What Is CSRF? Cross-Site Request Forgery Explained

Cross-site request forgery (CSRF) is an attack that makes a logged-in user's browser send a request the user never intended, such as changing an email address or adding an admin. Chromium-based browsers now hold back many cross-site cookies by default, but CSRF has not gone away. This guide explains how a CSRF attack works, what SameSite=Lax defaults really changed, how login CSRF and JSON APIs fit in, and which real CVEs show the pattern. It also covers how testers check for CSRF and the controls that prevent it.

What Is CSRF?

CSRF is a web vulnerability in which a malicious site causes a victim's browser to send an authenticated, state-changing request to another site where the victim is logged in. The target server sees a valid session cookie and processes the request as if the user meant it. MITRE catalogs it as CWE-352: Cross-Site Request Forgery.

It is also called XSRF or "sea-surf." MDN's CSRF guide sums up the three conditions that make a site vulnerable:

1. The request changes state. It updates an email address, a password, a payment, a setting or a user role.
2. The server relies only on cookies to authenticate it. The browser attaches those cookies automatically, whoever started the request.
3. Every parameter is predictable. Nothing in the request is secret or unique to the user's session, so an attacker can build it in advance.

Remove any one of those conditions and the attack fails. Every CSRF defense in this guide works by breaking one of them.

Where CSRF sits in the OWASP Top 10

CSRF does not have its own category in the current list. The OWASP Top 10:2025 A01 Broken Access Control page names CWE-352 among its notable weaknesses, next to server-side request forgery. That fits the bug: the server performs an action without confirming that the user actually asked for it. Our OWASP Top 10 guide walks through every 2025 category.

How a CSRF Attack Works

The example below is illustrative and uses reserved example domains. Imagine a web app at app.example.com that lets signed-in users change their account email with a simple form. The browser sends this request:

POST /account/email HTTP/1.1
Host: app.example.com
Cookie: session=<session-id>
Content-Type: application/x-www-form-urlencoded

email=user%40example.com

The server checks the session cookie, finds a logged-in user and updates the email. Nothing else in the request proves that the user clicked the button.

Now the attack, step by step:

1. The victim signs in to app.example.com, and the browser stores the session cookie.
2. The victim opens a page on another site, here attacker.example, through a link in an email, an ad or a forum post.
3. That page contains a form that targets app.example.com/account/email with an email address the attacker controls. A conceptual version looks like this:

<!-- Illustrative only: page hosted on attacker.example -->
<form action="https://app.example.com/account/email" method="POST">
  <input type="hidden" name="email" value="attacker@example.net">
</form>
<!-- A real attack submits this automatically; a lab test uses a visible button. -->

1. The browser sends the request and, if the cookie's SameSite rules allow it, attaches the victim's session cookie.
2. The server processes it. With no token and no origin check, it cannot tell this request from a real one, so the account email changes. A password reset to that address then hands the account to the attacker.

Notice what the attacker never touches. They do not steal the cookie, and the same-origin policy stops their page from reading the response. CSRF is a "blind" write: the attacker chooses the action, and the victim's browser supplies the identity.

What CSRF can and cannot do

Typical impact therefore depends on what the forged action does. Changing an email, password-recovery phone number or MFA setting can lead to account takeover. On an admin session it can create users, change security settings or, on some devices, run commands.

Why SameSite=Lax Defaults Changed the Landscape

For most of the web's history, browsers attached cookies to every request to a site, wherever it came from. That is exactly what CSRF exploits. The SameSite cookie attribute changed the rules by letting a site say when its cookies may travel with cross-site requests. According to MDN's Set-Cookie reference:

Third-party cookie blocking in some browsers can also stop None cookies, but that is a privacy feature you do not control. A "site" here is the registrable domain plus scheme, such as https://example.com. It is broader than an origin: shop.example.com and blog.example.com are different origins but the same site.

Lax by default: what Chromium shipped, and when

