Cross-Site Request Forgery: How CSRF Works and How to Stop It

Cross-site request forgery does not steal a session. It borrows one the browser is already holding.

What Is Cross-Site Request Forgery?

CSRF, sometimes written XSRF, tricks a browser into sending a request the user never intended, to a site where they are already authenticated.

CSRF works because browsers can automatically attach session cookies to requests when cookie and SameSite rules allow it, even when another site triggered the request. Modern SameSite controls prevent many traditional cross-site cookie requests. (MDN Web Docs)

The attacker usually cannot read the response because of the same-origin policy. CSRF therefore typically focuses on making the victim perform an unwanted action rather than directly stealing the response.

How Does a CSRF Attack Work?

1. The victim is logged in to the target application
2. The victim visits a page the attacker controls
3. That page issues a request to the target
4. The browser attaches the session cookie
5. The application processes it as the authenticated user

What Can It Actually Do?

Any sensitive action the victim is authorised to perform may be vulnerable if the endpoint lacks effective CSRF protection: transferring funds, changing a password, updating an email address, altering privacy settings, or creating an administrative user.

Email, password-recovery, payment, and account-management actions are particularly important because a successful CSRF against them can sometimes lead to account takeover or financial impact.

Delivery varies with the endpoint. A state-changing GET can sometimes be triggered through a link or subresource request when authentication cookies are included. This is one reason GET requests should never change application state. With SameSite=Lax, cookies are generally sent on cross-site top-level safe navigations, but not ordinary cross-site image requests. (MDN Web Docs)

A POST-based request uses a hidden form that submits on page load. JSON and API endpoints are not automatically immune. If an endpoint accepts browser-simple content types or otherwise allows a cross-site request without requiring a protected token or custom header, CSRF may still be possible. PortSwigger specifically notes that content-type requirements can determine whether a browser can construct a practical CSRF request. (PortSwigger)

Why Does It Matter?

CSRF is not a standalone category in the current OWASP Top 10:2025. CWE-352 remains included under A01:2025 Broken Access Control, which retains the number-one position. (OWASP Foundation)

Modern frameworks commonly provide built-in CSRF protections, while modern browsers generally treat cookies without an explicit SameSite value as Lax. These changes block many traditional CSRF techniques but do not remove the need for server-side protection. (MDN Web Docs)

That is why the cases that remain go unnoticed: legacy endpoints, custom handlers, and APIs written outside the framework's protections.

Common Mistakes

• Relying on SameSite alone. SameSite=Lax blocks cookies from most cross-site requests but still permits them on qualifying top-level navigations using safe methods such as GET. SameSite also works on the concept of a site rather than a strict origin. (MDN Web Docs)
• Using naive double-submit cookies. OWASP recommends a signed, session-bound double-submit cookie because the naive pattern can be vulnerable when an attacker can inject or manipulate cookies. (OWASP Cheat Sheet Series)
• Relying loosely on Origin or Referer checks. OWASP supports origin verification as a CSRF defence, but applications need a defined policy for requests where those headers are missing and should normally combine it with other protections. (OWASP Cheat Sheet Series)

How to Reduce the Risk

• Use your framework's built-in CSRF protection
• Apply synchronizer tokens for stateful applications
• Bind the token to the session, and reject missing or invalid tokens
• Use Fetch Metadata headers such as Sec-Fetch-Site to reject clearly cross-site state-changing requests, with Origin/Referer verification as a fallback for clients that do not provide Fetch Metadata. This matches OWASP's current recommendation. (OWASP Cheat Sheet Series)
• For API-driven applications, require a custom request header and configure CORS to permit only explicitly trusted origins. Browser requests carrying custom headers require a CORS preflight, which provides an additional CSRF barrier. (OWASP Cheat Sheet Series)
• Re-authenticate or require MFA for high-impact actions

What Should Security Testing Cover?

Ask your testers to establish:

• Whether removing the CSRF token still results in a successful request
• Whether a token from another session is accepted
• Whether any state-changing action is reachable by GET

Burp Suite's CSRF PoC generator can reproduce browser-based CSRF requests, while ZAP can detect and handle anti-CSRF tokens during testing. Manual validation is still important. (PortSwigger)

How OraSec Can Help

CSRF sits between application logic and access control, where automated scanners are weakest. OraSec's web application and API testing covers state-changing endpoints with a demonstrated request, not a flagged pattern.

Conclusion

CSRF survives because it needs nothing broken. It uses a working session, a valid request, and a browser doing exactly what it was designed to do.

FAQs

What is the difference between CSRF and XSS? XSS runs attacker-controlled script in your site's origin. CSRF sends a legitimate-looking request from somewhere else. XSS can defeat CSRF defences; the reverse is not true.

Does SameSite=Lax fix CSRF? It blocks many traditional cross-site requests, but it still allows cookies on qualifying top-level safe navigations and has other edge cases. OWASP generally recommends treating SameSite as defence in depth unless strict conditions are met. (OWASP Cheat Sheet Series)