Ensure Secure Cookies with Signed Bearer Tokens
Web cookies should use signed tokens to prevent tampering and ensure security.
Plain language
This control is about making sure that the web cookies used for logging into a website are secure and can't be tampered with by bad actors. If we don't do this, hackers might alter these cookies to impersonate users, leading to data breaches or unauthorised access to sensitive information.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentSection
Web application developmentOfficial control statement
Web application session cookies contain only digitally signed opaque bearer tokens.
Why it matters
If session cookies are not limited to digitally signed opaque bearer tokens, attackers can tamper with them to hijack sessions and access data.
Operational notes
Ensure cookies store only signed opaque bearer tokens; validate signatures on every request and alert on repeated invalid or altered token submissions.
Implementation tips
- Web developers should ensure that all session cookies are only using signed bearer tokens. This means they need to apply digital signatures to cookies so that any change in their content can be detected.
- IT teams should regularly audit the code for the web applications to confirm that it implements secure cookie practices. This involves checking that session cookies don't hold open text information; instead, they should be opaque and signed.
- System administrators should configure web servers to only accept secure cookies over HTTPS connections. This can be done by setting your server or application configuration to flag cookies as secure and ensuring irrelevant traffic is redirected from HTTP to HTTPS.
- Project managers should allocate resources to train web development staff about the importance of securing cookies, especially in sensitive applications. Arrange a workshop with an expert in cyber security to explain common threats and demonstrate how to implement secure cookies effectively.
- Security officers should periodically review the latest best practices for cookie security as provided by reputable sources like the Australian Cyber Security Centre (ACSC). This includes staying updated on the latest guidelines and ensuring that the organisation's practices align with these recommendations.
Audit / evidence tips
-
Askrecent security assessment reports on the web application: Request any documentation showing an audit of cookie security practices
GoodA report detailing checks performed, whether bearer tokens are signed, and actions taken to resolve any issues found
-
GoodDocumentation showing cookies are only transferred over HTTPS and are marked as secure and HTTP only
-
Aska demonstration of cookie-handling practices: Request someone from the IT team to walk you through how cookies are generated and verified
GoodA live demonstration showing cookies are signed with a digital tool, and tampered cookies are rejected
-
Asktraining records on secure cookie management for relevant staff
GoodTraining logs or certificates showing who attended, content covered, and the date of the training
-
GoodA current list that includes application names, compliance status, and any action items for non-compliant apps
Cross-framework mappings
How ISM-2064 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (3) expand_less | ||
| Annex A 8.25 | ISM-2064 addresses a specific secure session design: preventing cookie tampering by using digitally signed opaque bearer tokens | |
| Annex A 8.26 | ISM-2064 specifies a concrete security requirement for web sessions: cookies must only carry digitally signed opaque bearer tokens | |
| Annex A 8.28 | ISM-2064 requires that web application session cookies contain only digitally signed opaque bearer tokens to prevent tampering | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.