The big shift was making Lax the default for cookies that do not declare SameSite at all. Before that, a developer who did nothing got no protection. Google's SameSite updates page for Chromium records a bumpy rollout:

• February 4, 2020: Chrome 80 stable released, with enforcement starting for a limited population the week of February 17.
• April 3, 2020: Google temporarily rolled the enforcement back.
• July 14, 2020: enforcement resumed with Chrome 84 for Chrome 80 and later.
• August 11, 2020: the target was raised to 100% of Chrome 80+ stable users, ramping up gradually.
• March 18, 2021: the page records the behavior as the default, with the testing flags removed as of Chrome 91.

Other browsers did not all follow. MDN's browser compatibility data, checked on November 5, 2026, shows this:

The source data is the open MDN browser-compat-data project on GitHub. In plain terms, "browsers default to Lax" is only true for Chromium-based browsers. A Firefox or Safari user may still send a session cookie that has no SameSite attribute on a cross-site POST.

The two-minute exception

Chromium added a compatibility allowance it calls "Lax + POST." A cookie that has no SameSite attribute and is at most two minutes old can still be sent on a top-level cross-site POST. Chromium described the window as temporary, but MDN's Set-Cookie reference still documents it as of November 2026. A cookie explicitly set to SameSite=Lax does not get this allowance. That is one more reason to set the attribute yourself rather than rely on the default.

What Lax-by-default does not stop

The default raised the bar for lazy CSRF, and many old bugs stopped working in Chrome. But it does not protect every app, and the OWASP and MDN guidance both treat SameSite as defense in depth, not a complete fix. Gaps that remain:

• State changes on GET. Lax still sends cookies on top-level GET navigations, so a link that triggers GET /account/delete is still forgeable. Frameworks that let a GET be treated as a POST through a method-override parameter widen this gap.
• Same-site attackers. SameSite compares sites, not origins. A compromised or user-controlled subdomain, or one taken over through a dangling DNS record, counts as same-site.
• Non-Chromium users. As the table shows, Firefox and Safari do not ship Lax-by-default.
• Cookies set to SameSite=None. Single sign-on, embedded widgets and cross-site APIs often need None, and those cookies get no browser help.
• Fresh cookies inside the two-minute window, where the allowance still applies.
• Client-side CSRF. If your own JavaScript builds a request from attacker-controlled input such as the URL fragment, the request is same-origin and SameSite never applies.
• Non-cookie credentials sent automatically, such as HTTP Basic authentication or client certificates, which SameSite does not cover.

Login CSRF

Most CSRF talk is about forging actions inside a victim's session. Login CSRF works the other way around: the attacker forges a request to the login form with the attacker's own credentials, so the victim ends up signed in as the attacker.

The variant was named in 2008 by Stanford researchers Adam Barth, Collin Jackson and John C. Mitchell in "Robust Defenses for Cross-Site Request Forgery", presented at ACM CCS 2008. They reported that Yahoo, PayPal and Google were vulnerable at the time. The harm comes afterward. If the victim then saves a card, enters searches or uploads files, that data lands in an account the attacker controls. The same paper proposed the Origin request header, which browsers later adopted and which is now a core CSRF defense.

Login CSRF is easy to miss because the login form runs before there is a session to attach a token to. The OWASP CSRF Prevention Cheat Sheet recommends a pre-session that carries a token in the login form, then destroying it and issuing a new session after authentication to avoid session fixation.

Single sign-on adds its own version. In OAuth 2.0, an attacker can inject their own authorization code into a victim's callback so the victim's app links to the attacker's account. RFC 6749, Section 10.12 describes this as CSRF against the redirection URI. The current best practice, RFC 9700 (January 2025), says the long-established countermeasure is a random state value acting as a CSRF token, and that PKCE or the OpenID Connect nonce provides the same protection. A missing or unchecked state is still a common finding.

CSRF in JSON APIs and the Role of CORS

