Cross-Site Request Forgery (CSRF)
CSRF is an attack that forces an authenticated user's browser to send unintended requests to a web application where they are currently logged in.
Understanding Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery exploits the browser's automatic inclusion of credentials — cookies, HTTP authentication, and client-side certificates — with every request to a domain. An attacker hosts a malicious page that triggers a request (via a form submission, image tag, or JavaScript fetch) to the target application. Because the browser attaches the user's session cookie automatically, the target server processes the request as if the user initiated it.
A classic CSRF scenario involves a banking application. The user is logged into their bank in one tab. They visit an attacker's page in another tab, which contains a hidden form that submits a money transfer request to the bank. The bank's server sees a valid session cookie and processes the transfer.
Defenses include synchronizer tokens (unique per-session or per-request tokens embedded in forms), the SameSite cookie attribute which prevents cookies from being sent on cross-origin requests, and checking the Origin or Referer headers on state-changing requests. Modern frameworks like Next.js Server Actions and Django include CSRF protection by default, but API-only backends that rely solely on cookie authentication often lack it.
CSRF is less relevant for applications that authenticate via Authorization headers with bearer tokens, since these are not automatically attached by the browser. However, any application using cookie-based sessions remains vulnerable if CSRF protections are not explicitly implemented.
Why This Matters for Vibe-Coded Apps
Vibe-coded applications frequently use cookie-based authentication through services like Supabase Auth or Firebase Auth with session cookies. AI code generators tend to focus on making authentication work but often skip CSRF token implementation because it adds complexity without visible functionality. If your AI-built app uses server-side actions or form submissions with cookie auth, CSRF protection is essential.
When reviewing AI-generated backend code, check whether state-changing endpoints (POST, PUT, DELETE) validate a CSRF token or rely on SameSite cookie attributes. Many AI-generated APIs accept requests from any origin without CSRF validation, making them vulnerable to forged requests from malicious sites.
Real-World Examples
Netflix CSRF Vulnerability (2006)
A CSRF flaw allowed attackers to change Netflix account details, add DVDs to a user's queue, and modify the shipping address — all by having the user visit a crafted web page while logged into Netflix.
ING Direct Banking CSRF (2008)
Researchers discovered a CSRF vulnerability that could transfer money from ING Direct customer accounts by crafting a page that submitted hidden transfer requests, exploiting the bank's lack of anti-CSRF tokens.
WordPress Pingback CSRF
Multiple WordPress versions were vulnerable to CSRF attacks that could change admin settings, create new admin accounts, or install plugins when an administrator visited a malicious link while logged in.
Frequently Asked Questions
Is CSRF still relevant with modern SPAs?
It depends on the authentication method. If your SPA stores tokens in localStorage and sends them via Authorization headers, CSRF is not a concern because the browser does not automatically attach these. However, if your SPA uses cookie-based sessions (common with frameworks like Next.js using httpOnly cookies), CSRF remains a real threat. Many SPAs also make requests to same-origin APIs that rely on cookie authentication, keeping CSRF relevant.
How does the SameSite cookie attribute prevent CSRF?
SameSite=Strict prevents the browser from sending the cookie on any cross-origin request, completely blocking CSRF. SameSite=Lax allows cookies on top-level navigations (like clicking a link) but blocks them on cross-origin form POSTs and AJAX requests, which stops most CSRF attacks while preserving usability. SameSite=None provides no CSRF protection and requires the Secure flag.
Do I need CSRF tokens if I use SameSite cookies?
SameSite=Lax provides strong protection against most CSRF vectors, but defense in depth recommends combining it with CSRF tokens for critical actions. Some older browsers do not support SameSite, and Lax still allows cookies on GET navigations, which could be exploited if your app performs state changes on GET requests. For maximum security, use both SameSite=Lax and CSRF tokens.
Can CSRF steal data from the response?
Standard CSRF cannot read the response — it can only trigger the request. The same-origin policy prevents the attacker's page from reading cross-origin responses. However, CSRF can cause state changes like transferring money, changing passwords, or modifying account settings. If you need to protect against cross-origin data reading, that falls under CORS configuration.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to cross-site request forgery (csrf) and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan