rules-svelte

Potentially unsafe pattern detected in svelte code: "{@html ". Review the use case — this may indicate a security risk, a deprecated API, or a misconfiguration. Confirm the write is intentional.

RISK: eval() or new Function() inside a Svelte reactive statement ($:) re-executes on every dependency change — any user-controlled value flowing into it is a persistent XSS/code-injection vector. FIX: Remove eval/Function; use a static lookup table or JSON.parse() instead.

RISK: {@html} with user-controlled props/params/formData is a direct XSS sink (CWE-79) — Svelte does not sanitize {@html}. FIX: Sanitize with DOMPurify before passing to {@html}, or render as plain text (just use {variable} which Svelte auto-escapes).

You are using an outdated API for svelte. Please upgrade to the newer API.

RISK: SvelteKit form actions without CSRF protection are vulnerable to cross-site request forgery — a malicious site can POST to your action URL from a victim's browser. FIX: SvelteKit's built-in CSRF check validates the Origin header by default, but ensure you have not disabled it via csrf: { checkOrigin: false } in svelte.config.js.

RISK: Importing from '$env/static/private' inside a .svelte component causes SvelteKit to embed the secret value into the client bundle — it will be visible in the browser. FIX: Only use private env vars in +page.server.ts, +layout.server.ts, or +server.ts files. Pass only what the client needs via return {}.

RISK: A SvelteKit API route that handles mutations (POST/PUT/PATCH/DELETE) without checking session/user is unauthenticated — any caller can invoke it. FIX: Check locals.user or call auth() at the top of the handler and throw error(401) if unauthenticated.