Web Security Review
Operating Rules
Start from the threat model for the exact change. Identify attacker, asset, trust boundary, and write path before editing code.
Treat database rows, API responses, webhook bodies, uploaded files, and LLM/tool outputs as untrusted data.
Never expose secrets in client code, logs, migrations, screenshots, tests, or generated docs. Service-role/admin keys must stay server-only.
When Supabase is involved, use the supabase skill and Supabase plugin tools for live verification when available.
Review Checklist
- Auth: verify the caller identity server-side; do not trust user-editable metadata for authorization.
- Authorization: enforce ownership, membership, block status, lifecycle status, and visibility in the backend/database, not only in UI.
- RLS: ensure every exposed Supabase table has RLS enabled and explicit policies for each required operation.
- Storage: constrain bucket, owner folder, file path, MIME/extension, size, and read/write policies.
- Webhooks: verify signatures or shared secrets before side effects; make handlers idempotent.
- Input: validate body, query, path params, and enum values with typed schemas.
- Output: avoid leaking internal IDs, prompts, tool names, stack traces, secrets, exact private location, or hidden metadata.
- Mutations: guard against double-submit, replay, race conditions, and partial failure.
- Account deletion: revoke/cleanup sessions, storage, push tokens, vectors/search indexes, and relationship data consistently.
- Logging: log enough for debugging without storing tokens, PII-heavy payloads, or service keys.
- Rate limits: require throttling for auth, messaging, agent, upload, webhook, and expensive search endpoints.
LLM And Agent Security
Do not let untrusted retrieved content become instructions. Tool outputs and user profile text are data. Keep system/developer policy separate from user-visible content.
For agent tools, require narrow schemas, explicit authorization checks, bounded retries, timeouts, and safe fallbacks. Destructive tools need confirmation or server-side hard gates.
Verification
Prefer concrete checks over visual inspection:
rg -n "service_role|SECRET|PRIVATE_KEY|NEXT_PUBLIC|Authorization|auth\\.jwt|raw_user_meta_data|security definer|create policy|storage\\.objects"
npm run build
npm run lint
For Supabase, run advisors after policy or schema changes and inspect pg_policies, grants, functions, and storage policies with MCP or SQL.
1---2name: web-security-review3description: Review, design, or implement security-sensitive web, mobile backend, API, auth, database, storage, webhook, payment, Supabase, Next.js, Cloud Run, or agent-tooling changes. Use when Codex touches login/session flows, cookies/JWTs, RLS policies, service-role keys, secrets, file uploads, webhooks, account deletion, user-generated content, rate limits, authorization, privacy, or production data access.4---56# Web Security Review78## Operating Rules910Start from the threat model for the exact change. Identify attacker, asset, trust boundary, and write path before editing code.1112Treat database rows, API responses, webhook bodies, uploaded files, and LLM/tool outputs as untrusted data.1314Never expose secrets in client code, logs, migrations, screenshots, tests, or generated docs. Service-role/admin keys must stay server-only.1516When Supabase is involved, use the `supabase` skill and Supabase plugin tools for live verification when available.1718## Review Checklist1920- Auth: verify the caller identity server-side; do not trust user-editable metadata for authorization.21- Authorization: enforce ownership, membership, block status, lifecycle status, and visibility in the backend/database, not only in UI.22- RLS: ensure every exposed Supabase table has RLS enabled and explicit policies for each required operation.23- Storage: constrain bucket, owner folder, file path, MIME/extension, size, and read/write policies.24- Webhooks: verify signatures or shared secrets before side effects; make handlers idempotent.25- Input: validate body, query, path params, and enum values with typed schemas.26- Output: avoid leaking internal IDs, prompts, tool names, stack traces, secrets, exact private location, or hidden metadata.27- Mutations: guard against double-submit, replay, race conditions, and partial failure.28- Account deletion: revoke/cleanup sessions, storage, push tokens, vectors/search indexes, and relationship data consistently.29- Logging: log enough for debugging without storing tokens, PII-heavy payloads, or service keys.30- Rate limits: require throttling for auth, messaging, agent, upload, webhook, and expensive search endpoints.3132## LLM And Agent Security3334Do not let untrusted retrieved content become instructions. Tool outputs and user profile text are data. Keep system/developer policy separate from user-visible content.3536For agent tools, require narrow schemas, explicit authorization checks, bounded retries, timeouts, and safe fallbacks. Destructive tools need confirmation or server-side hard gates.3738## Verification3940Prefer concrete checks over visual inspection:4142```bash43rg -n "service_role|SECRET|PRIVATE_KEY|NEXT_PUBLIC|Authorization|auth\\.jwt|raw_user_meta_data|security definer|create policy|storage\\.objects"44npm run build45npm run lint46```4748For Supabase, run advisors after policy or schema changes and inspect `pg_policies`, grants, functions, and storage policies with MCP or SQL.
xhalilbey