CSRF Protection Missing in Cursor-Generated Forms and APIs
Your Cursor-generated application has forms and state-changing API endpoints (POST, PUT, DELETE) that lack CSRF (Cross-Site Request Forgery) protection. An attacker can craft a malicious webpage that tricks authenticated users into performing unintended actions on your app, such as changing their email, transferring funds, or deleting data.
Cursor often generates clean, functional forms and API routes but omits CSRF tokens entirely. The generated code accepts form submissions and API requests without verifying that they originated from your application. This is especially dangerous for apps that use cookie-based session authentication.
You might discover this during a security audit, penetration test, or when a security researcher demonstrates that they can create an external page that submits forms to your app on behalf of logged-in users.
Error Messages You Might See
Common Causes
- No CSRF middleware configured — Cursor generated Express/Next.js routes without adding csrf or csurf middleware to the application
- Forms missing hidden token fields — HTML forms were generated without a CSRF token input field
- SPA without CSRF headers — Single-page app makes fetch/axios calls without sending a CSRF token in request headers
- Cookie SameSite not set — Session cookies lack the SameSite attribute, allowing cross-site requests to include credentials
- API routes skip origin validation — Server-side endpoints don't check the Origin or Referer header to verify request source
- Webhook exemptions too broad — CSRF exemption for webhook endpoints accidentally covers all POST routes
How to Fix It
- Install CSRF middleware — For Express: use the csrf-csrf or lusca package. For Next.js: implement CSRF token validation in middleware. For Django/Rails: ensure built-in CSRF is enabled
- Add CSRF tokens to all forms — Include a hidden input field with the CSRF token:
<input type="hidden" name="_csrf" value="{{csrfToken}}"> - Send CSRF tokens in AJAX requests — For SPAs, read the CSRF token from a cookie or meta tag and include it in the X-CSRF-Token header on every state-changing request
- Set SameSite cookie attribute — Configure session cookies with
SameSite=LaxorSameSite=Strictto prevent cross-site cookie sending - Validate Origin header on the server — As a defense-in-depth measure, check that the Origin header matches your domain for all state-changing requests
- Only exempt specific webhook paths — If you have webhooks (e.g., /api/stripe/webhook), exempt only those specific paths from CSRF, not entire route groups
Real developers can help you.
You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.
Get HelpFrequently Asked Questions
Do I need CSRF protection if I use JWT authentication?
If your JWT is stored in localStorage and sent via Authorization header, CSRF protection is less critical since browsers don't automatically send localStorage data cross-site. However, if your JWT is stored in a cookie (common for SSR apps), you absolutely need CSRF protection.
Why do my API calls fail after adding CSRF protection?
Your frontend needs to include the CSRF token with every state-changing request. For SPAs, read the token from a cookie (e.g., XSRF-TOKEN) or a meta tag and add it as an X-CSRF-Token header in your HTTP client configuration.