SvelteKit

Security scanning for SvelteKit apps

SvelteKit nudges you toward secure patterns: $env/static/private vs $env/static/public makes it harder to accidentally bundle secrets, and form actions discourage CSRF-prone patterns. The remaining work is host-level (CSP/HSTS) and configuration (cookie flags, CORS on +server.ts endpoints).

Most common issues

  1. 01Missing CSP and HSTS on the deployed site (configure via svelte.config.js or host)
  2. 02+server.ts endpoints with wildcard CORS exposing data cross-origin
  3. 03Session cookies set manually without Secure/HttpOnly/SameSite

What SafeToShip checks for SvelteKit

  • headers
  • js-secrets
  • cors
  • cookies
  • ssl
  • exposed-files

FAQ

Frequently asked questions

Does $env/static/private prevent all leaks?
It prevents accidental bundling — but only for env values referenced through that import. If you read process.env.MY_SECRET directly in client code, it can still leak. Stick with the $env imports.
How do I add CSP in SvelteKit?
svelte.config.js → kit.csp.mode + kit.csp.directives. SvelteKit auto-injects nonces for inline scripts when you set mode: "auto".

Fix guides

Common SvelteKit fixes

Missing CSP header

A missing Content-Security-Policy header lets attackers inject scripts into your site. Here is what CSP does, why you need it, and how to add it in Next.js, Vercel, and Supabase apps.

Read more

CORS allows all origins

An Access-Control-Allow-Origin: * policy lets any site call your API. Sometimes that is fine, often it is a mistake. Here is how to decide and fix it.

Read more

Cookie missing Secure flag

Cookies without the Secure flag can be sent over HTTP, leaking session tokens to anyone on the same network. Here is how to set it.

Read more

Hardcoded API key in JS

Any secret in your client bundle is public. Here is how to find them, rotate them, and move the calls server-side.

Read more

Run a SvelteKit security scan

Free. 70+ checks. 60 seconds.