A common belief is that JSON APIs are immune to CSRF because an HTML form cannot send application/json. It is partly true, and the gaps are where real bugs live.

The key idea is the "simple request." An HTML form can send only three content types: application/x-www-form-urlencoded, multipart/form-data and text/plain. Requests like these go cross-origin without a CORS preflight. A request with Content-Type: application/json or a custom header is not simple, so the browser first asks the server for permission with a preflight. MDN's CSRF guide explains that a site using fetch() can defend itself by making sure state-changing requests are never simple requests.

That last row is the most important. CORS does not create CSRF protection; it relaxes the same-origin policy. MDN warns that a state-changing response is exposed to an origin when it lists that origin in Access-Control-Allow-Origin and also allows credentials. OWASP recommends allowing only a few specific origins you control and avoiding regex allowlists that cover every subdomain.

GraphQL endpoints are a frequent example, because one /graphql endpoint often accepts several content types and sometimes GET mutations. Our GraphQL API vulnerabilities guide covers the GraphQL-specific conditions. WebSockets have a close relative, cross-site WebSocket hijacking, explained in our WebSocket vulnerabilities guide.

Real-World CSRF Vulnerabilities

CSRF is not only a textbook bug. A query of the NVD API on November 5, 2026 returned five CVEs mapped to CWE-352 that CISA lists in its Known Exploited Vulnerabilities (KEV) catalog. Four of them, with one DeepStrike research case, show the pattern:

NVD records for each: CVE-2008-4128, CVE-2014-100005, CVE-2020-10181, CVE-2023-2533 and CVE-2025-63724.

Three lessons stand out:

• Admin interfaces are the prime target. Every case above needs an administrator's session, and the payoff is control of the device or application.
• Old CSRF bugs stay exploitable for years. The Cisco IOS flaw was published in 2008 and added to KEV in 2026. Embedded admin panels are rarely updated, and many are reached from browsers that have no reason to apply modern defaults to them.
• Impact goes beyond "change an email." The NVD records list CVSS 3.1 base scores of 8.0 for CVE-2014-100005 and 8.1 for CVE-2008-4128.

Case study: SVX Portal and CVE-2025-63724

DeepStrike published a technical write-up on SVX Portal 2.7A and CVE-2025-63724, and NVD lists that write-up as a reference for the CVE. The case is a useful lesson in classification and in how browser defaults decide real-world exposure.

• What NVD says. The NVD record describes the flaw as SQL injection through a crafted POST to admin/update_setings.php and maps it to CWE-89. The record lists a CVSS 3.1 base score of 6.0.
• What the code shows. Our write-up, clarified on November 3, 2026, explains that the endpoint escapes and quotes every value, so request data does not change the SQL structure. The real weakness is different: any POST field name that matches a stored setting overwrites that setting, there is no allowlist of editable settings, and there is no CSRF token. It maps more closely to missing control over modifiable fields (CWE-915) combined with CSRF (CWE-352). Our SQL injection guide shows what genuine SQL injection looks like by comparison.
• Why SameSite decides the risk. Without a token, the only barrier to a forged cross-site POST is whether the admin's browser sends the PHP session cookie. PHP's session.cookie_samesite setting is empty by default, which means no SameSite attribute is set, according to the PHP session configuration manual. In Chrome or Edge that cookie is treated as Lax and left off cross-site POSTs, apart from the two-minute allowance. In Firefox or Safari it is sent. The same deployment can therefore be exploitable for one admin and not for another, depending on their browser.

The fix in the advisory is the general fix: an allowlist of editable settings, a CSRF token on the settings form, prepared statements, and logging of every configuration change.

How to Prevent CSRF

No single control covers every case. The reliable approach is layered: a token or origin check that the server enforces, cookies that the browser restricts, and request design that leaves no simple path. The OWASP CSRF Prevention Cheat Sheet is the best single reference and underpins the advice below. For how CSRF fits alongside authentication, access control and input handling, see our web application security guide.

