How to Fix Cross-Site Request Forgery (CSRF) in SvelteKit
Learn how to prevent and fix Cross-Site Request Forgery (CSRF) vulnerabilities in SvelteKit applications. Step-by-step guide with code examples, security checklists, and best practices.
What Is Cross-Site Request Forgery (CSRF)?
Cross-Site Request Forgery (CSRF) is an attack that tricks an authenticated user into submitting a request they did not intend to make. The attack exploits the fact that browsers automatically include cookies (including session cookies) with every request to a domain, regardless of the request's origin.
An attacker crafts a malicious page or email containing a request to the target application. When an authenticated user visits the attacker's page, their browser automatically sends the request along with valid session cookies. The target application cannot distinguish this forged request from a legitimate one. CSRF attacks can change email addresses, transfer funds, modify account settings, or perform any action the authenticated user is authorized to do.
The attack is particularly effective because it does not require the attacker to steal the user's credentials -- it simply leverages the existing authenticated session. Modern single-page applications using token-based authentication (like JWT in headers) are naturally resistant to CSRF since custom headers are not automatically attached to cross-origin requests, but cookie-based authentication remains vulnerable without explicit protections.
Why It Matters
CSRF attacks can have serious consequences because they execute actions with the full authority of the victim user. In financial applications, CSRF can initiate unauthorized transfers. In administrative panels, it can create new admin accounts or change security settings. Because the requests come from the legitimate user's browser with valid authentication, they are difficult to detect and trace. CSRF attacks are also easy to execute at scale -- an attacker can embed the malicious request in a popular website, forum post, or advertising network, potentially affecting thousands of users simultaneously.
How to Fix It in SvelteKit
Implement anti-CSRF tokens: generate a unique, unpredictable token for each user session and include it in every state-changing request. The server validates this token before processing the request. Use the SameSite cookie attribute (set to "Lax" or "Strict") to prevent cookies from being sent with cross-origin requests. Verify the Origin and Referer headers on the server side. Require re-authentication for sensitive operations like changing passwords or email addresses. Use framework-provided CSRF protection (Next.js Server Actions have built-in CSRF protection, Django includes CSRF middleware, Express has csurf). For APIs, prefer token-based authentication sent via custom headers rather than cookies.
SvelteKit-Specific Advice
- Use `$env/static/private` and `$env/dynamic/private` for server-only secrets. Never import from `$env/static/public` for sensitive values.
- SvelteKit has built-in CSRF protection for form actions. Ensure you are using form actions rather than custom API endpoints for state-changing operations.
- Validate all data in `+server.ts` endpoints and `+page.server.ts` load functions. These are public-facing server endpoints.
- Use hooks (`hooks.server.ts`) for global authentication and authorization checks before requests reach route handlers.
SvelteKit Security Checklist for Cross-Site Request Forgery (CSRF)
SvelteKit Security Best Practices
Use `$env/static/private` and `$env/dynamic/private` for server-only secrets. Never import from `$env/static/public` for sensitive values.
SvelteKit has built-in CSRF protection for form actions. Ensure you are using form actions rather than custom API endpoints for state-changing operations.
Validate all data in `+server.ts` endpoints and `+page.server.ts` load functions. These are public-facing server endpoints.
Use hooks (`hooks.server.ts`) for global authentication and authorization checks before requests reach route handlers.
Configure security headers in `svelte.config.js` or through hooks. SvelteKit does not set security headers by default.
Be cautious with `event.locals` -- data set here is available to all subsequent handlers in the request pipeline.
Implement rate limiting in hooks or middleware, especially for form actions and API endpoints.
Use `+page.server.ts` load functions to keep data fetching on the server. Avoid exposing internal API URLs in client-side code.
Scan Your SvelteKit App with SafeVibe
Stop guessing if your SvelteKit app is vulnerable to Cross-Site Request Forgery (CSRF). Run an automated penetration test in minutes and get actionable results.
Start Free Scan