Use server-side CSRF tokens on every state-changing request, pair them with secure session settings, and keep CORS separate from request authenticity. The key is to verify that each sensitive action was intentionally initiated through the legitimate application context, not merely sent by an authenticated browser session.
Why CSRF still matters in React and API-driven apps
React and API-heavy architectures can create a false sense of safety because the UI is modern while the browser is still doing the same old thing: automatically sending cookies and other ambient credentials. CSRF remains a request-forgery problem, not a front-end-framework problem. The real control question is whether the server can distinguish a legitimate action initiated by your app from an unwanted action sent by another site.
That distinction matters most on state-changing operations such as profile updates, payments, password changes, and consent actions. If those endpoints trust only the browser session, an attacker can try to induce a victim’s browser to submit a valid-looking request without ever stealing the user’s password.
For API-driven apps, the common mistake is treating JSON endpoints, SPAs, and mobile-style front ends as if they are automatically immune. They are not. If a browser can authenticate to the API with a cookie, the API still needs a forgery check that is independent of CORS and independent of the visible UI.
What actually blocks forged browser requests
The most reliable pattern is a server-generated CSRF token that must accompany every state-changing request and be validated server-side before the action is accepted. The token should be tied to the user session or another server-side context the attacker cannot predict, and it should be required even when the request looks like a normal XHR or fetch call from the React app.
In practice, the protection has to work at the application boundary, not just in the browser. SameSite cookies, secure cookie flags, and short session lifetimes help reduce exposure, but they do not replace request authenticity checks. A request can come from a browser that is already logged in and still be malicious.
Good implementations also separate “can this browser talk to the API?” from “did the legitimate app intentionally ask for this action?” That is why CORS is a transport and origin policy, not a CSRF control. CORS can limit which scripts can read responses, but it does not by itself prove that a sensitive request was intentionally initiated by your application.
How to design CSRF protection for React and APIs
For browser-based apps, use a token pattern that the app can read and submit, such as a synchronizer token or a double-submit style design when it is implemented carefully on the server. The key requirement is that the server validates the token on every unsafe method, not only on a login flow or a few selected routes.
Protect the endpoints that change state, not just the page that renders forms. In a React single-page app, that means the CSRF check belongs in the API layer or gateway logic that enforces business actions, because the front end can be bypassed or manipulated. If a route can modify data, it should be behind the same authenticity requirement regardless of how the request was produced.
For teams looking to align this with broader api security practice, the same discipline used to stop broken authorization in APIs also helps here: validate the request context before trusting the action. OWASP’s API guidance is a useful companion for mapping request authenticity and authorization failures in modern back ends, especially where the UI is decoupled from the API surface. OWASP API Security Top 10
Risk and Threat Considerations
CSRF risk is highest when a browser session can act on behalf of a user without any second proof that the action was intentional. That becomes especially dangerous on account changes, financial actions, privilege changes, and any endpoint that triggers irreversible side effects. OWASP Top 10
Failure mechanism: The application accepts a state-changing request solely because the user’s browser is authenticated, while the request itself lacks a verifiable anti-forgery token or equivalent server-side authenticity check. An attacker can then cause the victim’s browser to submit the action from another site.
Impact: Unwanted transfers, profile manipulation, email or password changes, consent abuse, and account integrity loss can follow, even when the attacker never learns the victim’s password or session value.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | State-changing API requests need server-side validation before action execution. |
| API2 — Broken Authentication | CSRF defenses depend on proving request authenticity beyond ambient browser login. | |
| Recommendation — Enforce request-side checks before allowing sensitive API actions to execute. Require an explicit anti-forgery signal for every unsafe authenticated request. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Modern React apps often pair browser sessions with federated login and token-based flows. |
| Recommendation — Validate session and token handling so browser login state cannot be misused by forged requests. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CSRF tokens and related session controls rely on sound lifecycle handling of authenticators. |
| AC-3 — Access Enforcement | Server-side enforcement must decide whether a state-changing request is allowed. | |
| Recommendation — Manage authenticators and session artifacts so they cannot be predictably reused or forged. Enforce access decisions on the server before any protected state change occurs. | ||
Practitioner Guidance
What to verify: Confirm that every unsafe API method rejects requests without a valid CSRF token, and test that the token check is enforced server-side rather than in React code alone. Also verify that session cookies are configured to reduce cross-site submission risk, but treat those settings as supporting controls, not the primary defense.
Common mistake: Do not assume that JSON, fetch, or an SPA architecture makes CSRF disappear. If the API relies on browser cookies for authentication, you still need explicit request authenticity checks on the server.
Decision rule: If the endpoint changes state and the browser can authenticate with ambient credentials, require a CSRF token or an equivalent anti-forgery control. If the action is read-only and does not change trust or state, the CSRF burden is lower, but you still need to confirm that no side effect exists.
Practitioner takeaway: In React and API-driven systems, CSRF is prevented by proving intent at the server, not by trusting the front end or conflating CORS with authenticity.
Related resources from NHI Mgmt Group
- How should security teams prevent open redirect vulnerabilities in modern API and OAuth-driven applications?
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
- How should security teams prevent valid credentials from accessing the wrong API objects?