1. Use your framework's built-in CSRF protection

Most mature web frameworks include CSRF protection. OWASP's first recommendation is to check for it and turn it on before building anything custom. The common failures are not missing libraries. They are endpoints excluded from protection "temporarily," API routes added outside the protected middleware, and validation that only runs when a token is present.

2. Synchronizer tokens for stateful apps

The server generates a secret, unpredictable token, stores it in the user's session and embeds it in each form or page. Every state-changing request must return it in a hidden field or a custom header, and the server rejects any request where it is missing or does not match. OWASP's rules for tokens:

• Generate them with a cryptographically secure random source, unique per session or per request.
• Never put them in a URL or server logs.
• For this pattern, do not transmit the token in a cookie.
• Reject requests with no token, not only requests with a wrong one.

Per-request tokens are stricter but can break the browser's Back button. Per-session tokens are the usual compromise.

3. Signed double-submit cookies for stateless apps

When the server keeps no session state, the double-submit pattern sets a token in a cookie and requires the same value in a header or form field. OWASP now documents the naive version, a random value with no signature, "for reference only." Its weakness is that an attacker who can write cookies for your domain, for example from a sibling subdomain, can plant a matching pair. The recommended version is signed: an HMAC over a session-bound value with a server-side secret key, compared in constant time and sent with the Secure attribute.

4. Set SameSite explicitly and harden the session cookie

Do not rely on browser defaults. Set the attribute on every session cookie:

Set-Cookie: __Host-session=<session-id>; Path=/; Secure; HttpOnly; SameSite=Lax

Use Strict where the user experience allows it, and Lax where users must arrive logged in from links on other sites. The __Host- prefix forces the cookie to be host-only and Secure with Path=/, which stops subdomains from overwriting it. Treat all of this as defense in depth, not a replacement for steps 2 and 3.

5. Verify the Origin, with Referer as a fallback

Browsers send an Origin header on cross-origin requests and on POST requests. The server compares it with its own origin and rejects mismatches. If Origin is missing, OWASP suggests checking the hostname in Referer. Three rules matter:

• Compare the whole origin. A prefix or substring match lets app.example.com.attacker.example through.
• Do not treat a missing header or Origin: null as proof of a same-origin request.
• Behind a proxy, compare against a configured origin rather than a client-controllable Host header.

6. Add a Fetch Metadata policy

Modern browsers send a Sec-Fetch-Site header on every request with one of four values: same-origin, same-site, cross-site or none (a user action such as typing the URL or opening a bookmark). According to MDN's compatibility data, Chrome has sent it since version 76, Firefox since version 90 and Safari since version 16.4. Google's web.dev guide to Fetch Metadata calls the resulting check a Resource Isolation Policy.

OWASP's recommended policy is to reject unsafe methods (POST, PUT, PATCH, DELETE) when the value is cross-site, allow same-origin, and treat same-site carefully unless you trust every subdomain. Because older clients may not send the header, a fallback such as the Origin check is mandatory. Run the policy in log-only mode first, and include the Sec-Fetch headers in Vary if responses are cached. The full header set is defined in the W3C Fetch Metadata Request Headers specification.

The sketch below is illustrative, not a drop-in library. It shows how the checks fit together in a Python web app:

# Illustrative sketch: layered CSRF check for state-changing requests.
import hmac

TRUSTED_ORIGIN = "https://app.example.com"   # configured, not taken from Host
UNSAFE = {"POST", "PUT", "PATCH", "DELETE"}

def csrf_allowed(method, headers, session_token, submitted_token):
    if method not in UNSAFE:
        return True                       # GET must never change state

    site = headers.get("Sec-Fetch-Site")
    if site == "cross-site":
        return False                      # Fetch Metadata: block cross-site writes
    if site is None:                      # older client: fall back to Origin
        origin = headers.get("Origin")
        if origin is None or origin == "null" or origin != TRUSTED_ORIGIN:
            return False

    # Token check still runs for every unsafe request.
    if not session_token or not submitted_token:
        return False
    return hmac.compare_digest(session_token, submitted_token)

