Web Security Audit

Web Security Audit

A read-only security pass for any web project — built so it works the same on a Next.js app, a SvelteKit site, an Express API, or a completely different stack, and so a non-security person can trust the result.

How this skill works (read this first)

You (Claude) are the auditor. Do the 21 checks below by reading the code and applying judgment. Do not rely on a tool's raw regex output as the verdict — that is exactly what produces false positives (a regex sees KEY in a variable name and panics, even when the key is public by design and the value is empty). You read the code, understand the context, and decide.

The bundled security-audit.sh (run.ps1 on Windows) is an optional accelerator for large codebases. It is never required. Treat its output as a list of candidates to confirm, not findings. If the harness blocks running it, or you can't trust the project enough to execute its scripts, just do the checks by hand with Grep/Read — that path always works.

Ground rules

1. Read-only by default. The audit never edits files, installs packages, runs audit fix, or modifies dependencies. Reporting is the deliverable.
2. Never execute untrusted project code. Dependency-audit commands do not run project code, but they do use the network; obtain permission first. tsc / eslint / build steps execute the project's own config and plugins — only run them on a project the user already trusts, and never let a tool auto-install a missing binary (no npx <pkg> that hits the network).
3. Confirm before you flag. Every candidate must be opened and read. A match in a test fixture, an .env.example template, a comment, or a public-by-design key is not a finding.
4. Adapt to the repo. Monorepo? Run the checks per app (apps/web, packages/*) — auto-detection that only looks at the repo root will miss nested apps. Non-JS project (Python, Go…)? Say so and scope to what applies.

Production-safe audit boundary

Start with source, configuration, tests and dependency manifests. Against a live site, stay passive and low-volume: normally one request per page/header you must verify. Never brute-force credentials, fuzz production endpoints, enumerate at scale, bypass bot protection, place orders, trigger email/SMS/AI generation, run load/DoS tests, or probe infrastructure owned by a third party. If static evidence is enough, make zero production requests.

Dependency audits are network operations. Run them only when the user permits network access; otherwise report them as not run. Never print a discovered secret, token, email address, TOTP or raw provider error into the report—use file:line and [REDACTED].

The 21 checks — what to look for and how to read the result

For each one:

1. Find — grep the patterns across source files (skip node_modules, build output: .next .nuxt .svelte-kit dist build .output coverage).
2. Open & read — confirm it's real in context.
3. Decide — real issue, accepted-with-reason, or false positive.

Details where reading-with-judgment matters most:

• #1 client DB access — flag an ORM/DB client import (@prisma/client, drizzle-orm, mongoose, pg, mysql2, @supabase/supabase-js used as a service-role client, …) reachable from browser code: a React "use client" file, a .vue/.svelte component, or anything bundled to the client. Server components, route handlers, server actions, and *.server.ts are fine.
• #4 secrets in public env vars — this is the #1 source of false positives. See the allowlist below. Only flag when a real, non-empty secret value is assigned to a client-exposed variable. Empty templates and public-by-design keys are PASS.
• Static encrypted pages — client-side AES-GCM can protect a published blob, but it is not server authentication: attackers can copy the ciphertext and guess passwords offline, there is no per-user revocation, and any same-origin XSS can steal a derived key held in browser storage. Require a high-entropy password, strong KDF, authenticated encryption, noindex/no-store, CSP and an explicit acceptance of the shared-password model; use server-side access control when individual identity or revocation matters.
• #7 rate limiting — only expensive routes need it: AI generation, payments, email/SMS, anything that costs money or compute per call. A plain CRUD GET does not need a rate limiter to pass.
• #8 sensitive logs — include PII and transient credentials: email/account identifiers, auth headers, session IDs, OTP/TOTP codes and raw upstream error bodies. Log a stable category/request ID and redact values.
• #9 dependency audit — with network permission, run npm audit / pnpm audit / yarn audit (no project code executes). Report high/critical as errors, low/moderate as warnings. Do not run audit fix --force.
• #10/#11 typecheck & lint — these execute project config. Run only on a trusted project, using the locally installed binary (node_modules/.bin/tsc, node_modules/.bin/eslint). If not installed, skip and say so — never auto-install.
• #15 XSS — an innerHTML match is a candidate, not an automatic finding. Trace every interpolated value. Constants and correctly escaped values can be safe; decrypted/generated HTML needs an explicit trust boundary and a CSP.
• #17 URL sinks — validate stored, generated and provider-supplied URLs at the final sink (href, window.open, redirects). Reject javascript:, data:, embedded credentials and non-HTTP(S) schemes.
• #18 cost ordering — for AI, image/logo enrichment, payment, email and SMS, prove the order in code: cheap validation → bot/auth check → rate limit → entitlement/quota/credit reservation → paid call. A limiter after the provider call does not protect the bill.
• #19 update authenticity — HTTPS and encryption are not artifact authentication. Before tar, docker compose, bash or replacing code, verify a signature or encrypt-then-MAC tag, cap size, extract to a scratch directory, validate required files, then swap. Root installers must use mktemp, not predictable /tmp/name files. Shared-key HMAC does not protect against a malicious holder of that key; prefer public-key signatures when that threat matters.
• #20 fail closed — cap response/body/ciphertext sizes and KDF work factors before expensive processing. Validate decrypted JSON types, enums, uniqueness, numeric finiteness/ranges and totals. Missing action lists must not default to [] when empty means delete, sell or revoke. Validate mode enums before selecting production/live defaults.
• #21 containers — review read_only, cap_drop, no-new-privileges, non-root users, secret mounts and network exposure per service. Absence is a hardening opportunity, not automatically exploitable.

Public-by-design — do NOT flag these as leaks

These are meant to live in the browser. Finding them in client code or in a NEXT_PUBLIC_* / VITE_* / PUBLIC_* variable is expected and correct. Verify the intended protection exists, but do not report them as secret leaks:

• Supabase anon key (NEXT_PUBLIC_SUPABASE_ANON_KEY) — public; protected by Row Level Security policies. Confirm RLS is on; the key itself is fine.
• Stripe publishable key (pk_live_…, pk_test_…, NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY) — designed to be exposed. Only the secret key (sk_live_… / sk_test_…) is a real leak.
• Firebase web config (apiKey, authDomain, projectId, …) — public by design; protected by Firebase Security Rules + allowed-domains.
• Clerk publishable key (pk_…, NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY) — public.
• Analytics / monitoring tokens — PostHog (NEXT_PUBLIC_POSTHOG_KEY), Sentry DSN (NEXT_PUBLIC_SENTRY_DSN), GA/GTM IDs, Amplitude, Mixpanel browser tokens — all client-side by design.
• Map / search browser tokens — Mapbox pk.…, Google Maps browser key, Algolia search-only key — public, ideally restricted by domain/referrer.
• Empty or placeholder values — .env.example, .env.sample, .env.template with empty values or placeholders (your-key-here, xxx, changeme, sk_test_xxx, <...>) are templates, not secrets. Only a real value committed to a real .env is a leak.

When you skip one of these, say why in the report (e.g. "anon key is public, RLS confirmed in supabase/") so the user learns the reasoning, not just the verdict.

Always treat as a real secret (Error)

A literal value matching any of these committed to the repo is a genuine leak — rotate it immediately:

• OpenAI / Anthropic sk-… ; Stripe secret sk_live_… / sk_test_…
• AWS AKIA… access keys ; Google server key AIza… ; Google OAuth ya29.…
• GitHub ghp_… / gho_… / github_pat_… ; GitLab glpat-…
• Slack xoxb-… / xoxp-… ; SendGrid SG.…
• JWTs hardcoded in source ; private keys (-----BEGIN … PRIVATE KEY-----)
• DB connection strings with credentials (postgres://user:pass@…, mongodb+srv://user:pass@…, mysql://…, redis://…)

Also confirm .env, .env.* (except .env.example) are git-ignored.

Optional: the bash accelerator

For big repos you may run the bundled script to generate candidates faster.

# macOS / Linux / CI — from the project root
bash <skill-dir>/security-audit.sh           # offline/local, warnings don't fail
bash <skill-dir>/security-audit.sh --network # opt in to registry dependency audit
bash <skill-dir>/security-audit.sh --ci      # exit 1 on any error (for CI)

# Windows (delegates to Git Bash automatically)
& "<skill-dir>\run.ps1"
& "<skill-dir>\run.ps1" --ci

<skill-dir> is wherever this skill is installed (e.g. ~/.claude/skills/web-security-audit).

The script is read-only except --fix. Do not use --fix by default; it modifies files (eslint --fix, non-forced npm audit fix). Only run it on explicit user request, and review the git diff afterward. Whatever the script prints, still confirm each candidate yourself per the allowlist above.

Report template

After the pass, give the user a single table plus a plain-language verdict:

| # | Check | Result | Detail |
|---|-------|--------|--------|
| 1 | Client DB access            | PASS / FAIL | file:line or "none" |
| 2 | API auth                    | …           | … |
…
| 15| XSS sinks                   | …           | … |
…
| 21| Container least privilege   | …           | … |

Then, per real finding:

Finish with a one-line verdict in plain words ("No real security holes on the static checks. One thing to double-check: …"), and for any item you skipped as a false positive, one line on why it's safe. End with what you did not run (e.g. "didn't execute typecheck/lint — say the word and I'll run them on this trusted repo").

The 9 principles behind the checks

1. Don't talk to the database directly from the client.
2. Gatekeep every action (auth on every endpoint).
3. Don't hide, withhold (enforce premium server-side).
4. Keep secrets off the browser (public-by-design keys excepted).
5. Don't do math on the phone (price/score server-side).
6. Sanitize everything (validate inputs with a schema).
7. Rate limit expensive endpoints.
8. Don't log sensitive stuff.
9. Audit with a second pair of eyes (a different model catches different blind spots).

Source

Upstream: https://github.com/buffalodebile/vibecoding-security-audit Author: Burak Eregar (Mr Black AI). MIT licensed.