ASD ISM 2064 Ensure secure cookies with signed bearer tokens
What it says
Web application session cookies contain only digitally signed opaque bearer tokens.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWeb cookies should use signed tokens to prevent tampering and ensure security.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
Ensure cookies store only signed opaque bearer tokens; validate signatures on every request and alert on repeated invalid or altered token submissions.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Recent security assessment reports on the web application: Request any documentation showing an audit of cookie security practices.
Look at
Evidence of checks on the implementation of signed bearer tokens.
Good evidence
A report detailing checks performed, whether bearer tokens are signed, and actions taken to resolve any issues found.
- Check 2 of 5What an auditor asks for
Look at
The server configuration files or screenshots demonstrating secure cookie settings.
Good evidence
Documentation showing cookies are only transferred over HTTPS and are marked as secure and HTTP only.
- Check 3 of 5What an auditor asks for
Ask for
A demonstration of cookie-handling practices: Request someone from the IT team to walk you through how cookies are generated and verified.
Look at
The use of secure algorithms in the demonstration.
Good evidence
A live demonstration showing cookies are signed with a digital tool, and tampered cookies are rejected.
- Check 4 of 5What an auditor asks for
Ask for
Training records on secure cookie management for relevant staff.
Look at
Evidence of recent training sessions conducted.
Good evidence
Training logs or certificates showing who attended, content covered, and the date of the training.
- Check 5 of 5What an auditor asks for
Look at
The inclusion of security reviews for each application.
Good evidence
A current list that includes application names, compliance status, and any action items for non-compliant apps.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.25.
ISM-2064 addresses a specific secure session design: preventing cookie tampering by using digitally signed opaque bearer tokens. Annex A 8.25 requires establishing and applying secure development rules (secure SDLC), under which secure authentication/session management patterns such as signed session tokens would normally be mandated and verified. ISM-2064 is one specific SDLC control outcome, while Annex A 8.25 spans the full lifecycle and many other secure engineering rules.
This control partially meets 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.26 requires organisations to identify, specify and approve application security requirements, which is the governance mechanism by which a requirement like ISM-2064 would be captured for a web application. ISM-2064 is an implementation-level requirement, whereas Annex A 8.26 covers the broader requirements-definition process across applications.
This control partially meets A.8.28.
ISM-2064 requires that web application session cookies contain only digitally signed opaque bearer tokens to prevent tampering. Annex A 8.28 mandates applying secure coding principles, which would include correctly implementing tamper-resistant session management (e.g. signed tokens/cookies). ISM-2064 is a specific technical pattern for cookies, while Annex A 8.28 is broader across all coding practices and defect classes.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.