Secure before you ship

# AGENTS.md: security baseline

These rules apply to every change in this repository, whatever the stack.

## Secrets
- Never hard-code API keys, tokens, passwords or connection strings. Read them from environment variables.
- Never put a secret in a variable the browser can see: `NEXT_PUBLIC_*`, `VITE_*`, `PUBLIC_*`, `EXPO_PUBLIC_*`,
  or anything bundled into client JavaScript. If the front end needs a third-party API, call it through a server route.
- Never log secrets, full request headers, or whole environment objects.
- Keep `.env`, `.env.local` and similar files out of git. Keep `.env.example` up to date with dummy values.
- If you find a secret committed to git, stop and tell the human. Deleting the line is not enough —
  it must be rotated with the provider.

## Auth and access
- Every route, server action and API handler that reads or changes user data checks who the user is *on the server*.
- Check authorisation on the resource, not just login: "is this user allowed to touch *this* row?"
- Admin features check an admin role stored server-side, never a flag sent by the client.
- Database access rules (Supabase RLS, Firebase Security Rules, Postgres grants) are the real boundary.
  Do not turn them off to make something work.

## Input and output
- Validate all input on the server with a schema (zod, valibot, pydantic). Client validation is for UX only.
- Use parameterised queries or the ORM. Never build SQL with string concatenation.
- Do not render user content as raw HTML (`dangerouslySetInnerHTML`, `v-html`, `set:html`, `innerHTML`)
  unless it has been sanitised.
- File uploads: check type and size server-side, store outside the web root or in object storage, never trust the filename.

## Cost and abuse
- Any endpoint that calls a paid API (LLMs, email, SMS, maps) needs auth or rate limiting, and ideally both.
- Set spending caps or budget alerts on paid providers where they exist.

## Dependencies
- Prefer well-known packages. Check that a package name is real and spelled correctly before installing it.
- Do not add a dependency for something the platform already does.

## When unsure
Ask the human, or run the `launch-check` skill and report what it finds.

# CLAUDE.md

@AGENTS.md

## Claude Code notes
- Skills from this loadout live in `.claude/skills/`: `launch-check`. Use them when their description matches the task.
- Follow AGENTS.md above; where this file and AGENTS.md disagree, AGENTS.md wins.

<!-- From the Agent Loadout "Secure before you ship" v1.0.0 — https://loadout.jnw-it.com/loadouts/secure-before-you-ship/ -->

# GEMINI.md

@./AGENTS.md

## Gemini CLI notes
- Skills from this loadout live in `.agents/skills/`: `launch-check`. Use them when their description matches the task.
- Follow AGENTS.md above; where this file and AGENTS.md disagree, AGENTS.md wins.

<!-- From the Agent Loadout "Secure before you ship" v1.0.0 — https://loadout.jnw-it.com/loadouts/secure-before-you-ship/ -->

---
description: Never expose or hard-code secrets
alwaysApply: true
---

- Read secrets from environment variables. Never write a real key, token or password into code, tests, docs or examples.
- Client-exposed prefixes (`NEXT_PUBLIC_`, `VITE_`, `PUBLIC_`, `EXPO_PUBLIC_`) are public. Never put a secret behind one.
- Calls to paid or secret-key APIs go through server code, never directly from the browser.
- Never log tokens, cookies, auth headers or whole `process.env` / `os.environ` objects.
- When adding a variable, add a dummy entry to `.env.example` and make sure `.env*` (except the example) is git-ignored.
- If you spot a secret already committed, stop and tell the human that it needs rotating with the provider.

---
name: launch-check
description: Pre-launch security and readiness audit for web apps. Use when the user says they are about to launch, deploy, go live, share the link, or asks "is my app safe?".
---

# Launch check

Produce a plain-English, severity-ranked fix list that a non-expert can act on.
**Report first. Do not change code until the human picks which fixes to apply.**

## Steps

1. **Map the app (2 minutes, no more).** Identify the framework, where server code runs, the database and
   auth provider, the hosting platform, and every third-party API it calls. Read `package.json` /
   `requirements.txt` / `pyproject.toml`, the env example file, and the routes or API folder.

