8

There are 2 ways of setting 'secure' flag on a session cookie:

  1. In the application itself, for exemple:

    <session-config>
        <cookie-config>
            <http-only>true</http-only>
            <secure>true</secure>
        </cookie-config>
    </session-config>
    
  2. In the configuration of TLS proxy like httpd.

I can't find any article telling which one is the best practice.

The most secure is likely to be 2, while the most logical is the 1, since it only works with HTTPS.

3
  • What if you use 1 but the httpd is not configured for TLS?
    – Sravan
    Commented Sep 16, 2016 at 12:58
  • If you do that and you send an http request, the response will contain a set-cookie JSESSIONID with the secure flag, but your browser won't create the cookie, so it won't work actually.
    – Pleymor
    Commented Sep 16, 2016 at 13:08
  • Its the other way around. The browsers are not ignoring the secure flag
    – Sravan
    Commented Sep 16, 2016 at 16:00

2 Answers 2

3

I recommend its better to use both of them together as it doesn't cause any harm. Also, it ensures philosophy of Defense in Depth.

These days people are deploying on cloud and migrations are more often done. So,I think we cannot be sure that the configuration 2 you mentioned for httpd is in place all the time.

You should consider that enabling <secure>true</secure> in application is mandatory. Explanation given below.

Explanation:

Scenario 1(Assuming secure flag setting missed by TLS proxy/httpd)

I tested a scenario where I have only enabled <secure>true</secure> in the application itself and not configured secure flag via TLS proxy(httpd).

Now the Response Header has a cookie with secure flag, I observed that Firefox and Chrome process and save the cookie with secure flag.

Set-Cookie: acct=tafats; domain=localhost; Secure;expires=Thu, 16-Mar-2017 15:19:48 GMT; path=/; HttpOnly

From a Security point of view this is what is to be expected from browsers.

This protects you from session-hijacking attempts via packet sniffing.

In this case,If the attacker makes the user to click on http://example.com, the cookie is not sent because it has a secure flag.

Here, the <secure>true</secure> came to rescue.

Scenario 2(Assuming secure flag setting missed in the application but configured in TLS proxy/httpd)

Its good enough , as long as you have this secure flag set via TLS proxy. But the catch here is, you need to ensure that this TLS proxy setting is configured for all deployments you do all the time.

To conclude, I recommend its better to use both of them together and ensure the philosophy of Defense in Depth.

3

In the application.

The cookies themselves are set by the application, and the cookie flags are part of that. Cookies can have several flags: "secure", "httponly", "samesite". Only the application knows which cookies should have which flags. If your proxy inserts the httponly flag and the application wants to access the cookie with Javascript, this will no longer work. Cookies are the responsibility of the application.

Furthermore, you want the application to behave consistently no matter what proxy you are using. Developers are probably not using any proxy when testing the application, but they should still use secure cookies so that the environment closely matches production.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .