{
	"id": "4ee6e8af-1029-4e96-9880-e0b35a844974",
	"created_at": "2026-04-06T00:17:58.430035Z",
	"updated_at": "2026-04-10T13:11:46.647511Z",
	"deleted_at": null,
	"sha1_hash": "3c318fe81f4961d60bacf626c7011886b078f697",
	"title": "Session Management - OWASP Cheat Sheet Series",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 243603,
	"plain_text": "Session Management - OWASP Cheat Sheet Series\r\nArchived: 2026-04-05 21:08:15 UTC\r\nIntroduction¶\r\nWeb Authentication, Session Management, and Access Control:\r\nA web session is a sequence of network HTTP request and response transactions associated with the same user.\r\nModern and complex web applications require the retaining of information or status about each user for the\r\nduration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights\r\nand localization settings – which will apply to each and every interaction a user has with the web application for\r\nthe duration of the session.\r\nWeb applications can create sessions to keep track of anonymous users after the very first user request. An\r\nexample would be maintaining the user language preference. Additionally, web applications will make use of\r\nsessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as\r\nwell as being able to apply security access controls, authorized access to the user private data, and to increase the\r\nusability of the application. Therefore, current web applications can provide session capabilities both pre and post\r\nauthentication.\r\nOnce an authenticated session has been established, the session ID (or token) is temporarily equivalent to the\r\nstrongest authentication method used by the application, such as username and password, passphrases, one-time\r\npasswords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See\r\nthe OWASP Authentication Cheat Sheet.\r\nHTTP is a stateless protocol (RFC2616 section 5), where each request and response pair is independent of other\r\nweb interactions. Therefore, in order to introduce the concept of a session, it is required to implement session\r\nmanagement capabilities that link both the authentication and access control (or authorization) modules commonly\r\navailable in web applications:\r\nThe session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP\r\ntraffic and the appropriate access controls enforced by the web application. The complexity of these three\r\ncomponents (authentication, session management, and access control) in modern web applications, plus the fact\r\nthat its implementation and binding resides on the web developer's hands (as web development frameworks do not\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 1 of 17\n\nprovide strict relationships between these modules), makes the implementation of a secure session management\r\nmodule very challenging.\r\nThe disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or\r\nsidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers\r\ncan perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker's goal is to\r\nimpersonate a specific (or privileged) web application victim user. For generic attacks, the attacker's goal is to\r\nimpersonate (or get access as) any valid or legitimate user in the web application.\r\nSession ID Properties¶\r\nIn order to keep the authenticated state and track the users progress within the web application, applications\r\nprovide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared\r\nand exchanged by the user and the web application for the duration of the session (it is sent on every HTTP\r\nrequest). The session ID is a name=value pair.\r\nWith the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the\r\nfollowing properties.\r\nSession ID Name Fingerprinting¶\r\nThe name used by the session ID should not be extremely descriptive nor offer unnecessary details about the\r\npurpose and meaning of the ID.\r\nThe session ID names used by the most common web application development frameworks can be easily\r\nfingerprinted, such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID \u0026 CFTOKEN (ColdFusion),\r\nASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and\r\nprogramming languages used by the web application.\r\nIt is recommended to change the default session ID name of the web development framework to a generic name,\r\nsuch as id .\r\nSession ID Entropy¶\r\nSession identifiers must have at least 64 bits of entropy to prevent brute-force session guessing attacks.\r\nEntropy refers to the amount of randomness or unpredictability in a value. Each “bit” of entropy doubles the\r\nnumber of possible outcomes, meaning a session ID with 64 bits of entropy can have 2^64 possible values.\r\nA strong CSPRNG (Cryptographically Secure Pseudorandom Number Generator) must be used to generate\r\nsession IDs. This ensures the generated values are evenly distributed among all possible values. Otherwise,\r\nattackers may be able to use statistical analysis techniques to identify patterns in how the session IDs are created,\r\neffectively reducing the entropy and allowing the attacker to guess or predict valid session IDs more easily.\r\nNOTE:\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 2 of 17\n\nThe expected time for an attacker to brute-force a valid session ID depends on factors such as the number\r\nof bits of entropy, the number of active sessions, session expiration times, and the attacker's guessing rate.\r\nIf a web application generates session IDs with 64 bits of entropy, an attacker can expect to spend\r\napproximately 585 years to successfully guess a valid session ID, assuming the attacker can try 10,000\r\nguesses per second with 100,000 valid simultaneous sessions available in the application.\r\nFurther analysis of the expected time for an attacker to brute-force session identifiers is available here.\r\nSession ID Length¶\r\nAs mentioned in the previous Session ID Entropy section, a primary security requirement for session IDs is that\r\nthey contain at least 64 bits of entropy to prevent brute-force guessing attacks. Although session ID length\r\nmatters, it's the entropy that ensures security. The session ID must be long enough to encode sufficient entropy,\r\npreventing brute force attacks where an attacker guesses valid session IDs.\r\nDifferent encoding methods can result in different lengths for the same amount of entropy. Session IDs are often\r\nrepresented using hexadecimal encoding. When using hexadecimal encoding, a session ID must be at least 16\r\nhexadecimal characters long to achieve the required 64 bits of entropy. When using different encodings (e.g.\r\nBase64 or Microsoft's encoding for ASP.NET session IDs) a different number of characters may be required to\r\nrepresent the minimum 64 bits of entropy.\r\nIt’s important to note that if any part of the session ID is fixed or predictable, the effective entropy is reduced, and\r\nthe length may need to be increased to compensate. For example, if half of a 16-character hexadecimal session ID\r\nis fixed, only the remaining 8 characters are random, providing just 32 bits of entropy — which is insufficient for\r\nstrong security. To maintain security, ensure that the entire session ID is randomly generated and unpredictable, or\r\nincrease the overall length if parts of the ID are not random.\r\nNOTE:\r\nMore information about the relationship between Session ID Length and Session ID Entropy is available\r\nhere.\r\nSession ID Content (or Value)¶\r\nThe session ID content (or value) must be meaningless to prevent information disclosure attacks, where an\r\nattacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings\r\nof the web application.\r\nThe session ID must simply be an identifier on the client side, and its value must never include sensitive\r\ninformation or Personally Identifiable Information (PII). To read more about PII, refer to Wikipedia or this post.\r\nThe meaning and business or application logic associated with the session ID must be stored on the server side,\r\nand specifically, in session objects or in a session management database or repository.\r\nThe stored information can include the client IP address, User-Agent, email, username, user ID, role, privilege\r\nlevel, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 3 of 17\n\nsession details. If the session objects and properties contain sensitive information, such as credit card numbers, it\r\nis required to duly encrypt and protect the session management repository.\r\nIt is recommended to use the session ID created by your language or framework. If you need to create your own\r\nsessionID, use a cryptographically secure pseudorandom number generator (CSPRNG) with a size of at least 128\r\nbits and ensure that each sessionID is unique.\r\nSession Management Implementation¶\r\nThe session management implementation defines the exchange mechanism that will be used between the user and\r\nthe web application to share and continuously exchange the session ID. There are multiple mechanisms available\r\nin HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL\r\nparameters (URL rewriting – RFC2396), URL arguments on GET requests, body arguments on POST requests,\r\nsuch as hidden form fields (HTML forms), or proprietary HTTP headers.\r\nThe preferred session ID exchange mechanism should allow defining advanced token properties, such as the token\r\nexpiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 \u0026\r\n2965 \u0026 6265) are one of the most extensively used session ID exchange mechanisms, offering advanced\r\ncapabilities not available in other methods.\r\nThe usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might\r\ndisclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search\r\nengines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks.\r\nBuilt-in Session Management Implementations¶\r\nWeb development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management\r\nfeatures and associated implementation. It is recommended to use these built-in frameworks versus building a\r\nhome made one from scratch, as they are used worldwide on multiple web environments and have been tested by\r\nthe web application security and development communities over time.\r\nHowever, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is\r\nalways recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities,\r\nas well as review and change the default configuration to enhance its security by following the recommendations\r\ndescribed along this document.\r\nThe storage capabilities or repository used by the session management mechanism to temporarily save the session\r\nIDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized\r\naccess.\r\nUsed vs. Accepted Session ID Exchange Mechanisms¶\r\nA web application should make use of cookies for session ID exchange management. If a user submits a session\r\nID through a different exchange mechanism, such as a URL parameter, the web application should avoid\r\naccepting it as part of a defensive strategy to stop session fixation.\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 4 of 17\n\nNOTE:\r\nEven if a web application makes use of cookies as its default session ID exchange mechanism, it might\r\naccept other exchange mechanisms too.\r\nIt is therefore required to confirm via thorough testing all the different mechanisms currently accepted by\r\nthe web application when processing and managing session IDs, and limit the accepted session ID tracking\r\nmechanisms to just cookies.\r\nIn the past, some web applications used URL parameters, or even switched from cookies to URL\r\nparameters (via automatic URL rewriting), if certain conditions are met (for example, the identification of\r\nweb clients without support for cookies or not accepting cookies due to user privacy concerns).\r\nTransport Layer Security¶\r\nIn order to protect the session ID exchange from active eavesdropping and passive disclosure in the network\r\ntraffic, it is essential to use an encrypted HTTPS (TLS) connection for the entire web session, not only for the\r\nauthentication process where the user credentials are exchanged. This may be mitigated by HTTP Strict Transport\r\nSecurity (HSTS) for a client that supports it.\r\nAdditionally, the Secure cookie attribute must be used to ensure the session ID is only exchanged through an\r\nencrypted channel. The usage of an encrypted communication channel also protects the session against some\r\nsession fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the\r\nsession ID on the victim's web browser.\r\nThe following set of best practices are focused on protecting the session ID (specifically when cookies are used)\r\nand helping with the integration of HTTPS within the web application:\r\nDo not switch a given session from HTTP to HTTPS, or vice-versa, as this will disclose the session ID in\r\nthe clear through the network.\r\nWhen redirecting to HTTPS, ensure that the cookie is set or regenerated after the redirect has\r\noccurred.\r\nDo not mix encrypted and unencrypted contents (HTML pages, images, CSS, JavaScript files, etc) in the\r\nsame page, or from the same domain.\r\nWhere possible, avoid offering public unencrypted contents and private encrypted contents from the same\r\nhost. Where insecure content is required, consider hosting this on a separate insecure domain.\r\nImplement HTTP Strict Transport Security (HSTS) to enforce HTTPS connections.\r\nSee the OWASP Transport Layer Security Cheat Sheet for more general guidance on implementing TLS securely.\r\nIt is important to emphasize that TLS does not protect against session ID prediction, brute force, client-side\r\ntampering or fixation; however, it does provide effective protection against an attacker intercepting or stealing\r\nsession IDs through a man in the middle attack.\r\nCookies¶\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 5 of 17\n\nThe session ID exchange mechanism based on cookies provides multiple security features in the form of cookie\r\nattributes that can be used to protect the exchange of the session ID:\r\nSecure Attribute¶\r\nThe Secure cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS\r\n(SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session\r\nID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID\r\nfrom web browser traffic.\r\nForcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed\r\nin the web application host) does not protect against session ID disclosure if the Secure cookie has not been set -\r\nthe web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker\r\ncan intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web\r\napplication that will force the web browser to submit the session ID in the clear.\r\nSee also: SecureFlag\r\nHttpOnly Attribute¶\r\nThe HttpOnly cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability\r\nto access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent\r\nsession ID stealing through XSS attacks. However, if an XSS attack is combined with a CSRF attack, the requests\r\nsent to the web application will include the session cookie, as the browser always includes the cookies when\r\nsending requests. The HttpOnly cookie only protects the confidentiality of the cookie; the attacker cannot use it\r\noffline, outside of the context of an XSS attack.\r\nSee the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet.\r\nSee also: HttpOnly\r\nSameSite Attribute¶\r\nSameSite defines a cookie attribute preventing browsers from sending a SameSite flagged cookie with cross-site\r\nrequests. The main goal is to mitigate the risk of cross-origin information leakage, and provides some protection\r\nagainst cross-site request forgery attacks.\r\nSee also: SameSite\r\nDomain and Path Attributes¶\r\nThe Domain cookie attribute instructs web browsers to only send the cookie to the specified domain and all\r\nsubdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The Path\r\ncookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or\r\npaths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for\r\nthe directory (or path) of the resource requested and setting the cookie.\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 6 of 17\n\nIt is recommended to use a narrow or restricted scope for these two attributes. In this way, the Domain attribute\r\nshould not be set (restricting the cookie just to the origin server) and the Path attribute should be set as\r\nrestrictive as possible to the web application path that makes use of the session ID.\r\nSetting the Domain attribute to a too permissive value, such as example.com allows an attacker to launch attacks\r\non the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the\r\nsession IDs from secure.example.com .\r\nAdditionally, it is recommended not to mix web applications of different security levels on the same domain.\r\nVulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web\r\napplication on the same domain by using a permissive Domain attribute (such as example.com ) which is a\r\ntechnique that can be used in session fixation attacks.\r\nAlthough the Path attribute allows the isolation of session IDs between different web applications using\r\ndifferent paths on the same host, it is highly recommended not to run different web applications (especially from\r\ndifferent security levels or scopes) on the same host. Other methods can be used by these applications to access\r\nthe session IDs, such as the document.cookie object. Also, any web application can set cookies for any path on\r\nthat host.\r\nCookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS\r\nresolution to force the web browser to disclose the session ID for a given host or domain.\r\nExpire and Max-Age Attributes¶\r\nSession management mechanisms based on cookies can make use of two types of cookies, non-persistent (or\r\nsession) cookies, and persistent cookies. If a cookie presents the Max-Age (that has preference over Expires ) or\r\nExpires attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based\r\nuntil the expiration time.\r\nTypically, session management capabilities to track users after authentication make use of non-persistent cookies.\r\nThis forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is\r\nhighly recommended to use non-persistent cookies for session management purposes, so that the session ID does\r\nnot remain on the web client cache for long periods of time, from where an attacker can obtain it.\r\nEnsure that sensitive information is not compromised by ensuring that it is not persistent, encrypting it, and\r\nstoring it only for the duration of the need\r\nEnsure that unauthorized activities cannot take place via cookie manipulation\r\nEnsure secure flag is set to prevent accidental transmission over the wire in a non-secure manner\r\nDetermine if all state transitions in the application code properly check for the cookies and enforce their\r\nuse\r\nEnsure entire cookie should be encrypted if sensitive data is persisted in the cookie\r\nDefine all cookies being used by the application, their name and why they are needed\r\nHTML5 Web Storage API¶\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 7 of 17\n\nThe Web Hypertext Application Technology Working Group (WHATWG) describes the HTML5 Web Storage\r\nAPIs, localStorage and sessionStorage , as mechanisms for storing name-value pairs client-side. Unlike\r\nHTTP cookies, the contents of localStorage and sessionStorage are not automatically shared within requests\r\nor responses by the browser and are used for storing data client-side.\r\nThe localStorage API¶\r\nScope¶\r\nData stored using the localStorage API is accessible by pages which are loaded from the same origin, which is\r\ndefined as the scheme ( https:// ), host ( example.com ), port ( 443 ) and domain/realm ( example.com ). This\r\nprovides similar access to this data as would be achieved by using the secure flag on a cookie, meaning that\r\ndata stored from https could not be retrieved via http . Due to potential concurrent access from separate\r\nwindows/threads, data stored using localStorage may be susceptible to shared access issues (such as race-conditions) and should be considered non-locking (Web Storage API Spec).\r\nDuration¶\r\nData stored using the localStorage API is persisted across browsing sessions, extending the timeframe in which\r\nit may be accessible to other system users.\r\nOffline Access¶\r\nThe standards do not require localStorage data to be encrypted-at-rest, meaning it may be possible to directly\r\naccess this data from disk.\r\nUse Case¶\r\nWHATWG suggests the use of localStorage for data that needs to be accessed across windows or tabs, across\r\nmultiple sessions, and where large (multi-megabyte) volumes of data may need to be stored for performance\r\nreasons.\r\nThe sessionStorage API¶\r\nScope¶\r\nThe sessionStorage API stores data within the window context from which it was called, meaning that Tab 1\r\ncannot access data which was stored from Tab 2. Also, like the localStorage API, data stored using the\r\nsessionStorage API is accessible by pages which are loaded from the same origin, which is defined as the\r\nscheme ( https:// ), host ( example.com ), port ( 443 ) and domain/realm ( example.com ). This provides similar\r\naccess to this data as would be achieved by using the secure flag on a cookie, meaning that data stored from\r\nhttps could not be retrieved via http .\r\nDuration¶\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 8 of 17\n\nThe sessionStorage API only stores data for the duration of the current browsing session. Once the tab is\r\nclosed, that data is no longer retrievable. This does not necessarily prevent access, should a browser tab be reused\r\nor left open. Data may also persist in memory until a garbage collection event.\r\nOffline Access¶\r\nThe standards do not require sessionStorage data to be encrypted-at-rest, meaning it may be possible to directly\r\naccess this data from disk.\r\nUse Case¶\r\nWHATWG suggests the use of sessionStorage for data that is relevant for one-instance of a workflow, such as\r\ndetails for a ticket booking, but where multiple workflows could be performed in other tabs concurrently. The\r\nwindow/tab bound nature will keep the data from leaking between workflows in separate tabs.\r\nReferences¶\r\nWeb Storage APIs\r\nLocalStorage API\r\nSessionStorage API\r\nWHATWG Web Storage Spec\r\nWeb Workers¶\r\nWeb Workers run JavaScript code in a global context separate from the one of the current window. A\r\ncommunication channel with the main execution window exists, which is called MessageChannel .\r\nUse Case¶\r\nWeb Workers are an alternative for browser storage of (session) secrets when storage persistence across page\r\nrefresh is not a requirement. For Web Workers to provide secure browser storage, any code that requires the secret\r\nshould exist within the Web Worker and the secret should never be transmitted to the main window context.\r\nStoring secrets within the memory of a Web Worker offers the same security guarantees as an HttpOnly cookie:\r\nthe confidentiality of the secret is protected. Still, an XSS attack can be used to send messages to the Web Worker\r\nto perform an operation that requires the secret. The Web Worker will return the result of the operation to the main\r\nexecution thread.\r\nThe advantage of a Web Worker implementation compared to an HttpOnly cookie is that a Web Worker allows for\r\nsome isolated JavaScript code to access the secret; an HttpOnly cookie is not accessible to any JavaScript. If the\r\nfrontend JavaScript code requires access to the secret, the Web Worker implementation is the only browser storage\r\noption that preserves the secret confidentiality.\r\nSession ID Life Cycle¶\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 9 of 17\n\nSession ID Generation and Verification: Permissive and Strict Session Management¶\r\nThere are two types of session management mechanisms for web applications, permissive and strict, related to\r\nsession fixation vulnerabilities. The permissive mechanism allows the web application to initially accept any\r\nsession ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the\r\nweb application will only accept session ID values that have been previously generated by the web application.\r\nThe session tokens should be handled by the web server if possible or generated via a cryptographically secure\r\nrandom number generator.\r\nAlthough the most common mechanism in use today is the strict one (more secure), PHP defaults to permissive.\r\nDevelopers must ensure that the web application does not use a permissive mechanism under certain\r\ncircumstances. Web applications should never accept a session ID they have never generated, and in case of\r\nreceiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be\r\ndetected as a suspicious activity and an alert should be generated.\r\nManage Session ID as Any Other User Input¶\r\nSession IDs must be considered untrusted, as any other user input processed by the web application, and they must\r\nbe thoroughly validated and verified. Depending on the session management mechanism used, the session ID will\r\nbe received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do\r\nnot validate and filter out invalid session ID values before processing them, they can potentially be used to exploit\r\nother web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent\r\nXSS if the session IDs are stored and reflected back afterwards by the web application.\r\nRenew the Session ID After Any Privilege Level Change¶\r\nThe session ID must be renewed or regenerated by the web application after any privilege level change within the\r\nassociated user session. The most common scenario where the session ID regeneration is mandatory is during the\r\nauthentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to\r\nthe authenticated state though in some cases still not yet the authorized state. Common scenarios to consider\r\ninclude; password changes, permission changes, or switching from a regular user role to an administrator role\r\nwithin the web application. For all sensitive pages of the web application, any previous session IDs must be\r\nignored, only the current session ID must be assigned to every new request received for the protected resource,\r\nand the old or previous session ID must be destroyed.\r\nThe most common web development frameworks provide session functions and methods to renew the session ID,\r\nsuch as request.getSession(true) \u0026 HttpSession.invalidate() (J2EE), Session.Abandon() \u0026\r\nResponse.Cookies.Add(new...) (ASP .NET), or session_start() \u0026 session_regenerate_id(true) (PHP).\r\nThe session ID regeneration is mandatory to prevent session fixation attacks, where an attacker sets the session ID\r\non the victim user's web browser instead of gathering the victim's session ID, as in most of the other session-based\r\nattacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based\r\nvulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS\r\n(see here and here).\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 10 of 17\n\nA complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and\r\npost authentication, so that the web application can keep track of anonymous users and authenticated users\r\nwithout the risk of exposing or binding the user session between both states.\r\nReauthentication After Risk Events¶\r\nWeb applications should require reauthentication after high-risk events such as:\r\nChanges to critical user information (e.g., password, email address)\r\nLogin attempts from new or suspicious IP addresses or devices\r\nAccount recovery flows (e.g., password reset or compromised-account detection)\r\nFor best practices on implementing reauthentication after these events, see the Reauthentication After Risk Events\r\nsection in the Authentication Cheat Sheet\r\nAdditional Resources¶\r\nWhy Frequent Reauthentication Can Be a UX Pitfall by Tailscale\r\nConsiderations When Using Multiple Cookies¶\r\nIf the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a\r\ngiven session, the web application must verify all cookies (and enforce relationships between them) before\r\nallowing access to the user session.\r\nIt is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of\r\nunauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is\r\nestablished. If the web application does not verify both cookies for authenticated sessions, an attacker can make\r\nuse of the pre-authentication unprotected cookie to get access to the authenticated user session (see here and here).\r\nWeb applications should try to avoid the same cookie name for different paths or domain scopes within the same\r\nweb application, as this increases the complexity of the solution and potentially introduces scoping issues.\r\nSession Expiration¶\r\nIn order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is\r\nmandatory to set expiration timeouts for every session, establishing the amount of time a session will remain\r\nactive. Insufficient session expiration by the web application increases the exposure of other session-based attacks,\r\nas for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.\r\nThe shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session\r\nexpiration timeout values must be set accordingly with the purpose and nature of the web application, and balance\r\nsecurity and usability, so that the user can comfortably complete the operations within the web application without\r\nthe session frequently expiring.\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 11 of 17\n\nBoth the idle and absolute timeout values are highly dependent on how critical the web application and its data\r\nare. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15-30 minutes for low risk\r\napplications. Absolute timeouts depend on how long a user usually uses the application. If the application is\r\nintended to be used by an office worker for a full day, an appropriate absolute timeout range could be between 4\r\nand 8 hours.\r\nWhen a session expires, the web application must take active actions to invalidate the session on both sides, client\r\nand server. The latter is the most relevant and mandatory from a security perspective.\r\nFor most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out\r\nthe token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for\r\nthe session ID, and set the Expires (or Max-Age ) attribute to a date from the past (in case a persistent cookie is\r\nbeing used): Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT\r\nIn order to close and invalidate the session on the server side, it is mandatory for the web application to take active\r\nactions when the session expires, or the user actively logs out, by using the functions and methods offered by the\r\nsession management mechanisms, such as HttpSession.invalidate() (J2EE), Session.Abandon() (ASP\r\n.NET) or session_destroy()/unset() (PHP).\r\nAutomatic Session Expiration¶\r\nIdle Timeout¶\r\nAll sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will\r\nremain active in case there is no activity in the session, closing and invalidating the session upon the defined idle\r\nperiod since the last HTTP request received by the web application for a given session ID.\r\nThe idle timeout limits the chances an attacker has to guess and use a valid session ID from another user.\r\nHowever, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker's actions, as\r\nthey can generate activity on the session periodically to keep the session active for longer periods of time.\r\nSession timeout management and expiration must be enforced server-side. If the client is used to enforce the\r\nsession timeout, for example using the session token or other client parameters to track time references (e.g.\r\nnumber of minutes since login time), an attacker could manipulate these to extend the session duration.\r\nAbsolute Timeout¶\r\nAll sessions should implement an absolute timeout, regardless of session activity. This timeout defines the\r\nmaximum amount of time a session can be active, closing and invalidating the session upon the defined absolute\r\nperiod since the given session was initially created by the web application. After invalidating the session, the user\r\nis forced to (re)authenticate again in the web application and establish a new session.\r\nThe absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim\r\nuser.\r\nRenewal Timeout¶\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 12 of 17\n\nAlternatively, the web application can implement an additional renewal timeout after which the session ID is\r\nautomatically renewed, in the middle of the user session, and independently of the session activity and, therefore,\r\nof the idle timeout.\r\nAfter a specific amount of time since the session was initially created, the web application can regenerate a new\r\nID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be\r\nvalid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it.\r\nAt that time, when the client switches to the new ID inside the current session, the application invalidates the\r\nprevious ID.\r\nThis scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be\r\nreused to hijack the user session, even when the victim user session is still active. The user session remains alive\r\nand open on the legitimate client, although its associated session ID value is transparently renewed periodically\r\nduring the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements\r\nthe idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is\r\nan application requirement to keep the user sessions open for long periods of time).\r\nDepending on the implementation, potentially there could be a race condition where the attacker with a still valid\r\nprevious session ID sends a request before the victim user, right after the renewal timeout has just expired, and\r\nobtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the\r\nattack as the session will be suddenly terminated because the associated session ID is not valid anymore.\r\nManual Session Expiration¶\r\nWeb applications should provide mechanisms that allow security aware users to actively close their session once\r\nthey have finished using the web application.\r\nLogout Button¶\r\nWeb applications must provide a visible and easily accessible logout (logoff, exit, or close session) button that is\r\navailable on the web application header or menu and reachable from every web application resource and page, so\r\nthat the user can manually close the session at any time. As described in Session_Expiration section, the web\r\napplication must invalidate the session at least on server side.\r\nNOTE: Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side\r\nenhancements allow conscientious users to protect their sessions by helping to close them diligently.\r\nWeb Content Caching and Clear-Site-Data¶\r\nEven after the session has ended, private or sensitive data exchanged during the session may still be accessible\r\nthrough the web browser's cache. To mitigate this, web applications must use restrictive cache directives for all\r\nHTTP and HTTPS traffic. This includes the use of HTTP headers such as Cache-Control and Pragma , or\r\nequivalent \u003cmeta\u003e tags on all pages—especially those displaying sensitive content.\r\nSession identifiers must never be cached. To prevent this, it is highly recommended to include the Cache-Control: no-store directive in responses containing session IDs. Unlike no-cache , which allows caching but\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 13 of 17\n\nrequires revalidation, no-store ensures that the response (including headers like Set-Cookie ) is never stored in\r\nany cache.\r\nIn addition to preventing future caching, applications should ensure that previously stored sensitive data is\r\nremoved when a session ends. This can be achieved by returning the Clear-Site-Data response header (for\r\nexample, Clear-Site-Data: \"cache\", \"cookies\", \"storage\" ) during logout or session termination. This\r\ninstructs the browser to delete cached resources, cookies, and other client-side storage associated with the origin,\r\nhelping ensure a complete session cleanup.\r\nNote: The directive Cache-Control: no-cache=\"Set-Cookie, Set-Cookie2\" is sometimes suggested to\r\nprevent session ID caching. However, this syntax is not widely supported and may lead to unintended\r\nbehavior. Instead, use Cache-Control: no-store for stronger protection. Clear-Site-Data: cache\r\ncan be used to clear every stored response for a site in the browser cache, so use this with care. Note\r\nthat this will not affect shared or intermediate caches. Reference: MDN - Cache-Control and MDN -\r\nClear-Site-Data header\r\nReauthentication After Risk Events¶\r\nTo ensure session integrity and account protection, applications should require reauthentication when specific\r\nhigh-risk events are detected. These may include:\r\nAttempted or completed password changes\r\nLogin from a new or suspicious IP address or device\r\nCompletion of account recovery or challenge flows (e.g., hacked-lock scenarios)\r\nRequiring reauthentication helps mitigate session hijacking and unauthorized access—especially when long-lived\r\nsessions or external identity providers are in use.\r\nRecommended Practices:\r\nPrompt users for primary credentials (e.g., password) or enforce MFA\r\nProvide clear messaging explaining the need to reauthenticate\r\nAdditional Client-Side Defenses for Session Management¶\r\nWeb applications can complement the previously described session management defenses with additional\r\ncountermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and\r\nverifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer\r\nof defense that has to be bypassed by intruders.\r\nInitial Login Timeout¶\r\nWeb applications can use JavaScript code in the login page to evaluate and measure the amount of time since the\r\npage was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client\r\ncode can notify the user that the maximum amount of time to log in has passed and reload the login page, hence\r\nretrieving a new session ID.\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 14 of 17\n\nThis extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios\r\nwhere a previously used (or manually set) session ID is reused by the next victim using the same computer, for\r\nexample, in session fixation attacks.\r\nForce Session Logout On Web Browser Window Close Events¶\r\nWeb applications can use JavaScript code to capture all the web browser tab or window close (or even back)\r\nevents and take the appropriate actions to close the current session before closing the web browser, emulating that\r\nthe user has manually closed the session via the logout button.\r\nDisable Web Browser Cross-Tab Sessions¶\r\nWeb applications can use JavaScript code once the user has logged in and a session has been established to force\r\nthe user to re-authenticate if a new web browser tab or window is opened against the same web application. The\r\nweb application does not want to allow multiple web browser tabs or windows to share the same session.\r\nTherefore, the application tries to force the web browser to not share the same session ID simultaneously between\r\nthem.\r\nNOTE: This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are\r\nshared by all web browser tabs/windows.\r\nAutomatic Client Logout¶\r\nJavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions\r\nafter the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by\r\nthe logout button mentioned previously).\r\nThe benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see\r\nthat the session has finished due to inactivity, or even can be notified in advance that the session is about to expire\r\nthrough a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web\r\npages that require extensive input data due to server-side silently expired sessions.\r\nSession Attacks Detection¶\r\nSession ID Guessing and Brute Force Detection¶\r\nIf an attacker tries to guess or brute force a valid session ID, they need to launch multiple sequential requests\r\nagainst the target web application using different session IDs from a single (or set of) IP address(es). Additionally,\r\nif an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), they need to\r\nlaunch multiple sequential requests from a single (or set of) IP address(es) against the target web application to\r\ngather new valid session IDs.\r\nWeb applications must be able to detect both scenarios based on the number of attempts to gather (or use) different\r\nsession IDs and alert and/or block the offending IP address(es).\r\nDetecting Session ID Anomalies¶\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 15 of 17\n\nWeb applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The\r\nOWASP AppSensor Project provides a framework and methodology to implement built-in intrusion detection\r\ncapabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form\r\nof detection points and response actions. Instead of using external protection layers, sometimes the business logic\r\ndetails and advanced intelligence are only available from inside the web application, where it is possible to\r\nestablish multiple session related detection points, such as when an existing cookie is modified or deleted, a new\r\ncookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in\r\nthe middle of a session.\r\nBinding the Session ID to Other User Properties¶\r\nWith the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it\r\nis highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these\r\ndifferent properties in the middle of an established session, this is a very good indicator of session manipulation\r\nand hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.\r\nAlthough these properties cannot be used by web applications to trustingly defend against session attacks, they\r\nsignificantly increase the web application detection (and protection) capabilities. However, a skilled attacker can\r\nbypass these controls by reusing the same IP address assigned to the victim user by sharing the same network\r\n(very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very\r\ncommon in corporate environments), or by manually modifying the User-Agent to look exactly like the victim\r\nuser's.\r\nLogging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs¶\r\nWeb applications should increase their logging capabilities by including information regarding the full life cycle\r\nof sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and\r\ndestruction of session IDs, as well as details about its usage within login and logout operations, privilege level\r\nchanges within the session, timeout expiration, invalid session activities (when detected), and critical business\r\noperations during the session.\r\nThe log details might include a timestamp, source IP address, web target resource requested (and involved in a\r\nsession operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes\r\nand messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…).\r\nSensitive data like the session ID should not be included in the logs in order to protect the session logs against\r\nsession ID local or remote disclosure or unauthorized access. However, some kind of session-specific information\r\nmust be logged in order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the\r\nsession ID instead of the session ID itself in order to allow for session-specific log correlation without exposing\r\nthe session ID.\r\nIn particular, web applications must thoroughly protect administrative interfaces that allow to manage all the\r\ncurrent active sessions. Frequently these are used by support personnel to solve session related issues, or even\r\ngeneral issues, by impersonating the user and looking at the web application as the user does.\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 16 of 17\n\nThe session logs become one of the main web application intrusion detection data sources, and can also be used\r\nby intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or\r\nmany) attacks are detected. If active protections are implemented, these defensive actions must be logged too.\r\nSimultaneous Session Logons¶\r\nIt is the web application design decision to determine if multiple simultaneous logons from the same user are\r\nallowed from the same or from different client IP addresses. If the web application does not want to allow\r\nsimultaneous session logons, it must take effective actions after each new authentication event, implicitly\r\nterminating the previously available session, or asking the user (through the old, new or both sessions) about the\r\nsession that must remain active.\r\nIt is recommended for web applications to add user capabilities that allow checking the details of active sessions\r\nat any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate\r\nsessions manually, and track account activity history (logbook) by recording multiple client details such as IP\r\naddress, User-Agent, login date and time, idle time, etc.\r\nSession Management WAF Protections¶\r\nThere are situations where the web application source code is not available or cannot be modified, or when the\r\nchanges required to implement the multiple security recommendations and best practices detailed above imply a\r\nfull redesign of the web application architecture, and therefore, cannot be easily implemented in the short term.\r\nIn these scenarios, or to complement the web application defenses, and with the goal of keeping the web\r\napplication as secure as possible, it is recommended to use external protections such as Web Application Firewalls\r\n(WAFs) that can mitigate the session management threats already described.\r\nWeb Application Firewalls offer detection and protection capabilities against session based attacks. On the one\r\nhand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the Secure and\r\nHttpOnly flags, applying basic rewriting rules on the Set-Cookie header for all the web application responses\r\nthat set a new cookie.\r\nOn the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions,\r\nand the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the\r\nsession ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the\r\nrelationship between the session ID and other client properties, like the IP address or User-Agent), or managing\r\nsession expiration (by forcing both the client and the web application to finalize the session).\r\nThe open-source ModSecurity WAF, plus the OWASP Core Rule Set, provide capabilities to detect and apply\r\nsecurity cookie attributes, countermeasures against session fixation attacks, and session tracking features to\r\nenforce sticky sessions.\r\nSource: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nhttps://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html"
	],
	"report_names": [
		"Session_Management_Cheat_Sheet.html"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434678,
	"ts_updated_at": 1775826706,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3c318fe81f4961d60bacf626c7011886b078f697.pdf",
		"text": "https://archive.orkl.eu/3c318fe81f4961d60bacf626c7011886b078f697.txt",
		"img": "https://archive.orkl.eu/3c318fe81f4961d60bacf626c7011886b078f697.jpg"
	}
}