Skip to content

CSRF cheat sheet: clarify SameSite limitations and fix pseudocode syntax highlighting #2080

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Copilot wants to merge 2 commits into
base: master
Choose a base branch
from
Open

CSRF cheat sheet: clarify SameSite limitations and fix pseudocode syntax highlighting #2080

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
94feeb6
Initial plan
Copilot Mar 26, 2026
07429a9
Fix CSRF cheat sheet: update SameSite limitations and pseudocode synt…
Copilot Mar 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,7 +96,7 @@ It's a common misconception to include timestamps as a value to specify the CSRF

Below is an example in pseudo-code that demonstrates the implementation steps described above:

```code
```javascript
// Gather the values
secret = getSecretSecurely("CSRF_SECRET") // HMAC secret key
sessionID = session.sessionID // Current authenticated user session
Expand All @@ -116,7 +116,7 @@ response.setCookie("csrf_token=" + csrfToken + "; Secure") // Set Cookie without

Below is an example in pseudo-code that demonstrates validation of the CSRF token once it is sent back from the client:

```code
```javascript
// Get the CSRF token from the request
csrfToken = request.getParameter("csrf_token") // From header or form field (NOT cookie)

Expand Down Expand Up @@ -419,7 +419,13 @@ Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax

All modern desktop and mobile browsers support the `SameSite` attribute. The main exceptions are legacy browsers including Opera Mini (all versions), UC Browser for Android, and older mobile browsers (iOS Safari < 13.2, Android Browser < 97). To track the browsers implementing it and know how the attribute is used, refer to the following [service](https://caniuse.com/#feat=same-site-cookie-attribute). Chrome implemented `SameSite=Lax` as the default behavior in 2020, and Firefox and Edge have followed suit. Additionally, the `Secure` flag is required for cookies that are marked as `SameSite=None`.

It is important to note that this attribute should be implemented as an additional layer _defense in depth_ concept. This attribute protects the user through the browsers supporting it, and it contains as well 2 ways to bypass it as mentioned in the following [section](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.3.7.1). This attribute should not replace a CSRF Token. Instead, it should co-exist with that token to protect the user in a more robust way.
It is important to note that this attribute should be implemented as an additional layer of _defense in depth_. This attribute protects the user through browsers supporting it, but has important limitations:

- **`SameSite=Lax` does not protect state-changing `GET` requests**: `SameSite=Lax` only blocks cookies on cross-site requests that use unsafe HTTP methods (e.g., `POST`, `PUT`, `DELETE`). Cross-site top-level navigations using safe methods (`GET`, `HEAD`, `OPTIONS`) still transmit cookies under `Lax`. If your application performs any state-changing operations via `GET` requests (which is itself strongly discouraged), `SameSite=Lax` will not protect those endpoints.
Copy link
Copy Markdown
Member

@jmanico jmanico Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first bullet is correct, with one nuance. Under SameSite=Lax, cookies are sent on cross-site top-level navigations that use a safe method, including GET; that means a state-changing GET endpoint would still be exposed.

Also, when Lax is applied as a browser default rather than explicitly set, some browsers use a temporarily more permissive variant that may also send cookies on certain recent cross-site POST requests.


- **Subdomain and sibling-domain vulnerabilities**: `SameSite` can be bypassed if any subdomain or sibling domain of your application is compromised (e.g., via XSS, HTML injection, or a [subdomain takeover](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover) attack). A subdomain is considered "same-site", so an attacker controlling `vulnerable.example.com` can inject or overwrite cookies that are sent to `example.com`, defeating `SameSite` protection entirely. This is a significant risk on SaaS platforms where multiple tenants share a domain.
Copy link
Copy Markdown
Member

@jmanico jmanico Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Brief note, “inject or overwrite cookies sent to example.com” is accurate primarily when cookies are domain-scoped; it is less accurate for properly host-only cookies, especially __Host- cookies.


This attribute should not replace a CSRF Token. Instead, it should co-exist with that token to protect the user in a more robust way.

### Using Standard Headers to Verify Origin

Expand Down
Loading