Session cookie configuration in Symfony framework.yaml
Session settings are configured in config/packages/framework.yaml under the 'framework.session' key. Key settings: cookie_httponly, cookie_lifetime, cookie_samesite, cookie_secure.
OWASP Cheat Sheets · all subjects
application_security/session_management
62 notes in this subject, read out of this brain and free to use. This is page 1 of 2.
Session cookie_httponly setting prevents JavaScript access
Set 'cookie_httponly: true' in session configuration to prevent JavaScript from accessing the session cookie. This is a recommended security practice.
Session TTL duration recommendations
According to OWASP recommendations, set cookie_lifetime in session configuration to: 2-5 minutes for high-value applications, 15-30 minutes for lower-risk applications.
Session cookie_samesite setting prevents cross-origin cookie sending
Set 'cookie_samesite' to either 'lax' or 'strict' to prevent cookies from being sent from cross-origin requests. 'lax' allows the cookie with 'safe' top-level navigations and same-site requests. 'strict' prevents any cookie from being sent when the HTTP request is not from the same domain.
Session cookie_secure setting with auto value
Set 'cookie_secure: auto' in session configuration to ensure cookies are only sent over secure connections. 'auto' sets 'true' for HTTPS and 'false' for HTTP protocol.
Session cookie_secure default value
By default, 'cookie_secure' is set to 'true'. Ensure it is not explicitly set to 'false' as this would allow cookies to be sent over insecure HTTP connections.
Disable PHP session.auto_start when using Symfony
When using Symfony for session management, it is recommended to disable 'session.auto_start = 1' directive in php.ini. Symfony manages sessions through its own mechanisms, and the PHP directive can cause conflicts and unexpected behavior.
Session ID entropy requirement
Session identifiers must have at least 64 bits of entropy to prevent brute-force session guessing attacks. With 64 bits of entropy, an attacker can expect to spend approximately 585 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available.
Session ID length in hexadecimal
When using hexadecimal encoding, a session ID must be at least 16 hexadecimal characters long to achieve the required 64 bits of entropy. Different encoding methods result in different lengths for the same entropy; Base64 or Microsoft's ASP.NET encoding may require different character counts.
Session ID name fingerprinting
The session ID name should not be extremely descriptive or offer unnecessary details. Default names like PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), and ASP.NET_SessionId disclose technologies and programming languages. It is recommended to change the default session ID name to a generic name, such as 'id'.
Session ID content must not contain sensitive data
The session ID content must be meaningless to prevent information disclosure attacks. The session ID must never include sensitive information or Personally Identifiable Information (PII). All meaning and business logic associated with the session ID must be stored server-side in session objects or session management database, not encoded in the ID itself.
Use cryptographically secure random number generator for session IDs
A strong CSPRNG (Cryptographically Secure Pseudorandom Number Generator) must be used to generate session IDs to ensure values are evenly distributed. If a custom session ID is created, use a cryptographically secure pseudorandom number generator with a size of at least 128 bits and ensure each sessionID is unique.
Secure cookie attribute usage
The 'Secure' cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This is mandatory to prevent session ID disclosure through Man-in-the-Middle attacks. Setting Secure flag is essential even if the web application forces HTTPS, as an attacker can intercept and manipulate victim traffic to inject HTTP references that force the browser to submit the session ID in clear.
HttpOnly cookie attribute usage
The 'HttpOnly' cookie attribute instructs web browsers not to allow scripts (JavaScript or VBscript) to access cookies via the DOM document.cookie object. This is mandatory to prevent session ID theft through XSS attacks. However, if XSS is combined with CSRF, the session cookie will still be sent with requests. HttpOnly only protects confidentiality; it does not protect against CSRF attacks.
SameSite attribute for session cookies
Session cookies must explicitly set SameSite=Strict (preferred) or SameSite=Lax. Never use SameSite=None without Secure, and do not rely on browser-default values, which vary across browsers and versions. SameSite prevents the browser from sending the cookie on cross-site requests, mitigating cross-origin leakage and providing CSRF defense.
Set-Cookie header with secure attributes example
Example secure session cookie: Set-Cookie: __Host-SessionID=<value>; Secure; HttpOnly; SameSite=Strict; Path=/
Domain cookie attribute scope
The Domain cookie attribute instructs browsers to send the cookie only to the specified domain and all subdomains. If not set, the cookie is sent only to the origin server by default. It is recommended not to set the Domain attribute (restricting the cookie to the origin server only) to prevent cross-subdomain cookie attacks. Setting Domain to permissive values like 'example.com' allows attackers to launch attacks between different hosts and web applications on the same domain.
Path cookie attribute scope
The Path cookie attribute instructs browsers to send the cookie only to the specified directory or subdirectories within the web application. If not set, the cookie is sent for the directory of the requested resource by default. It is recommended to set Path as restrictive as possible to the specific path that uses the session ID.
Do not use persistent cookies for session management
Session management should use non-persistent (session) cookies, not persistent cookies with Max-Age or Expires attributes. Non-persistent cookies force the session to disappear when the browser is closed, preventing the session ID from remaining in the client cache for extended periods where an attacker could obtain it.
Do not store authentication tokens in localStorage or sessionStorage
Do not store authentication tokens, session IDs, JWTs, refresh tokens, or any credential in localStorage or sessionStorage. These APIs are accessible to any JavaScript executing in the origin, so a single XSS vulnerability discloses every token. Use HttpOnly; Secure; SameSite=Strict cookies (preferred) or a Backend-for-Frontend (BFF) pattern instead.
Use cookies as primary session ID exchange mechanism
A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation attacks.
Enforce HTTPS for entire session
It is essential to use an encrypted HTTPS (TLS) connection for the entire web session, not only for the authentication process. Do not switch a session from HTTP to HTTPS, or vice-versa, as this will disclose the session ID in clear. When redirecting to HTTPS, ensure that the cookie is set or regenerated after the redirect has occurred.
Implement HTTP Strict Transport Security (HSTS)
Implement HSTS to enforce HTTPS connections and protect sessions. See the OWASP HTTP Strict Transport Security Cheat Sheet for detailed guidance.
Do not mix encrypted and unencrypted content
Do not mix encrypted and unencrypted contents (HTML pages, images, CSS, JavaScript files, etc) in the same page or from the same domain. Where possible, avoid offering public unencrypted contents and private encrypted contents from the same host. If insecure content is required, consider hosting it on a separate insecure domain.
Strict vs permissive session management
There are two types of session management mechanisms: permissive and strict. Permissive mechanisms allow the web application to accept any session ID value set by the user as valid, creating a new session for it. Strict mechanisms enforce that the web application only accepts session ID values previously generated by the web application. Strict is more secure. PHP defaults to permissive. Web applications should reject session IDs they have never generated and generate a new one instead, treating this as suspicious activity.
Treat session IDs as untrusted user input
Session IDs must be considered untrusted, like any other user input, and must be thoroughly validated and verified before processing. Depending on the session management mechanism, the session ID will be received in GET or POST parameters, in the URL or in HTTP headers. Failure to validate session IDs can expose the application to SQL injection, persistent XSS, and other vulnerabilities.
Renew session ID after privilege level change
The session ID must be renewed or regenerated after any privilege level change within the user session. Common scenarios include authentication (unauthenticated to authenticated state), password changes, permission changes, or switching from regular user to administrator role. For all sensitive pages, previous session IDs must be ignored, only the current session ID must be assigned, and the old session ID must be destroyed.
Session ID regeneration framework methods
Web development frameworks provide session regeneration methods: J2EE uses request.getSession(true) & HttpSession.invalidate(); ASP.NET uses Session.Abandon() & Response.Cookies.Add(new...); PHP uses session_start() & session_regenerate_id(true).
Session fixation attack prevention
Session ID regeneration is mandatory to prevent session fixation attacks, where an attacker sets the session ID on the victim's browser instead of gathering it. This protection works independently of HTTP or HTTPS and mitigates session fixation attacks enabled by HTTP response splitting or XSS vulnerabilities.
Use different session ID names pre and post authentication
A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication. This allows the web application to track anonymous and authenticated users separately without the risk of exposing or binding the user session between both states.
Reauthentication after high-risk events
Web applications should require reauthentication after high-risk events such as: changes to critical user information (e.g., password, email address); login attempts from new or suspicious IP addresses or devices; account recovery flows (e.g., password reset or compromised-account detection).
Verify all cookies when using multiple cookies
If a web application uses multiple cookies for a given session, the web application must verify all cookies and enforce relationships between them before allowing access to the user session. Common scenario: a pre-authentication cookie over HTTP and a post-authentication secure cookie over HTTPS. If not verified together, an attacker can use the pre-authentication cookie to access the authenticated session.
Session idle timeout
All sessions should implement an idle or inactivity timeout defining the amount of time a session remains active with no activity before being closed and invalidated. Session timeout management and expiration must be enforced server-side. If the client enforces timeout using session token or other client parameters to track time, an attacker could manipulate these to extend the session duration.
Idle timeout recommendations
Common idle timeout ranges: 2-5 minutes for high-value applications and 15-30 minutes for low-risk applications. The exact value depends on the balance between security and usability, allowing users to complete operations without sessions frequently expiring.
Session absolute timeout
All sessions should implement an absolute timeout regardless of session activity. This defines the maximum amount of time a session can be active since initial creation, after which the session is closed and invalidated. The user is then forced to reauthenticate and establish a new session. This limits the amount of time an attacker can use a hijacked session.
Absolute timeout recommendations
Absolute timeouts depend on how long a user typically uses the application. For an office worker using the application for a full day, an appropriate absolute timeout range could be between 4 and 8 hours.
Session renewal timeout
Web applications can implement an additional renewal timeout after which the session ID is automatically renewed in the middle of the user session, independently of session activity. After a specific time since session creation, the application regenerates a new ID for the user session. The previous ID remains valid for some time (safety interval) before the client switches to the new ID. When the client switches to the new ID, the application invalidates the previous ID. This minimizes the time a session ID can be reused to hijack a session.
Logout button requirements
Web applications must provide a visible and easily accessible logout (logoff, exit, or close session) button available on the web application header or menu and reachable from every resource and page. The user can manually close the session at any time. The web application must invalidate the session at least on the server side.
Invalidate session on client and server
When a session expires or the user logs out, the web application must take active actions to invalidate the session on both client and server. Client-side actions typically involve clearing the token value. For cookies, set an empty or invalid value and set the Expires (or Max-Age) attribute to a past date. Server-side, use session functions like HttpSession.invalidate() (J2EE), Session.Abandon() (ASP.NET), or session_destroy()/unset() (PHP).
Cache-Control header for session IDs
Session identifiers must never be cached. Include the Cache-Control: no-store directive in responses containing session IDs. Unlike no-cache, which allows caching but requires revalidation, no-store ensures the response (including headers like Set-Cookie) is never stored in any cache.
Clear-Site-Data header for session cleanup
When a session ends, use the Clear-Site-Data response header (e.g., Clear-Site-Data: "cache", "cookies", "storage") during logout or session termination. This instructs the browser to delete cached resources, cookies, and other client-side storage associated with the origin, ensuring complete session cleanup and removal of previously stored sensitive data.
Cache directives for sensitive content
Web applications must use restrictive cache directives for all HTTP and HTTPS traffic, especially for pages displaying sensitive content. Use HTTP headers such as Cache-Control and Pragma, or equivalent <meta> tags. Even after a session ends, private or sensitive data exchanged during the session may remain accessible through the browser cache.
Session ID guessing and brute force detection
Web applications must detect when an attacker tries to guess or brute force session IDs by launching multiple sequential requests using different session IDs from single or multiple IP addresses. Detection should be based on the number of attempts to gather or use different session IDs. Alert and/or block the offending IP address(es) when suspicious patterns are detected.
Bind session ID to user properties
Bind the session ID to other user or client properties such as client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these properties during an established session, it indicates potential session manipulation and hijacking attempts. Use this to alert and/or terminate suspicious sessions. Note: skilled attackers can bypass these controls by sharing the same IP (NAT), using the same proxy, or modifying User-Agent.
Log session lifecycle events
Web applications should log the full lifecycle of sessions including creation, renewal, and destruction of session IDs, as well as details about usage within login/logout operations, privilege level changes, timeout expiration, invalid session activities, and critical business operations. Log details should include timestamp, source IP, target resource, HTTP headers (User-Agent, Referer), GET/POST parameters, error codes, username/user ID.
Log salted hash of session ID instead of ID itself
Sensitive data like the session ID should not be included in logs to protect against session ID disclosure. Instead, log a salted-hash of the session ID to allow session-specific log correlation without exposing the actual session ID.
Simultaneous session logon policy
It is a web application design decision whether to allow multiple simultaneous logons from the same user from the same or different client IP addresses. If not allowing simultaneous logons, the application must effectively terminate the previously available session after each new authentication event, or ask the user which session should remain active. It is recommended to allow users to check active sessions, monitor concurrent logons, remotely terminate sessions, and view account activity history.
Web Workers for storing secrets
Web Workers are an alternative for browser storage of session secrets when storage persistence across page refresh is not required. For Web Workers to provide secure storage, code requiring the secret should exist within the Web Worker and the secret should never be transmitted to the main window context. Storing secrets in Web Worker memory offers the same security as HttpOnly cookies: confidentiality is protected. However, XSS can still be used to send messages to the Web Worker to perform operations requiring the secret.
Web Worker advantage over HttpOnly cookie
A Web Worker implementation advantage compared to HttpOnly cookies is that Web Workers allow isolated JavaScript code to access the secret, while HttpOnly cookies are not accessible to any JavaScript. If frontend code requires access to the secret, Web Worker implementation is the only browser storage option that preserves secret confidentiality.
localStorage scope and origin
Data stored using the localStorage API is accessible by pages loaded from the same origin, defined as the scheme (https://), host (example.com), port (443), and domain/realm (example.com). This provides similar access as the secure flag on a cookie—data stored from https cannot be retrieved via http. Data stored using localStorage may be susceptible to shared access issues and race-conditions due to potential concurrent access.
localStorage persistence and offline access
Data stored using localStorage is persisted across browsing sessions, extending the timeframe it may be accessible to other system users. The standards do not require localStorage data to be encrypted-at-rest, so it may be possible to directly access this data from disk.
sessionStorage scope and window context
The sessionStorage API stores data within the window context from which it was called, meaning Tab 1 cannot access data stored from Tab 2. Like localStorage, data stored using sessionStorage is accessible by pages from the same origin (scheme, host, port, domain/realm).
sessionStorage duration and offline access
The sessionStorage API only stores data for the duration of the current browsing session. Once the tab is closed, data is no longer retrievable, though it does not necessarily prevent access if the browser tab is reused or left open, or if data persists in memory until garbage collection. Standards do not require sessionStorage data to be encrypted-at-rest.
Use built-in framework session management
It is recommended to use built-in session management features from web development frameworks (J2EE, ASP.NET, PHP, etc.) rather than building homemade solutions. Framework implementations are used worldwide and tested by the security and development communities. However, frameworks have presented vulnerabilities in the past, so always use the latest version available and review default configuration to enhance security.
Secure session storage repository
The storage capabilities or repository used by the session management mechanism must be secure, protecting session IDs against local or remote accidental disclosure or unauthorized access. If session objects contain sensitive information like credit card numbers, encrypt and protect the session management repository.
Initial login timeout client-side protection
Web applications can use JavaScript to evaluate and measure the amount of time since the login page was loaded and a session ID was granted. If a login attempt occurs after a specific amount of time, client code can notify the user and reload the login page to retrieve a new session ID. This extra protection attempts to force session ID renewal pre-authentication and avoids scenarios where previously used session IDs are reused in session fixation attacks.
Force logout on browser window close
Web applications can use JavaScript to capture web browser tab or window close (or back) events and take appropriate actions to close the current session before closing the browser, emulating manual logout via the logout button.
Disable cross-tab session sharing
Web applications can use JavaScript after login to force users to re-authenticate if a new browser tab or window is opened against the same web application, disallowing multiple tabs/windows from sharing the same session. Note: This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all browser tabs/windows.
Automatic client-side logout on idle timeout
JavaScript can be used on all or critical pages to automatically logout sessions after the idle timeout expires, e.g., by redirecting to the logout page. Client-side implementation complements server-side idle timeout, allowing users to see the session has finished due to inactivity and be notified in advance through countdown timers and warning messages. This prevents loss of work from silent server-side session expiration.
WAF session management protections
Web Application Firewalls (WAFs) can detect and protect against session-based attacks. WAFs can enforce security attributes on cookies (Secure, HttpOnly flags) via basic rewriting rules on Set-Cookie headers. Advanced WAF capabilities include tracking sessions and session IDs, protecting against session fixation by renewing session IDs on privilege changes, enforcing sticky sessions by verifying relationship between session ID and client properties (IP, User-Agent), and managing session expiration on both client and server.