2. **Work through `references/checklist.md`.** For each item decide: pass, fail, or can't tell.
   Prefer evidence from the code. Useful searches:
   - Secrets in code: `git grep -nE "(sk_live|sk_test|sb_secret_|service_role|AKIA[0-9A-Z]{16}|ghp_|xox[bp]-|-----BEGIN)"`
   - Secrets in history: `git log -p --all -S "sk_live" | head` (repeat for other patterns that hit)
   - Client-exposed env: `git grep -nE "(NEXT_PUBLIC_|VITE_|PUBLIC_|EXPO_PUBLIC_)[A-Z_]*(SECRET|PRIVATE|SERVICE|TOKEN)"`
   - Committed env files: `git ls-files | grep -E "(^|/)\.env"`
   - Raw HTML: `git grep -nE "dangerouslySetInnerHTML|v-html|set:html|innerHTML\s*="`
   - String-built SQL: `git grep -nE "(query|execute|raw)\(.*(\+|\$\{|f\")"`
   - Server routes without an auth check: list every API route and note which ones read the user.

3. **Check the database rules** if there is one. Supabase: every public table has RLS enabled with real
   policies. Firebase: rules are not `allow read, write: if true`. Plain Postgres/MySQL: the app user is not a superuser.

4. **Check abuse and cost.** List every endpoint that triggers a paid API. Note whether it requires auth and is rate limited.

5. **Write the report** in this format:

```
Launch check — <app name> — <date>
Verdict: Not ready / Ready with fixes / Ready

CRITICAL (fix before anyone else sees the link)
1. <what is wrong, in one sentence> — <file:line>
   Why it matters: <the realistic bad outcome>
   Fix: <the concrete change>

HIGH (fix before launch day)
...
MEDIUM (fix in the first week)
...
Couldn't check: <items needing dashboard access, with how the human can check them>
```

Keep each finding to three or four lines. Do not pad the report with passes; list passes as a single line count.

6. **Offer the fixes.** Ask which to apply. Rotated keys, dashboard settings and DNS changes are jobs for the
   human — explain exactly where to click, but do not pretend you did them.

# Launch checklist

Severity in brackets is the default; raise it if the data is sensitive.

## Secrets
- [Critical] No live secret keys in source code or config files.
- [Critical] No secrets in client-exposed env vars or the built front-end bundle.
- [Critical] No `.env` files tracked by git. If one ever was, the keys in it need rotating.
- [High] Secrets in git history have been rotated (removing the commit is not enough).
- [Medium] `.env.example` exists and lists every variable with a dummy value.

## Authentication
- [Critical] Every API route / server action that touches user data checks the session on the server.
- [Critical] Admin pages and endpoints check a server-side role, not a client flag or a hidden URL.
- [High] Password reset and magic-link flows expire and are single use (default on most providers — confirm it is not disabled).
- [Medium] Email confirmation is required before an account can do anything costly.

## Data access
- [Critical] Database rules are on: Supabase RLS on every public table, Firebase rules not open, no public buckets with private files.
- [Critical] Users cannot read or change another user's rows by changing an ID in the request (test one by hand).
- [High] Update endpoints cannot change ownership or role fields.
- [High] Queries are parameterised; no string-built SQL.

## Abuse and cost
- [Critical] Endpoints that call paid APIs (LLM, email, SMS) need auth.
- [High] Those endpoints are rate limited per user or IP.
- [High] Provider spending limits or budget alerts are set.
- [Medium] Sign-up has some bot friction (captcha, email confirmation or invite).

## Input and output
- [High] Server-side validation on every input.
- [High] No unsanitised user HTML rendered.
- [Medium] Uploads checked for type and size server-side.
- [Medium] Error responses do not leak stack traces or SQL.

## Platform
- [High] HTTPS only. Cookies are `Secure`, `HttpOnly` and `SameSite=Lax` or stricter.
- [Medium] Security headers set: `Content-Security-Policy` (even a basic one), `X-Content-Type-Options: nosniff`,
  `Referrer-Policy`, `frame-ancestors` / `X-Frame-Options`.
- [Medium] CORS is not `*` on endpoints that use cookies.
- [Medium] Debug mode, test routes and seed endpoints are off in production.

## Dependencies
- [High] `npm audit --omit=dev` / `pip-audit` shows no critical issues in runtime dependencies.
- [Medium] Lockfile committed.
- [Medium] No unfamiliar or misspelt packages (check anything you do not recognise on the registry).

## Readiness (not security, but people notice)
- [Medium] Privacy policy and terms exist if you collect personal data (UK GDPR applies to UK users).
- [Medium] Error tracking or at least server logs are on.
- [Medium] Database backups are on and you know how to restore one.