Understanding CSRF and why website owners should care
Cross-site request forgery (CSRF) is a web security problem that quietly lets an attacker cause a user’s browser to perform actions on a site where that user is already authenticated. The attack typically tricks the victim into submitting a request,like changing an email address, making a payment, or updating account settings,without their explicit intent. For website owners, the risk is twofold: users can lose trust after unauthorized actions, and your application can be held responsible for weak request validation that allowed those actions. Recognizing how CSRF works and adding straightforward protections reduces liability and protects users from account compromise or unwanted transactions.
How CSRF attacks actually work
At the core, CSRF leverages the fact that browsers automatically include cookies and some credentials in requests to a site. If a user is logged into example.com, an attacker who convinces the browser to visit a forged url or submit a hidden form can cause the browser to send an authenticated request to example.com. The server sees a valid session cookie and performs the action, because it has no reliable way to distinguish an attacker-originated request from a legitimate one. Common attack vectors include malicious links, auto-submitting forms in third-party pages, or image tags that cause GET requests; modern attacks may use hidden POST forms or JavaScript when cross-origin protections allow it.
Practical defenses: what to implement first
Protection against CSRF is best approached with multiple, complementary measures. Start with defenses that are simple to add and provide broad coverage, then harden endpoints handling sensitive state changes. The most important and widely adopted controls are CSRF tokens, SameSite cookie attributes, and strict server-side origin checks. Together, these reduce both automated and manual attacks.
Use anti-CSRF tokens (synchronizer token pattern)
Anti-CSRF tokens are unique values generated by the server and tied to a user’s session. The token is embedded in forms or returned to single-page apps, and it must be included in any state-changing request. Because an attacker cannot read the token from another origin, they cannot forge a proper request. Implement tokens on every form or API endpoint that changes data, and validate them server-side each time. For ajax-based apps, the token is often sent as a custom header (e.g., X-CSRF-Token) with every non-GET request. Many web frameworks provide CSRF protection out of the box,enable and configure it rather than reinventing the wheel.
Set cookies with SameSite and secure attributes
Cookies carrying session identifiers should be marked with SameSite and Secure. SameSite=Lax or SameSite=Strict prevents cookies from being sent on most cross-site requests, which blocks many CSRF techniques that rely on cookies being included. Lax balances usability and security for typical flows like GET links; Strict is safer but can break legitimate cross-site flows. Always use Secure so cookies are only sent over https, and include HttpOnly where appropriate to reduce the chance of client-side script leakage. While SameSite doesn’t replace tokens, it’s an effective additional barrier and easy to configure on most platforms.
Validate Origin and Referer headers
Server-side checks of the Origin or Referer header add another line of defense, especially for APIs. For POST, PUT, PATCH and DELETE requests, confirm that the Origin or Referer matches your site’s expected domain. These headers can be spoofed in some environments, but when combined with token checks they make attacks significantly harder. Note that some user agents or privacy extensions may omit Referer, so treat these checks as complementary rather than a sole defense.
Protect APIs and cors settings
APIs exposed to browsers need careful Cross-Origin Resource Sharing (CORS) configuration. Avoid using Access-Control-Allow-Origin: * for endpoints that change state or return sensitive data. Prefer strict whitelists and disallow credentials for cross-origin requests unless explicitly needed; if you must allow credentials, ensure you only permit trusted origins and require CSRF protection tokens on the API calls. For json APIs, using a custom header (e.g., X-CSRF-Token) forces browsers to preflight, giving servers an opportunity to deny dangerous cross-origin requests.
Implementation checklist for common stacks
Most frameworks have built-in CSRF mechanisms; use them and follow these practical steps. First, enable the framework’s CSRF middleware and read the docs to understand how tokens are embedded and validated. Second, set your cookies with SameSite and Secure attributes,configuration is typically a single setting. Third, audit all endpoints that change state and ensure they require tokens or proper headers. Fourth, review CORS settings to prevent overly permissive cross-origin access. Finally, include CSRF checks in your testing and include automated tests that attempt to call state-changing endpoints without tokens.
- Enable framework CSRF protection (e.g., Django, Rails, Express middleware).
- Set session cookies with SameSite and Secure attributes.
- Require anti-CSRF tokens for forms and AJAX requests.
- Validate Origin/Referer for state-changing requests.
- Restrict CORS and avoid allowing credentials to untrusted origins.
Testing and monitoring
Testing CSRF protection should be part of your regular security checks. Automated scanners and penetration testing tools can detect obvious CSRF weaknesses, but manual testing remains valuable: try to submit state-changing requests from another origin, remove or alter tokens, and confirm the server rejects those requests. Monitor logs for anomalies like repeated failed token validations or unexpected Origin headers, which could indicate attempted attacks. Also track user reports of unexpected actions and correlate them with server-side validation failures to quickly identify gaps.
Common mistakes to avoid
Some pitfalls are easy to fall into. Relying solely on cookies without tokens leaves you exposed; placing CSRF tokens only in JavaScript-accessible locations without binding them to sessions can be bypassed if XSS exists; accepting Referer checks as the only measure can fail if privacy tools strip that header. Don’t forget to protect non-html endpoints like JSON APIs, and avoid making CORS overly permissive just to support third-party integrations. Finally, mixing authentication and CSRF protection assumptions,such as thinking a JSON-only API is safe because it doesn’t render forms,can be dangerous without token or header checks.
Quick example: sending a token with fetch
For single-page applications using fetch, include the CSRF token in a custom header and validate it on the server. This ensures the request requires a value only your site can provide. A simple client-side pattern is to read a token from a meta tag or a cookie and send it with non-GET requests; server code then checks the value against the session or a server-side store.
// Example client-side header (simplified)
const token = document.querySelector('meta[name="csrf-token"]').content;
fetch('/account/update', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-CSRF-Token': token
},
body: JSON.stringify({ email: 'new@example.com' })
});
Summary
CSRF is a realistic threat for any site that relies on browser cookies or automatically-sent credentials. Protecting your users is straightforward if you adopt a layered approach: implement anti-CSRF tokens, set cookies with SameSite and Secure flags, validate Origin/Referer where useful, and lock down CORS. Use your framework’s built-in protections, test regularly, and treat CSRF as part of your standard security checklist rather than an optional add-on.
FAQs
Q: Is SameSite enough to stop CSRF?
A: SameSite significantly reduces many CSRF vectors but is not a complete replacement for tokens. Combine SameSite with server-side CSRF tokens and proper origin checks for robust protection, especially for sensitive actions and APIs that allow credentials.
Q: Do I need CSRF protection for APIs that use JWTs?
A: If the JWT is stored in a cookie and automatically sent by the browser, you still need CSRF protection. If the JWT is stored and sent manually (for example, in an Authorization header managed by client-side code), the risk is lower, but you must ensure secure storage practices to avoid XSS risks.
Q: Can CSRF be fixed with CORS alone?
A: Proper CORS configuration helps, but it is not a sole answer. CORS restricts cross-origin requests from browsers but must be configured carefully to avoid allowing credentials from untrusted origins. Use CORS together with tokens and cookie settings.
Q: How do I test that CSRF protection is working?
A: Try to submit state-changing requests from a different origin without tokens or with manipulated tokens, and confirm the server rejects them. Use automated tools and manual tests, and review server logs for rejected attempts or missing token errors.
