Classification noteMITRE classifies Cross-Site Request Forgery as CWE-352. In the OWASP Top 10:2025, CWE-352 is mapped under A01: Broken Access Control.
What Is CSRF (Cross-Site Request Forgery)?
CSRF is an intent-validation failure: the application receives a request carrying valid browser credentials but does not have enough evidence that the authenticated user intentionally initiated that request.
The attack works because browsers automatically attach some credentials, especially cookies, when requests meet the cookie’s delivery rules. An attacker does not need to steal the victim’s session first. Instead, the attacker tries to make the victim’s browser send a request that the target application will accept as authenticated.
| Element | Role in CSRF |
|---|---|
| Victim browser | Carries session or other browser-managed authority accepted by the target application |
| Attacker-controlled context | Causes the browser to initiate a request the user did not intend |
| Automatically supplied credentials | Make the forged request appear authenticated to the application |
| State-changing endpoint | Performs an action such as changing account data, creating a resource, or modifying settings |
| Missing intent validation | Allows the application to accept the forged request without a trusted CSRF signal |
CSRF belongs to the broader family of cyber security vulnerabilities. Unlike XSS, CSRF does not require attacker-controlled JavaScript to execute inside the target application’s origin. The forged request can succeed simply because the browser supplies authority that the server trusts.
How Does CSRF Work?
CSRF works in four steps: the victim already has browser-held authority, an attacker causes a request to the target application, the browser automatically includes accepted credentials, and the application performs the action without verifying user intent.
- The victim has an active session or browser-held authority. The browser already has a session cookie or another credential the target application accepts automatically.
- The attacker causes a request to the target application. The victim loads an attacker-controlled page, follows a crafted link, submits a cross-site form, or reaches another context capable of initiating the request.
- The browser attaches credentials according to its normal rules. If the session cookie or other authority is sent with the request, the target application sees an authenticated request.
- The application performs the action. If the endpoint lacks an effective CSRF token, origin check, Fetch Metadata policy, SameSite protection, or another intent-validation control, the forged request may be accepted.
| Stage | What Happens |
|---|---|
| Attacker-controlled context | Creates or triggers a request toward the target application |
| Victim browser | Processes the cross-site request |
| Automatic credentials | Browser adds session cookies or other accepted ambient credentials when policy allows |
| State-changing action | Application accepts the request because authentication is present but user intent was not sufficiently verified |
Why Doesn’t the Same-Origin Policy Stop CSRF?
The Same-Origin Policy does not stop all CSRF because it mainly restricts what one origin can read or interact with across origins; it does not universally prevent a browser from sending cross-origin requests. Traditional HTML forms, for example, can submit simple cross-origin requests.
This creates the classic CSRF condition: the attacker may be unable to read the protected response, but can still cause the victim’s browser to send a state-changing request. That is why CSRF is usually a one-way request attack rather than a response-reading attack.
What Conditions Make a CSRF Attack Possible?
A practical CSRF attack usually needs four conditions: a meaningful state-changing action, browser-held authority, a request the attacker can reproduce cross-site, and missing or ineffective request-intent validation.
| Requirement | Why It Matters |
|---|---|
| State-changing action | There must be an operation worth triggering, such as changing account details or creating a privileged resource |
| Browser-held authority | The browser must automatically supply credentials or another accepted form of authority |
| Forgeable request | The attacker must be able to reproduce the required method, parameters, or content from a cross-site context |
| Missing intent validation | The server does not require a valid anti-CSRF token, trusted origin evidence, Fetch Metadata signal, or equivalent protection |
A missing CSRF token by itself does not prove that an endpoint is vulnerable. The request may still be protected by SameSite cookie behavior, strict origin validation, Fetch Metadata enforcement, a custom-header requirement, or another effective control. A valid finding must establish that the state-changing request can actually be forged under the application’s real browser and authentication conditions.
CSRF Example
A simple CSRF example is an account-settings endpoint that accepts a state-changing request while trusting only the user’s session cookie.
Suppose a logged-in user legitimately changes an email address through a request conceptually like this:
POST /account/change-email
[email protected]If the application accepts the request solely because the browser includes the user’s session cookie, another site may be able to cause the browser to send the same kind of request with an attacker-chosen email value. The attacker does not need to know the session cookie; the browser may attach it automatically.
A properly protected endpoint requires additional evidence that the request came from an authorized application flow, such as a valid CSRF token, an accepted origin, Fetch Metadata checks, or another control appropriate to the application’s architecture.
What Can an Attacker Do With CSRF?
An attacker can use CSRF to perform actions the victim is authorized to perform, so the impact is limited mainly by the victim’s privileges and the operations the vulnerable endpoint exposes.
- Change account details: email address, profile information, delivery address, or recovery settings.
- Modify security settings: password-reset configuration, notification settings, connected applications, or API-related settings.
- Create or delete resources: projects, posts, users, keys, or application objects.
- Trigger purchases or transfers: when sensitive actions do not require stronger transaction confirmation.
- Perform administrative actions: if the victim is a privileged user and the affected operation accepts forged requests.
CSRF does not normally give the attacker direct access to the protected response body. Its strength comes from causing an authenticated browser to perform an action, not from bypassing the browser’s cross-origin read restrictions.
Common CSRF Scenarios
The most useful CSRF scenarios to distinguish are traditional action CSRF, login CSRF, and client-side CSRF. These describe different request flows rather than a universal three-type taxonomy.
Traditional CSRF
Traditional CSRF causes an already authorized browser to perform a state-changing action the user did not intend. The classic case is a cross-site form or navigation reaching a cookie-authenticated endpoint that lacks sufficient request-intent validation.
Login CSRF
Login CSRF targets the authentication flow itself. Instead of abusing an existing victim session, the attacker causes the victim’s browser to log into an account or session chosen by the attacker. The victim may then unknowingly place personal data into that attacker-associated account or continue activity inside the wrong session.
Login endpoints therefore should not be assumed safe merely because the user is not authenticated yet. OWASP recommends protecting login flows where CSRF would create a meaningful security problem.
Client-Side CSRF
Client-side CSRF occurs when attacker-controlled data influences the legitimate application’s own JavaScript and causes that JavaScript to construct an unintended request. This is important because the application’s script may automatically attach valid CSRF tokens, custom headers, or other trusted request data.
The flow is different from classical CSRF:
attacker-controlled URL or input → legitimate application JavaScript → unintended request built by trusted client code
Preventing this requires validating client-side inputs and avoiding code paths where untrusted URL fragments, query parameters, or messages can directly choose sensitive endpoints or request data.
What Is a CSRF Token and How Does It Work?
A CSRF token is an unpredictable value that the server requires on sensitive requests so that valid browser credentials alone are not enough to authorize the action.
The attacker may be able to cause the browser to submit a request, but should not be able to read a token generated inside the protected application and reproduce that token correctly from another origin.
Synchronizer Token Pattern
The synchronizer token pattern stores or associates an unpredictable token with the user’s server-side session. The application includes that token in protected forms or application-generated requests and rejects state-changing requests that do not present a valid value.
A good token should be cryptographically unpredictable, tied appropriately to the user’s session or request context, validated server-side, and kept out of URLs where it could leak through browser history, logs, analytics, or Referer headers.
Per-Session vs Per-Request Tokens
Per-session tokens are simpler and remain valid for the life of the user’s session. Per-request tokens can reduce the useful lifetime of a leaked token but add complexity and can interfere with browser navigation or multi-tab behavior. Either model can be secure when implemented correctly; the important properties are unpredictability, correct validation, and appropriate session binding.
How to Detect CSRF Vulnerabilities
CSRF detection must prove that a state-changing request can be forged under the application’s real browser and authentication conditions. Checking only whether a form contains a hidden token is not enough.
| Method | What It Can Reveal | Important Limitation |
|---|---|---|
| Manual testing | Whether a sensitive action can actually be reproduced cross-site with the victim’s browser-held authority | Requires application context, authorization, and careful interpretation of browser behavior |
| DAST | State-changing forms or endpoints with missing, weak, or inconsistently validated CSRF controls | A missing token alone may be a false positive if another effective control blocks cross-site requests |
| Authenticated scanning | Protected account, dashboard, administrative, and workflow actions that are invisible to anonymous scanning | Coverage depends on the scanner reaching and exercising the relevant state-changing workflow |
| SAST / code review | Mutating handlers that lack token, Origin, Fetch Metadata, or framework-level CSRF validation | Runtime cookie policy, browser behavior, and CORS configuration may change real exploitability |
| Browser and network inspection | Cookie SameSite settings, Origin/Referer behavior, Fetch Metadata headers, request content types, and CORS interactions | Requires understanding the complete protection stack rather than one isolated header |
A practical defensive review follows this order:
- Identify a state-changing endpoint. Confirm that the request modifies data, privileges, settings, or another meaningful resource.
- Determine what authority the browser supplies automatically. Check cookies or other browser-managed credentials.
- Determine whether the request can be reproduced cross-site. Evaluate the required method, content type, parameters, custom headers, and CORS behavior.
- Check request-intent controls. Verify token validation, SameSite policy, Origin/Referer checks, Fetch Metadata handling, framework protections, and any reauthentication requirement.
- Confirm the action is actually accepted. A missing token or suspicious request pattern should not be reported as confirmed CSRF unless the protection stack can be bypassed under realistic conditions.
Because most valuable CSRF targets exist behind login, an authenticated vulnerability scan can expose significantly more relevant workflows than an anonymous scan.
How to Prevent CSRF
Prevent CSRF by requiring evidence of request intent that an attacker-controlled origin cannot reproduce automatically. The strongest design uses built-in framework protection where available and layers tokens, browser request metadata, cookie policy, origin validation, and stronger confirmation for high-risk actions.
Use Built-In Framework CSRF Protection
Use the CSRF protection provided by a well-maintained framework before building custom token logic. Framework implementations usually integrate token generation, storage, validation, and request handling in a way that is less error-prone than ad-hoc middleware.
Use Synchronizer CSRF Tokens
For session-based applications, require an unpredictable token that is associated with the authenticated session and submitted separately from the browser’s automatically attached cookie. Validate the token on every protected state-changing request.
Use Fetch Metadata Headers
Fetch Metadata headers let the server evaluate the relationship between the page that initiated a request and the destination receiving it. For CSRF defense, Sec-Fetch-Site is especially useful because it can identify requests as same-origin, same-site, cross-site, or none.
A practical policy is to reject unsafe state-changing requests marked cross-site unless the endpoint is intentionally designed for cross-site use. Treat same-site according to whether sibling subdomains are fully trusted; same-site does not mean same-origin.
Fetch Metadata is best used as another server-side signal, not as a replacement for tokens or careful authentication design in applications that need stronger guarantees.
Validate Origin and Referer
For state-changing requests, compare the request’s Origin header with the application’s expected origin where that header is available. A carefully implemented Referer check can be used as a fallback in environments where Origin is absent.
The comparison must use the exact expected origin rather than substring matching. Requests with missing or unexpected origin evidence should follow a deliberate application policy instead of being accepted automatically.
Do Not Use GET for State-Changing Actions
GET requests should retrieve data, not change application state. Browsers can issue cross-site GET requests through links, navigations, images, and other mechanisms, which makes state-changing GET endpoints especially difficult to protect reliably.
Using POST instead is necessary for correct HTTP semantics, but POST is not automatically CSRF-safe. Cross-site HTML forms can submit POST requests, so state-changing POST endpoints still need effective CSRF protection.
Use Non-Simple Requests for Browser APIs Where Appropriate
For JavaScript APIs, requiring a content type such as application/json or a custom request header can make the request non-simple. A hostile origin cannot freely send such a credentialed cross-origin request unless the target’s CORS policy permits the required preflight and origin.
This protection depends on CORS being configured correctly. Do not allow untrusted origins to make credentialed cross-origin requests, and avoid reflecting arbitrary Origin values while enabling credentials. A misconfigured CORS policy can allow an attacker-controlled origin to send and read requests that the application intended to restrict.
Require Fresh User Confirmation for Critical Actions
For high-impact operations such as changing authentication factors, modifying recovery details, rotating sensitive keys, deleting an account, or authorizing financial actions, require fresh evidence of user intent such as reauthentication or an additional confirmation step.
A CSRF token proves that a request followed an expected application flow; it does not necessarily prove that a user consciously approved a high-risk transaction at that moment.
How Does CSRF Apply to APIs and Single-Page Applications?
CSRF risk in APIs and SPAs depends primarily on how the browser supplies authentication. Cookie-authenticated APIs can be vulnerable because cookies may be attached automatically, while APIs that require an explicit bearer token in an Authorization header have a different classical CSRF threat model.
| Authentication / Request Model | CSRF Relevance |
|---|---|
| Cookie-based session authentication | CSRF is relevant because the browser may attach the cookie automatically |
| Bearer token explicitly added by JavaScript | Classical CSRF is reduced because a hostile page cannot automatically attach the protected token as a custom Authorization header |
| Credentialed cross-origin API | Risk depends heavily on CORS origin rules, credential settings, and request-intent controls |
| Same-site multi-subdomain application | Requires careful trust decisions because same-site requests can still be cross-origin |
A JSON API is not automatically immune to CSRF. If a browser can send the required request with accepted credentials from another origin, the endpoint still needs protection. Requiring non-simple requests and correctly configured CORS can reduce classical CSRF exposure, but those controls must match the application’s actual authentication model.
For broader endpoint, authorization, and request-security coverage, see ScanTitan’s API security testing and REST API security guides.
CSRF vs XSS vs SSRF: What Is the Difference?
CSRF, XSS, and SSRF involve different security principals: CSRF abuses the victim browser’s authority, XSS executes attacker-controlled content inside a trusted browser origin, and SSRF causes a server to make an unintended request.
| Question | CSRF | XSS | SSRF |
|---|---|---|---|
| Core mechanism | Victim browser sends an unintended authenticated request | Browser executes attacker-controlled active content in the vulnerable origin | Server sends an unintended network request |
| Primary trust abused | User/session or browser authority | Trusted application origin and unsafe rendering | Server/network/service trust |
| Can attacker normally read protected response data? | Usually not through classical CSRF alone | Often yes when script executes within the target origin | Depends on whether the SSRF response is returned or blind |
| Typical core control | Request-intent validation | Context-safe output and DOM handling | Destination and network controls |
Successful cross-site scripting (XSS) can often undermine CSRF defenses because script executing inside the trusted origin may be able to read tokens and issue legitimate-looking requests. Server-side request forgery (SSRF), by contrast, changes who sends the request entirely: the server becomes the request origin rather than the victim’s browser.
Can Vulnerability Scanners Detect CSRF?
Vulnerability scanners can detect some CSRF weaknesses, but a reliable result requires more than noticing that a form lacks a hidden token. The scanner must understand the endpoint’s state-changing behavior, authentication context, browser cookie policy, request structure, and other CSRF controls.
DAST can inspect forms and API calls, identify missing or weak request-intent controls, replay requests, and test authenticated workflows. Authenticated coverage is especially important because the most valuable CSRF targets usually exist behind login.
Automated testing becomes less reliable when protection depends on SameSite behavior, custom CORS rules, Fetch Metadata, multi-step business workflows, or client-side JavaScript that builds requests dynamically. Those cases may need code review or manual browser testing to determine whether a suspicious endpoint is actually forgeable.
This is why vulnerability scanning and penetration testing are complementary. Automated scanning can identify candidate weaknesses at scale, while manual testing can confirm exploitability and business impact where browser state and workflow logic matter.
ScanTitan’s Website Vulnerability Scanner can test web applications and APIs for runtime security weaknesses, while authenticated testing extends coverage into logged-in application states.
Frequently Asked Questions
What does CSRF stand for?
CSRF stands for Cross-Site Request Forgery. It is a vulnerability in which an attacker causes a browser to send an unintended request that a target application accepts using the browser’s existing authority.
Does CSRF require the victim to be logged in?
Traditional CSRF usually requires the browser to hold credentials or another form of authority that the target application accepts automatically. Login CSRF is an important exception because it targets the authentication flow itself.
What is a CSRF token?
A CSRF token is an unpredictable value that a protected application requires on sensitive requests so that valid browser credentials alone are not enough to authorize the action.
Does SameSite prevent CSRF?
SameSite cookies reduce many cross-site cookie-sending scenarios, but they should be treated as defense in depth rather than the only CSRF control. Same-site is also broader than same-origin, which matters when sibling subdomains are not equally trusted.
Can POST requests be vulnerable to CSRF?
Yes. Cross-site HTML forms can submit POST requests, so using POST does not prevent CSRF. State-changing POST endpoints still need effective request-intent validation.
Are APIs vulnerable to CSRF?
Yes, especially when a browser API uses automatically attached cookies for authentication. APIs that require an explicit bearer token in an Authorization header have a different classical CSRF threat model because hostile pages cannot normally attach that protected header automatically.
Can XSS bypass CSRF protection?
Often, yes. If attacker-controlled JavaScript executes inside the application’s trusted origin, it may be able to read CSRF tokens and issue requests that satisfy the application’s normal CSRF checks. Preventing XSS remains important even when strong CSRF controls are present.
Can a vulnerability scanner detect CSRF?
Scanners can identify some CSRF weaknesses, especially in authenticated forms and API workflows, but missing-token findings require context. SameSite, Origin, Fetch Metadata, CORS, framework protections, and business logic can all affect whether the request is actually forgeable.