7. Design APIs so forged requests cannot be simple

For JSON APIs, require Content-Type: application/json and reject everything else, including text/plain. Or require a custom header that a cross-site page cannot send without a preflight. Keep the CORS allowlist to exact origins you control and never combine a reflected origin with credentials. Prefer bearer tokens in the Authorization header over cookies for APIs called by first-party JavaScript, where that fits your architecture.

8. Keep GET safe and confirm sensitive actions

Never change state on GET, HEAD or OPTIONS. For high-impact actions such as changing an email, password, MFA setting or payout account, require re-authentication or a one-time code. That limits the damage of an endpoint someone forgot to protect. OWASP specifically advises against relying on a CAPTCHA as a CSRF defense.

9. Fix XSS, because it defeats every CSRF defense

OWASP's cheat sheet puts it bluntly: cross-site scripting can defeat all CSRF mitigation techniques. Script running in your origin can read the token from the page and send requests that are same-origin by definition. CSRF defenses only hold if your XSS defenses do too. Our cross-site scripting (XSS) guide covers those.

CSRF prevention checklist

Where these checks belong in the development lifecycle, from design review to pre-release testing, is covered in our secure SDLC guide.

How Penetration Testers Check for CSRF (Lab-Safe)

CSRF testing is low-risk compared with many web tests, but it still changes data by definition. Professional testing follows a few rules: written authorization, test accounts the tester owns, and forged requests aimed only at a lab or staging environment, never at real users' sessions. The OWASP Web Security Testing Guide section on CSRF is the standard reference. The workflow below is a method, not a payload list.

Step 1: Map every state-changing action

Testers list each request that changes something: profile, email, password, MFA, roles, payments, integrations, API keys, admin settings, and the login and logout flows. For each one they record the HTTP method, the content type, how the user is authenticated (cookie, header token or both) and any token parameter.

Step 2: Inspect cookies and authentication

The tester checks each session cookie's SameSite, Secure and HttpOnly attributes and whether it uses a __Host- prefix. A cookie with no SameSite attribute is a signal to test in more than one browser engine. If authentication uses only an Authorization header that the app's JavaScript sets, classic CSRF is unlikely, and the effort moves to how that token is stored.

Step 3: Test how the server handles tokens and origins

Using their own test account, testers replay a legitimate request with one change at a time and record whether the server still accepts it:

• Token removed entirely
• Token replaced with a random value
• Token taken from a second test account's session
• Same action sent with a different method, such as GET instead of POST
• JSON endpoint called with a form-encoded or text/plain body
• Origin header changed to a foreign site, set to null or removed

Any accepted variant is a candidate finding. DeepStrike's client-side vulnerabilities write-up describes one such case, where the server issued CSRF tokens but did not reject requests with a missing or altered token.

Step 4: Prove it cross-site in a lab

A candidate becomes a finding when a request from a different site really works. The tester hosts a minimal test page on a domain they control, like the example form earlier, and opens it in a browser signed in to the lab app with a test account. Because defaults differ, this step is repeated in a Chromium-based browser and in Firefox or Safari. A result such as "exploitable in Firefox and Safari, blocked by Lax-by-default in Chrome" is still a valid finding, with severity adjusted for the user base.

Step 5: Check login CSRF, OAuth and CORS

Testers check whether the login form accepts a cross-site submission, whether OAuth callbacks verify state (or PKCE or a nonce), and whether CORS reflects arbitrary origins with credentials. That last issue can turn a write-only CSRF into a full read of the victim's data.

Step 6: Report impact and retest

A useful CSRF finding names the endpoint and action, shows which checks failed, states the browsers in which it was reproduced, and explains the realistic impact. A forged email change that enables account takeover is rated very differently from a forged newsletter preference. After the fix, the same lab test is repeated to confirm rejection.

CSRF vs XSS vs SSRF

The three names sound alike, and all three abuse trust, but they abuse different trust in different places.

They also chain. XSS defeats CSRF defenses because script in your origin can read tokens. CSRF does not run script by itself, but it can submit a value that a separate stored-XSS bug later renders. SSRF is the server-side mirror image of CSRF: in SSRF the forged request comes from your server, as explained in our guide to server-side request forgery.

These three are among the most common web vulnerabilities we see described in public research, and access-control bugs such as insecure direct object references (IDOR) often sit next to them in the same features.

Frequently Asked Questions

What is CSRF in simple terms?

CSRF is when a website you visit secretly makes your browser send a request to another site where you are logged in. Your browser adds your login cookie automatically, so the other site thinks you asked for the action, such as changing your email or password.

What is a CSRF token?

A CSRF token is a secret, unpredictable value the server puts in each form or page and requires back with every state-changing request. A malicious site cannot read or guess it, so forged requests arrive without a valid token and the server rejects them.

Does SameSite=Lax prevent CSRF?

It blocks the most common form, a cross-site POST, but it is not a complete defense. Lax still allows cookies on cross-site GET navigations, treats subdomains as the same site, and is only the default in Chromium-based browsers. Firefox and Safari do not apply it to cookies that lack the attribute. Use it with tokens or origin checks.

What is the difference between CSRF and XSS?

CSRF makes the victim's browser send a request from another site and cannot read the response. XSS runs attacker script inside your site, so it can read pages and act freely as the user. XSS can bypass CSRF defenses by reading the token.

Are JSON APIs vulnerable to CSRF?

They can be. An API that strictly requires application/json or a custom header, or that authenticates with a bearer token in the Authorization header, resists classic CSRF. One that also accepts form or text/plain bodies, or has a CORS policy that trusts any origin with credentials, is vulnerable.

How do I fix a "CSRF token missing" error?

That error usually means the protection is working and the request did not include the token. Make sure the form or JavaScript sends the token the framework issued, in the field or header it expects, and that the session cookie is being sent. Do not fix it by disabling CSRF protection on the endpoint.

Is CSRF still in the OWASP Top 10?

Yes, as part of a broader category. In the OWASP Top 10:2025, CWE-352 Cross-Site Request Forgery is listed under A01:2025 Broken Access Control.

Next Step: Test Your App for CSRF Across Browsers

CSRF looks solved until you check. Browser defaults protect some users and not others, new API routes skip middleware, and a single permissive CORS rule can undo every token. The checks that matter are concrete: which actions accept a request without a valid token, which cookies lack an explicit SameSite attribute, and which browsers your users actually run.

DeepStrike's web application penetration testing services combine automated discovery with rigorous manual testing aligned to the OWASP Top 10. Only vulnerabilities validated through exploitation are reported, each with actionable remediation steps. To scope a test, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

MITRE CWE-352: Cross-Site Request Forgery (CSRF)

OWASP Top 10:2025 A01 Broken Access Control

OWASP Cross-Site Request Forgery Prevention Cheat Sheet

OWASP Web Security Testing Guide: Testing for Cross Site Request Forgery

MDN: Cross-site request forgery (CSRF)

MDN: Set-Cookie header reference

MDN browser-compat-data (GitHub)

Chromium: SameSite Updates

web.dev: Protect your resources from web attacks with Fetch Metadata

W3C: Fetch Metadata Request Headers

Barth, Jackson and Mitchell: Robust Defenses for Cross-Site Request Forgery (ACM CCS 2008)

RFC 6749: The OAuth 2.0 Authorization Framework

RFC 9700: Best Current Practice for OAuth 2.0 Security (January 2025)

PHP Manual: Session runtime configuration

NVD: CVE-2008-4128

NVD: CVE-2014-100005

NVD: CVE-2020-10181

NVD: CVE-2023-2533

NVD: CVE-2025-63724