Thx. I saw your note and have been thinking about this potential conflict. Do you mean: I should not be setting the flag in both Apache conf AND application.cfm?
I took your note to mean that I need to ensure the secure setting is not in https.conf twice - which it is not. Where else would I need to worry about?
Either way, I tested this config in chrome, edge and Firefox- all Pass.
Also, the third party check is now passing (failing before).
LOL - I think we were typing at the same time.
Great feedback guys. I greatly appreciate it. AND - I really need to get this right before moving to production and mucking up our SLAs.
YES - Full control over everything… I like your suggestion.
I put in the CFABORT directly under the cfapplication statement (after backing out my httpd.conf change and restarting)… It went back to a failure state (where the Secure flags are new missing when tested in an incognito window)…
The external testing tool shows the same (Secure flag missing)
What could possibly be doing this?
Check over all the apache configuration files to make sure there isn’t anything similar to the line you added, remember it might not be in httpd.conf, it might be in a include, that is editing the cookie, so maybe do a grep for Header edit and see if there is already something else there editing the cookie. Either that or in the Tomcat configuration, but I don’t know what that would be.
From a quick Google, it looks like in Tomcat it would be a CookieProcessor element.
Another way to find out if it’s something ELSE in Apache messing with things (as Andrew notes) would be to test your requests against CFML code running via the built-in (Tomcat) web server rather than via Apache. Have you tried that yet, again even with just some simple test code as we’ve been discussing?
Depending on how you installed Lucee, you may have a Lucee webapps/ROOT folder where you can drop in such test code, and then browser it via 8888. But there are so many different ways that people can install and configure Lucee, so if you have access to the Lucee Admin, on its overview page, the bottom section on “web contexts” will tell you both values.
If code tested that way still failed to show the use of secure cookies (for CFID/CFTOKEN), then we know the issue is either in Lucee or in Tomcat (as Andrew also proposed might be possible). Each step gets us closer to knowing the cause–and therefore a potential solution. 
Thanks guys. I will test tomcat next.
Something I failed to mention in our config, that I realize may be extremely relevant, is that all SSL processing is off-loaded to the AWS load balancer - which is upstream (obviously) from the prod web server cluster. So, as far as tomcat / Apache / Luce are concerned - everything runs on port 80 / http. Is this part of the puzzle?
I don’t think that matters as that is the configuration I’m using and it hasn’t affected it and I don’t think AWS ELB has any options to change the cookie headers but always worth double checking.
Okay. Thanks.
Based on your suggestion above, I dug into the Tomcat config settings. I found this helpful article:
https://geekflare.com/secure-cookie-flag-in-tomcat/
Unfortunately, it did not work. Still missing Secure Flag for CFID and CFTOKEN… Which seems to point to something in my Apache config as the problem (and so far, the only place I’ve round a solution).
I’m not sure how to do that because (as discussed) the entire environment is non-ssl / http. I did put in the cfabort in application.cfm - but since I can’t load :8888 securely, I think this is a false positive. Right?
Also - Dumb question at this point perhaps - but are you guys using Session Type = Application? (we are).
Adam/Purdue, it doesn’t matter whether you make the request via https, if you’re simply wanting to see what sort of headers the cfml page returns.
The secure attribute for a cookie does indeed control whether that cookie would be RETURNED to a server in a subsequent request (and only if that request is made via https), but I’m not aware of any limitation by which the page that SETS the cookie needs to be called via https. (There may be, but again I am not aware of it nor would I expect it.)
So that’s why I proposed you run the test that I suggested. Have you tried it?
And I am assuming you are judging results not be what the browser dev tools shows for its display of what cookies are IN the browser (via the application tab in most browsers), but instead you should be looking at the network tab to see what RESPONSE HEADERS are being generated by the specific page you request. You may discover interesting things if you watch that.
And if you may well be already doing that, great. Let us know how it goes testing a page via the built-in web server, again as much for diagnostic purposes.
Finally, to be clear, I have not myself been testing anything as I’ve share my responses. I’ve always been seeing thesd on my phone this weekend, and I’ve just been chiming in where I thought I might offer helpful perspective.
Thanks again. Hate to be a broken record - but you guys are SO helpful. I can’t thank you enough.
So that’s why I proposed you run the test that I suggested. Have you tried it?
For sure. I loaded web pages from the :8888 port as you suggested (which I believe is coming straight from Tomcat). Saw the same exact results. In our configuration, the default path you mentioned above “Lucee webapps/ROOT folder” is not in use. We set a different path in the Tomcat conf files. At any rate, wanted you to know I ran the test. Here is what I saw:
On your other point, about looking at the “Network” tab of Chrome developer tools. Great suggestion! Thank you! I did that.
Here is the output from outside the firewall - running through Apache:
Here is the data from inside the DMZ network, calling directly to Tomcat via Port 8888:
If I’m reading this correctly (and there is a high probability I’m not 
— it seems that Tomcat is not setting the secure flag for the CFID and CFTOKEN cookies despite my settings in Application.cfm. Your test helped isolate this to a Tomcat issue, correct?
The only other real difference I can see between the Tomcat and Apache output is that the Tomcat call includes a JSESSIONID… Is this problem stemming from the fact that I’m running SESSION TYPE = APPLICATION under SCOPE in the Lucee Admin? Do you guys run that Session Type?
So grateful for this community. Thanks a million!
From seeing your direct Tomcat requests at port 8888 I can see that the flags are not being set. Looks like your directive sessioncookie is being ignored somehow.
Now I just saw that you set:
Still, I’m not at home to test… but: You’ve defined cf_ssn_cookies as a struct, but then afterwards you assign it as a string with:
sessioncookie="#cf_ssn_cookies#"
That would be a string, not a struct:
sessioncookie="{httponly=‘true’, secure=‘true’}"
I really don’t now if Lucee would identify that string above as a struct and cast it as a struct. Instead it should be sessioncookie={httponly=‘true’, secure=‘true’} (without the doublequotes).
What happens if you assign it like so:
sessioncookie=cf_ssn_cookies ?
Or even directly:
sessioncookie={httponly=‘true’, secure=‘true’}
You could also try setting it as bracket notarion like so:
sessionCookie[“secure”] = true
SessionCookie[“httpOnly”] = true
Would like to know what happens. I’d test it directly if I had my notebook with me, but I’m just with my mobile right now 
sessioncookie="{httponly=‘true’, secure=‘true’}"
sessioncookie="{httponly=‘true’, secure=‘true’}
No quotes at all:
Your other idea:
None seem to work. Bummer 
What cookies does the lucee admin set?
With our session type = Application, it looks like CFID and CFTOKEN…
sorry, i meant is the admin setting both secure and httponly (i.e the subject of this thread)
Hi Zack!
In a nutshell - the fine people of this forum gave me code to add to CFAPPLICATION - with the hopes that it would set both flags.
Unfortunately, only the httponly flag is being set. We can’t get the “Secure” flag to set.
The only way I’ve found to do it (and I’m about 8 hours into this issue at this point) is to add code to the Apache http.conf to force the flag in the set-cookie header… This allows my PCI Compliance scan to pass…
HOWEVER - Folks in this community have warned against this solution saying it has caused them issues. Any ideas? I’m stumped. The testing against port 8888 shows the Secure flag is NOT being set by Tomcat…
there’s absolutely nothing wrong with doing it in Apache
the old <cfapplication> style might be the problem, I know it works with Application.cfc
Thanks Zackster… Glad to hear you have confidence in the Apache approach. We will, of course, do thorough regression testing before pushing this to production…
the old
<cfapplication>style might be the problem
I was thinking that too based on my research until a few people chimed-in and said it was working for them.
I will see if I can answer that empirically with a simple Application.cfc test.
another workaround that might help: I remember just setting the flags with cfcookie in the past for a legacy app with application.cfm with cfcookie somewhere after the cfapplication tag like so:
<cfcookie name="CFID" value="#SESSION.CFID#" httpOnly="true" secure="true">
<cfcookie name="CFTOKEN" value="#SESSION.CFTOKEN#" httpOnly="true" secure="true">
That worked in that environment, I don’t know if it would work for you or if it might break something else. But better would be to rewrite your application.cfm to Application.cfc.
Thanks for all the help everyone. For now, we are going to run with the update to the Apache http.conf file.
For future reference, here is the line we added to httpd conf:
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
After a restart of httpd, the secure flag is present on the cookie.
We will report back if there are any issues.