Cross-Site Request Forgery (CSRF)
Last updated: January 16, 2026
CSRF tricks authenticated users into submitting malicious requests without their knowledge, potentially changing account settings, making purchases, or transferring data.
Scan for This VulnerabilityWhat is Cross-Site Request Forgery (CSRF)?
When you're logged into a site, your browser automatically sends authentication cookies with every request to that site. CSRF exploits this by tricking your browser into making requests to that site from a malicious page. The target site can't tell if the request was intentional.
Why It's Dangerous
This vulnerability can allow attackers to access sensitive data, compromise user accounts, or gain unauthorized control over your application. In AI-generated code, this issue is particularly common because security measures are often deprioritized in favor of rapid feature development.
Why AI Code Is Vulnerable
AI code generation tools focus on producing functional code quickly. They often generate patterns that work correctly but lack the defensive measures experienced security engineers would implement. This makes cross-site request forgery (csrf) particularly prevalent in vibe-coded applications.
Understanding the Technical Details
Cross-Site Request Forgery (CSRF) is classified as a high-severity vulnerability because of its potential to cause significant damage to your application and users. Understanding the technical mechanics helps you recognize and prevent this issue in your own code.
This vulnerability typically occurs when security controls are either missing entirely, improperly configured, or incorrectly implemented. In many cases, the code appears to work correctly during development and testing, but the security flaw becomes exploitable once the application is deployed and accessible to malicious actors.
Attackers actively scan for this type of vulnerability using automated tools. Once discovered, exploitation can be rapid—often within hours of your application going live. The consequences range from data theft and account takeover to complete system compromise depending on the application's architecture.
For vibe-coded applications built with platforms like Lovable, Bolt.new, Replit, or v0.dev, this vulnerability appears in roughly 20-40% of deployments according to security research. The AI-generated patterns often follow insecure defaults that require manual security hardening.
How It Happens
- No CSRF token validation
- GET requests performing state changes
- Overly permissive CORS policies
- SameSite cookie attribute not set
- Token not bound to user session
Impact
Unauthorized account changes (email, password)
Unwanted purchases or transactions
Data modification or deletion
Privilege escalation if admin is targeted
How to Detect
- Check if forms include CSRF tokens
- Test if state-changing requests work without tokens
- Verify SameSite cookie attribute
- Run VAS to detect CSRF vulnerabilities
How to Fix
Use SameSite cookies
Modern browsers support SameSite attribute to prevent CSRF.
// Set SameSite attribute
Set-Cookie: session=abc123; SameSite=Lax; Secure; HttpOnly
// Lax: Cookies sent with top-level navigation
// Strict: Cookies never sent cross-siteImplement CSRF tokens
Include unpredictable tokens in forms and validate on server.
// Generate token
const csrfToken = crypto.randomUUID();
session.csrfToken = csrfToken;
// Include in form
<input type="hidden" name="_csrf" value={csrfToken} />
// Validate on submission
if (req.body._csrf !== session.csrfToken) {
return res.status(403).json({ error: 'Invalid CSRF token' });
}Use framework protections
Most frameworks have built-in CSRF protection.
// Next.js API routes are protected by default
// if you use proper cookie settings
// For custom protection, use libraries like csurf
import csrf from 'csurf';
const csrfProtection = csrf({ cookie: true });Commonly Affected Platforms
Prevention Best Practices
The most effective approach to cross-site request forgery (csrf) is prevention. Implementing security measures during development is significantly easier and less costly than remediating vulnerabilities after deployment.
Security-First Development
When using AI code generation tools, always review the generated code for security implications. AI tools prioritize functionality over security, so treat all generated code as requiring security review. Establish a checklist of security requirements specific to your application type and verify each before deployment.
Continuous Security Testing
Integrate security scanning into your development workflow. Run scans after major code changes, before deployments, and on a regular schedule for production applications. Early detection of vulnerabilities reduces remediation costs and prevents potential breaches.
Defense in Depth
Never rely on a single security control. Implement multiple layers of protection so that if one control fails, others still protect your application. For example, combine authentication, authorization, input validation, and output encoding to create comprehensive protection against attacks.
Stay Informed
Security threats evolve constantly. Follow security researchers, subscribe to vulnerability databases, and monitor your dependencies for known issues. Understanding emerging threats helps you proactively protect your applications before attackers exploit new techniques.
Is Your App Vulnerable?
VAS automatically scans for cross-site request forgery (csrf) and provides detailed remediation guidance with code examples. Our scanner specifically targets vulnerabilities common in AI-generated applications.
Scans from $5, results in minutes. Get actionable results with step-by-step fix instructions tailored to your stack.
Get Starter ScanFrequently Asked Questions
How does SameSite prevent CSRF?
SameSite=Lax (default in modern browsers) only sends cookies with top-level navigations and GET requests from external sites. This blocks CSRF attacks that use hidden forms or AJAX. SameSite=Strict is more restrictive but can break legitimate flows like OAuth callbacks.
Are APIs vulnerable to CSRF?
REST APIs using cookies for auth are vulnerable. APIs using Bearer tokens in headers are generally safe because JavaScript from another origin can't set those headers due to CORS. If your API uses httpOnly cookies, implement CSRF protection or use SameSite=Strict.