Security vulnerability scans sometimes flag the JSESSIONID cookie as a security misconfiguration because the cookie path equals / and the SameSite attribute equals None. This warning occurs because the cookie acts as an artifact of the underlying infrastructure, but administrators can safely ignore the warning because Okta does not use the JSESSIONID cookie for user session management. Administrators reviewing browser storage or security scans observe a warning indicating that malicious scripts can access the JSESSIONID cookie or share it across applications in the same domain.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Security Vulnerability Scans

The underlying Okta infrastructure inherently generates the JSESSIONID cookie. Okta assigns the Secure and HttpOnly attributes to the cookie when setting the path. Administrators can verify this using the web browser developer tools:

Why does the JSESSIONID cookie appear, and how is the session secured?

Administrators can safely ignore this warning because the cookie acts as an artifact of the underlying infrastructure and does not govern session security. Administrators do not need to perform any active risk mitigation or configuration changes.

Verify that Okta properly protects the actual session cookies by opening the web browser developer tools, locating the session cookie, and confirming the security attributes.

1. Open the web browser developer tools.
2. Locate the SID cookie for Okta Classic Engine or the IDX cookie for Okta Identity Engine (OIE).
3. Confirm that both cookies possess the HTTPOnly and Secure attributes, with the SameSite attribute equaling None and Secure equaling True.