tanstack-start-security

@rules/auth-and-session.md @rules/server-boundaries.md @rules/http-and-headers.md @rules/validation.md @references/official-security-notes.md

TanStack Start Security

<output_language>

Default all user-facing deliverables, saved artifacts, reports, plans, generated docs, summaries, handoff notes, commit/message drafts, and validation notes to Korean, even when this canonical skill file is written in English.

Preserve source code identifiers, CLI commands, file paths, schema keys, JSON/YAML field names, API names, package names, proper nouns, and quoted source excerpts in their required or original language.

Use a different language only when the user explicitly requests it, an existing target artifact must stay in another language for consistency, or a machine-readable contract requires exact English tokens. If a localized template or reference exists (for example *.ko.md or *.ko.json), prefer it for user-facing artifacts.

</output_language>

Purpose

Harden TanStack Start applications without turning every change into a full security rewrite.

Use this skill when the job is specifically about security posture in a TanStack Start app:

• auth and session protection
• cookies, CSRF, trusted origins, and browser request safety
• request middleware in src/start.ts
• server function and server route hardening
• secret and env boundary protection
• SSR, hydration, and client/server execution leaks
• security headers, CSP, webhook verification, and rate limiting

Do not use this skill for generic React work or non-security copy edits.

This skill's output shape is a security decision set: the mapped security surface, the rule file that governs it, the smallest change that closes the risk, and the verification output that proves the risk is closed. Work whose deliverable is an architecture plan instead of a closed security risk - folder layout, routing conventions, data-loading model, cache behavior - does not fit that shape, so do not stretch this skill to cover it: harden and report only the security surfaces actually in scope, and name the remaining architecture items as outside this skill's output shape.

If the request is a generic non-TanStack security review, route away to the normal security-review path instead of forcing TanStack Start rules.

<instruction_contract>

Field	Contract
Intent	Reduce the real security risk in a TanStack Start app without turning every change into a full security rewrite.
Scope	Auth and sessions, cookies/CSRF/trusted origins, secrets and env exposure, request middleware, server functions, server routes, headers/CSP/CORS, webhooks, rate limiting, and SSR/hydration/import-boundary leaks in a TanStack Start project.
Authority	User and project instructions outrank this skill. Current official TanStack Start and auth-library documentation outranks this skill's notes when the two disagree. The core security gates block a change regardless of other preferences.
Evidence	Repository signals (app.config.ts, @tanstack/react-start, @tanstack/react-router, src/routes/__root.tsx), the touched source paths, the rule files that govern them, and the project check output.
Tools	Local search, read, and edit commands plus the project's own lint, typecheck, test, and build commands. Network access, credential use, and destructive or production-affecting commands need explicit user approval.
Loop	No loop: one mapping-and-fix pass over the affected surfaces followed by the rule-file checklists, repeated only when a new surface is touched or a check fails.
Output	Korean security report or change set: the mapped security surfaces, the rule file behind each fix, the changed files, the verification commands with their results, and the residual stack-dependent risk.
Verification	Run the rules/validation.md gates for every touched surface plus the project's own checks, then record the exact commands and their results.
Stop condition	Stop when each mapped surface is hardened or explicitly deferred, the relevant rule-file gates pass, verification output is recorded, and the remaining stack-dependent risk is named.

</instruction_contract>

Trigger Examples

Positive examples:

• Review TanStack Start login and session handling security.
• Prevent secrets from leaking through a TanStack Start server function.
• Review auth, cookies, CSRF, and webhook security in this TanStack Start app.

Negative examples:

• Make a small style-only change to a plain React page.
• Security review an Express API server that is not a TanStack Start app.

Boundary examples:

• Change only the copy on a TanStack Start page. If there is no change to security boundaries, auth, env handling, server routes, or headers, this skill may be too heavy.

Step 1: Project Validation

Apply this skill only when the repository is actually using TanStack Start signals such as:

• app.config.ts
• @tanstack/react-start in package.json
• @tanstack/react-router in package.json
• src/routes/__root.tsx

If those signals are absent, stop and fall back to the normal implementation or security-review path.

Step 2: Read The Right Rules

Read these files before editing security-sensitive code:

• rules/auth-and-session.md for authentication, authorization, cookies, and request-origin rules
• rules/server-boundaries.md for createServerFn, createServerOnlyFn, env/secrets, and import boundaries
• rules/http-and-headers.md for server routes, CSP, headers, CORS, rate limiting, and webhook handling
• rules/validation.md for review gates and verification steps

Read references/official-security-notes.md when auth stack details, TanStack execution rules, or Better Auth specifics matter.

Start Here By Prompt Type

• auth, session, cookie, CSRF, beforeLoad, and authorization issues: start with rules/auth-and-session.md
• secret leaks, env exposure, loader, SSR context, hydration leaks, and import-boundary issues: start with rules/server-boundaries.md
• src/start.ts middleware, CSP, CORS, headers, webhooks, rate limiting, and server routes: start with rules/http-and-headers.md
• if the prompt is a copy-only edit or a non-TanStack security request, stop at the core boundary decision and route away instead of reading deeper files

Step 3: Security Mapping

Before changing code, map which security surface you are touching:

1. Auth/session
2. Secrets/env
3. Request middleware in src/start.ts
4. Server functions
5. Server routes / HTTP endpoints
6. Browser-delivered headers and CSP
7. SSR / hydration / import boundary leaks

If more than one surface is affected, validate all linked rule files before editing.

Step 4: Preferred Fix Order

Use the lightest fix that closes the actual risk:

1. Stop secret or boundary leaks first
2. Add session/authz enforcement next
3. Tighten cookies, origins, and mutation safety
4. Add explicit headers, CSP, webhook checks, and rate limits
5. Only then consider larger auth-stack or route-structure migrations

Step 5: Auto-Remediation Policy

Auto-fix directly when the change is local, reversible, and clearly safer:

• move privileged logic behind createServerFn or createServerOnlyFn
• add route/session guard checks
• replace client-exposed secret access with server-only access
• add missing input validation or origin/signature checks
• tighten cookie or header defaults when the current stack is clear

Do not auto-apply broad, risky migrations without explicit justification:

• replacing the auth library
• sweeping session model changes
• site-wide CSP rewrites without checking asset/script requirements
• broad CORS or cookie-domain changes across environments

Core Security Gates

Block the change until fixed if any of these are true:

• client-reachable code can import or derive a secret
• protected data mutation trusts client-provided identity or role claims
• a TanStack Start loader or shared utility performs privileged work without an explicit server boundary
• a route relies on beforeLoad only, without equivalent server-side protection for protected actions
• loader output, SSR context, or hydrated state serializes secrets or internal-only auth data
• a server route is accepting browser state-changing input without auth/origin/CSRF strategy
• webhook handlers trust payloads before signature verification
• auth/session cookies are configured loosely without deliberate environment rules

<validation_checklist>

Verification

Before claiming completion:

• verify the relevant rule-file checklist
• run the project checks that prove the change did not break the app
• summarize what was hardened and what remains stack-dependent

For detailed review and command guidance, use rules/validation.md.

</validation_checklist>