Understanding CSRF (Cross-Site Request Forgery)
Cross-Site Request Forgery, commonly called CSRF, is an attack that tricks a user’s browser into submitting a request to a site where the user is already authenticated. Because the browser automatically includes credentials like cookies, the forged request can perform actions such as changing an email address, transferring funds, or updating settings. The attack doesn’t require the attacker to know the user’s login, just to get the user to visit a page or load an image/script that issues a request to the target site.
How a CSRF attack typically works
Imagine you’re logged into a banking site in one tab. In another tab you open a malicious page that contains a form auto-submitted to the bank’s transfer endpoint. Your browser sends the request and includes the bank cookie, so the bank sees the request as authenticated. The attacker’s page didn’t need to steal your cookie or credentials , it simply exploited the browser’s automatic credential handling. This pattern is the core of CSRF and explains why defenses focus on separating trusted requests from cross-site requests.
Common defenses against CSRF
Several techniques are widely used to prevent CSRF. Each has trade-offs in complexity, compatibility, and what kinds of applications it suits best. It helps to think of defenses as either preventing the browser from attaching credentials automatically or making cross-site requests invalid even when credentials are attached.
1) Anti-CSRF tokens (synchronizer tokens)
Anti-CSRF tokens are unique, unpredictable values generated by the server and embedded in safe places of forms or requests (usually inside html forms or as a hidden field). The server stores or validates the token when the request arrives. Since an attacker on a third-party site cannot read the token from the target site (same-origin policy), they cannot craft a valid forged request. Tokens work reliably for traditional server-rendered apps and are the most common recommendation for state-changing endpoints.
2) SameSite cookies
The SameSite cookie attribute instructs browsers not to send cookies on certain cross-site requests. Values like Lax or Strict reduce CSRF risk by preventing cookies from being attached during cross-site browsing in many scenarios. Setting SameSite=Lax already blocks most GET-based CSRF vectors and Lax/Strict in combination with secure and HttpOnly flags strengthens protection. However, behavior differs between browsers and some legitimate cross-site workflows may be broken, so test carefully.
3) Double-submit cookie
The double-submit approach writes a random value into a cookie and also sends it as a request parameter (or header). The server checks that the cookie value matches the parameter. Because an attacker can’t read the cookie value from another origin, they cannot set the matching parameter correctly. This method doesn’t require server-side token storage, which simplifies horizontal scaling, but it still depends on same-origin protections and correct implementation.
4) Origin and Referer header checks
Servers can validate the Origin or Referer header of incoming requests to ensure they originated from the same site. For POST requests, Origin is usually present and harder to spoof than Referer. This method is simple and effective in many cases, but some users or proxies might strip headers, and older browsers may behave inconsistently, so it’s best used as part of a layered defense rather than the only protection.
Alternatives and patterns that avoid CSRF entirely
In some architectures you can eliminate CSRF by changing how authentication and state are handled. These alternatives trade CSRF risk for other considerations like XSS risk or developer complexity, so it’s important to choose a solution that fits your app’s threat model.
1) Token-in-header (no cookies)
If the browser does not send automatic credentials (cookies) with requests, CSRF cannot occur. Many single-page applications (SPAs) use an Authorization header with a bearer token (e.g., a JWT) stored in memory and attached manually to requests. Because attackers cannot cause the browser to attach such headers from another origin, CSRF is avoided. The downside is that storing tokens in localStorage or similar makes them vulnerable to cross-site scripting (XSS) if your site’s JavaScript is compromised. Keeping tokens in memory and re-obtaining them on refresh plus strong XSS protection reduces that risk.
2) Short-lived tokens and reauthentication
Another approach is to require reauthentication or a fresh one-time code for sensitive actions. For example, require the user to enter their password for money transfers or to use short-lived approval tokens. This moves the burden to the user for high-risk operations and can be combined with step-up authentication like two-factor challenges. It’s effective for protecting high-value actions but adds friction to the user experience.
3) Same-origin-only APIs and cors
Configuring APIs to accept only same-origin requests or to require preflighted requests with special headers (and enforcing strict CORS policies) reduces CSRF risk. If your API rejects cross-origin requests or requires a custom header that browsers do not send cross-site automatically, it becomes much harder for an attacker to forge valid requests. This is a good match for public APIs and services that expose endpoints to web apps under tight control.
Comparing the options: pros, cons, and when to pick what
No single defense is correct for every situation. Anti-CSRF tokens are reliable for traditional server-side apps where cookies store session state. SameSite is a low-effort improvement that can block many attacks and should be set where possible. For SPAs that use authorization headers, avoiding cookies can remove CSRF risk but you must harden against XSS. Origin/Referer checks are simple and effective as a secondary check, and double-submit cookies are a lightweight alternative when stateful tokens are inconvenient to store.
- Server-rendered apps (cookie sessions): Use CSRF tokens + set SameSite and secure cookie flags.
- Single-page apps (API with Authorization header): Prefer tokens in headers and strong XSS protections; SameSite still helps for any cookies you use.
- Public APIs: Require CORS, custom headers, or signed requests and avoid cookie-based auth for APIs.
- High-risk operations: Require reauthentication or multi-factor confirmations in addition to standard protections.
Implementation tips and common pitfalls
When implementing CSRF protections, pay attention to where tokens are stored and how they’re validated. Embedding tokens in the HTML output of server-rendered pages is simple and effective; for ajax calls include the token in an HTTP header. Always validate tokens server-side. Don’t rely solely on client-side checks since an attacker controlling a page can bypass them. Be careful with SameSite: older browsers may not support it, and Lax vs Strict affects behavior like cross-site link navigation. If using JWTs or other tokens stored in the browser, treat XSS as a first-class threat: use Content Security Policy (CSP), HttpOnly cookies for sensitive cookies (if you still use cookies), input sanitization, and minimize inline scripts to reduce attack surface.
Summary
CSRF attacks exploit the browser’s tendency to send credentials automatically with cross-site requests. Defenses fall into two main groups: techniques that make forged requests invalid (anti-CSRF tokens, double-submit cookies, origin checks) and architecture choices that remove automatic credentials from cross-site requests (use of Authorization headers, strict CORS, short-lived tokens). For most traditional sites, anti-CSRF tokens combined with SameSite cookie attributes provide strong protection. For SPAs and APIs, moving authentication out of the cookie path can prevent CSRF but requires stronger XSS mitigations. Pick the approach that matches your app’s architecture, test in real browsers, and layer protections for the best results.
FAQs
1. Is CSRF the same as XSS?
No. CSRF tricks a browser into making an authenticated request from another site; it exploits how browsers include credentials. XSS (Cross-Site Scripting) lets an attacker run code in the victim’s browser, which can be used to perform CSRF or steal tokens. XSS is generally considered more dangerous because it can bypass many defenses if scripts run in the application’s origin.
2. Are SameSite cookies enough to stop CSRF?
SameSite significantly reduces CSRF risk and should be used, but it’s not a complete solution by itself because behavior can vary between browsers and it may break legitimate cross-site flows. For maximum safety, combine SameSite with server-side CSRF tokens or other checks.
3. If I use JWT in localStorage, am I safe from CSRF?
Storing tokens in localStorage prevents automatic cookie-based CSRF, but it exposes you to XSS risk, since malicious scripts can read localStorage. If you go this route, prioritize preventing XSS through CSP, input validation, and minimizing inline JavaScript. Consider keeping short-lived tokens and refresh tokens stored more securely.
4. When should I require reauthentication for actions?
Use reauthentication for sensitive, high-value actions such as changing account email, password, or making payments. This adds user friction but provides a strong defense against both CSRF and session theft.
5. What’s the simplest practical starting point?
For most applications: enable SameSite and secure cookies, implement server-side CSRF tokens for state-changing endpoints, and validate Origin/Referer headers where feasible. For APIs, prefer token-in-header approaches with strict CORS and strong XSS protections.
