CWE-1275 covers sensitive cookies that do not set the SameSite attribute, or that set an insecure value. Any web application that uses cookies for sessions or other sensitive state is in scope.
How it happens
The SameSite attribute controls how cookies are sent on cross-domain requests. It takes three values: Lax, Strict or None.
With None, another website can create a cross-domain POST request to your site, and the browser automatically attaches your cookies. If you have no other protection, such as anti-CSRF tokens, that can lead to Cross-Site Request Forgery (CSRF) attacks.
So the weakness is not exactly a broken cookie. It is a missing layer. The cookie is sent in contexts where it should not be, and the application then has to be perfect everywhere else.
The recorded example is CVE-2022-24045. A web application for a room automation system had client-side JavaScript that set a sensitive cookie without the SameSite attribute.
Vulnerable and fixed
A Node.js Express sketch that sets a session cookie with no SameSite value:
// Vulnerable: no SameSite, no Secure, readable by scripts
res.cookie("session", token);
A safer version:
// Safer: Lax blocks most cross-site sends, Secure and HttpOnly add more
res.cookie("session", token, {
sameSite: "lax", // use "strict" if your flows allow it
secure: true,
httpOnly: true
});
The same idea in a raw header:
Set-Cookie: session=abc123; SameSite=Lax; Secure; HttpOnly
Secure and HttpOnly are separate attributes from SameSite. They are shown here because they belong on the same cookie, though the CWE itself concerns SameSite.
What an attacker gains
MITRE records impact on confidentiality, integrity, non-repudiation and access control, through modification of application data. The likelihood of an integrity breach is rated Low, and it applies when the site has no other defense against CSRF. In plain terms, an attacker can trick a logged in user's browser into submitting a request the user never intended.
How to find it
MITRE notes that automated static analysis (SAST) can find some instances by analyzing source code without running it.
Simple checks you can do today:
- Open browser developer tools, go to the storage or application tab and list your cookies. Note which have a SameSite value.
- Grep your code for every place cookies are set, including client-side JavaScript. The CVE above was a cookie set in JavaScript.
- Run a dynamic scan against a staging site and review the cookie findings.
- Check any framework default, since defaults differ and have changed over time. Set the attribute explicitly rather than rely on one.
How to fix it
The record lists no mitigation text. The description points to the fix.
- Set SameSite to Lax or Strict on every sensitive cookie. Strict sends the cookie only on same-site requests. Lax is a common balance because it keeps normal top level navigation working.
- Use None only when you truly need cross-site sending, for example an embedded widget, and pair it with anti-CSRF tokens.
- Keep anti-CSRF tokens on state changing requests regardless. SameSite is one layer, not the whole defense.
- Set cookies on the server where you can, so one place controls the attributes.
- Add a test that fails when a sensitive cookie is missing SameSite.
Try it yourself
This kind of cookie issue shows up in a dynamic scan of a running web app. The demo walks through one.
Click through it at your own pace, or open it full screen.
Quick check
Which SameSite value is the risky one?
None, because the browser then attaches cookies to cross-domain requests such as a POST from another site. A missing attribute is also a gap worth closing explicitly.
Does SameSite replace anti-CSRF tokens?
No. MITRE's wording is that the risk applies when there are no additional protections such as anti-CSRF tokens. Use both.
