When a cookie is protected with the secure attribute set to true it will not be send by the browser over an unencrypted HTTP request and thus cannot be observed by an unauthorized person during a man-in-the-middle attack.

Why is this an issue?

When a cookie is created without the secure attribute set to true, browsers will transmit it over unencrypted HTTP connections as well as HTTPS. An attacker who can observe or intercept network traffic—for example on a public Wi-Fi network—can read the cookie value in cleartext.

What is the potential impact?

Session hijacking

If a session cookie is transmitted over an unencrypted HTTP connection, an attacker who can intercept the traffic can steal it. With a valid session cookie, the attacker can impersonate the victim and gain full access to their account without knowing their password. Even on sites that primarily use HTTPS, a single HTTP request containing the session cookie is enough to expose it.

How to fix it in Servlet

Call setSecure(true) on the Cookie object to ensure it is only transmitted over HTTPS.

Code examples

Noncompliant code example

If you create a security-sensitive cookie in your JAVA code:

Cookie c = new Cookie(COOKIENAME, sensitivedata);
c.setSecure(false);  // Noncompliant

By default the secure flag is set to false:

Cookie c = new Cookie(COOKIENAME, sensitivedata);  // Noncompliant: cookies are created by default without a secure flag

Compliant solution

Cookie c = new Cookie(COOKIENAME, sensitivedata);
c.setSecure(true);

Cookie c = new Cookie(COOKIENAME, sensitivedata);
c.setSecure(true);

Resources

Standards