Review SvelteKit form actions (export const actions), load() functions (+page.server.js/+page.js, +layout.server.js/+layout.js), +server.js endpoints, and template bindings for the concrete, documented defect classes that recur in SvelteKit apps: CSRF protection disabled or weakened via checkOrigin/trustedOrigins, load() returning sensitive data with no auth check on that exact path, an auth guard that lives only in a parent +layout.server.js and is silently skipped by a child page that never calls await parent() (or by client-side navigation that does not re-run the layout load), cookies set without httpOnly/secure/sameSite/path explicitly locked down, and unsanitized {@html} rendering of user-reachable input. This skill exists so the review stays anchored to these five documented, security-critical sinks instead of drifting into a general \"SvelteKit code review\" of routing, reactivity, or component design.
Use this skill when the user asks to:
\nexport const actions) or a load() function for authentication/authorization correctness,svelte.config.js's csrf block (checkOrigin, trustedOrigins) is safely configured,cookies.set() call or an {@html} binding is safe,Do not use this skill for:
\n$state/$derived), or component-composition review with no security angle — use a SvelteKit architecture-focused skill instead,+page.server.js/+layout.server.js/+server.js/form-action code and no cookie or {@html} usage — there is no server-side sink in scope,resolve-library-id (matched result: /sveltejs/kit) before citing any CSRF-mechanism, cookie-default, or load()/auth claim./sveltejs/kit is SvelteKit's own repository (runtime source such as respond.js/cookie.js plus its documentation tree), so both source-level mechanics and prose guidance are queryable through query-docs. Use it to confirm exact runtime behavior — e.g., that csrf_check_origin only rejects same-origin-mismatched, form-content-type POST/PUT/PATCH/DELETE requests, that trustedOrigins: ['*'] fully disables the origin check regardless of checkOrigin, and that cookies.set() defaults httpOnly and secure to true (with secure relaxed only on plain-HTTP localhost) and sameSite to 'lax'.+layout.server.js auth guard as insufficient, confirm via query-docs (or the official_docs URLs in this skill's metadata.json if Context7 is unavailable) that layout load() functions do not re-run on every child-route navigation and that layout/page load() functions run concurrently unless a child explicitly calls await parent() — this is the documented mechanism behind the risk, not an assumption.package.json and svelte.config.js first to confirm the SvelteKit major version and adapter in use — cookie defaults (the path-required behavior) and CSRF option shape changed between SvelteKit 1 and 2; do not apply v2 requirements to a v1 codebase or vice versa.official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.checkOrigin: false, a wildcard trustedOrigins, an unguarded sensitive load() return, or an untraced {@html} sanitizer gap to MEDIUM just because it has not been observed exploited yet — the risk is in the structure, not in whether someone has already hit it.cookies.get() call, the specific missing guard, or the specific cookies.set() options object is not a valid finding — it is a guess.export function load() (or export const actions), determine whether an auth check happens inside that exact function (e.g., via a requireLogin()-style helper reading event.locals/cookies) before any sensitive data is fetched or returned. Do not accept \"the parent layout checks auth\" as sufficient unless the specific child load() under review actually calls await parent() and that call's result is checked, or hooks.server.js's handle function enforces the guard before any load() runs.cookies.get(...) value being passed directly into a database call or trusted as an identity claim. A session/user identity must be resolved through a verifying helper (session-store lookup, signature check, requireLogin()) — a lookup with no verification step is not authentication, it is an unguarded read keyed on attacker-controlled input.cookies.set() call for explicit httpOnly, secure, sameSite, and path. Flag any call that sets httpOnly: false (or otherwise turns off a secure default) on a session/identity cookie as HIGH, and flag any call missing path as at least MEDIUM (SvelteKit requires an explicit path since v2 specifically to avoid ambiguous cookie scoping).{@html} binding whose data source includes any user-reachable input (route params, query strings, request bodies, form-submitted content, third-party API responses that themselves echo user input) unless a named sanitizer call (e.g., DOMPurify.sanitize()) is visibly present on that exact data-flow path in the template expression. A sanitizer import existing elsewhere in the codebase does not clear this bar.checkOrigin: false and trustedOrigins: ['*'] as equally severe: both fully disable SvelteKit's CSRF origin check for cross-site form submissions, even though only one of them touches the literal checkOrigin key.Load these only when needed:
\nsvelte.config.js's csrf block, a form action, or a load()/+layout.server.js/hooks.server.js auth-guard trace.cookies.set() call or an {@html} template binding.Return, at minimum:
\nload() function(s), hooks.server.js handle, svelte.config.js csrf block, cookie operations, and/or {@html} bindings in scope,csrf-bypass, auth-leakage, auth-boundary, cookie-policy, or xss), the concrete data-flow trace (the exact checkOrigin/trustedOrigins value, the cookies.get()-to-sink path, the layout-to-child guard gap, the cookies.set() options object, or the {@html} origin-to-sink path), and a fix sketch matching SvelteKit's documented pattern,{@html} finding, an explicit statement of whether a sanitizer call is present on the traced path — never approve on the assumption one exists elsewhere,hooks.server.js (applies to every request) or only in a +layout.server.js/+page.server.js load() (applies only if that exact function runs and, for a layout, only if a child calls await parent()),repo evidence, documentation-based, or inference), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,