# CSRF Protection: Stop Unwanted Actions from Another Site

> CSRF makes an authenticated browser send an unwanted request. Use SameSite, tokens and origin checks as complementary controls.

- Canonical article: [https://www.metacyber.guru/articles/csrf-protection-guide](https://www.metacyber.guru/articles/csrf-protection-guide)
- Category: Website Security
- Author: Muhammad Azhar
- Published: August 14, 2026
- Last reviewed: 2026-08-14

Cross-site request forgery abuses a browser that is already authenticated. A malicious page causes the browser to send a state-changing request, and ambient cookies may make it look legitimate.

## Protect state changes

- Use unpredictable anti-CSRF tokens tied to the session.
- Set appropriate SameSite cookie attributes.
- Validate Origin or Referer for sensitive requests.
- Require reauthentication for high-impact changes.
- Never change state through GET requests.

## APIs need context

An API using Authorization headers instead of cookies has a different exposure. CORS is not a universal CSRF defence, and XSS can defeat many in-page controls.

## Test like a browser

Verify forms, JSON endpoints, multipart uploads and logout. Framework defaults help only when developers use the intended middleware correctly.

## Login CSRF exists too

An attacker may cause a victim to sign into the attacker's account, then collect information the victim unknowingly adds. Protect login and account-linking endpoints, not only obvious payment actions.

## Token handling

Do not place anti-CSRF tokens in URLs where logs and referrers may capture them. Compare tokens in constant time where appropriate and rotate them with session boundaries.

## Design state changes so browsers cannot trigger them casually

Use POST, PUT, PATCH or DELETE for mutations; never change account state through a GET link. Add framework-supported anti-CSRF tokens for cookie-authenticated forms and APIs, validate Origin or Referer where appropriate, and use SameSite cookies as defence in depth.

## APIs need a precise threat model

A bearer token supplied in an Authorization header is not automatically sent cross-site like a cookie, but unsafe storage can expose it to XSS. If the API authenticates with cookies, CORS does not replace CSRF protection. Protect login, logout and account-linking flows as well as payments.

Test with a page hosted on a different origin and confirm that the server rejects a forged action. A hidden form that “looks impossible” is still a valid attack tool.

## Sources and further reading

- [OWASP: CSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)
- [MDN: CSRF glossary](https://developer.mozilla.org/en-US/docs/Glossary/CSRF)

---

This Markdown edition is provided for language-model retrieval. The canonical human-readable page is the HTML article linked above.