Security prompts and rules for Cursor, Claude Code and other AI coding agents

---
description: Security rules for this project
alwaysApply: true
---

# Security rules

- Never hard-code secrets, API keys, tokens or passwords. Read them from environment variables on the server only.
- Never put secrets in variables with a NEXT_PUBLIC_, VITE_ or PUBLIC_ prefix: those are bundled into the browser.
- Check the session and the user's permissions on every API route, server action and Edge Function before returning or changing data.
- With Supabase, enable Row Level Security on every table and write owner-only policies. Never use a service_role or sb_secret_ key in client code.
- Set session cookies as HttpOnly, Secure and SameSite.
- Add rate limiting to login, signup, password reset and any endpoint that sends email or calls a paid API.
- Vet new dependencies before adding them: prefer well-maintained packages and avoid ones you cannot verify.
- Never log secrets, tokens or personal data.
- When you change anything security-related, explain it in plain English and say how to verify it.

# Security rules

- Never hard-code secrets, API keys, tokens or passwords. Read them from environment variables on the server only.
- Never put secrets in variables with a NEXT_PUBLIC_, VITE_ or PUBLIC_ prefix: those are bundled into the browser.
- Check the session and the user's permissions on every API route, server action and Edge Function before returning or changing data.
- With Supabase, enable Row Level Security on every table and write owner-only policies. Never use a service_role or sb_secret_ key in client code.
- Set session cookies as HttpOnly, Secure and SameSite.
- Add rate limiting to login, signup, password reset and any endpoint that sends email or calls a paid API.
- Vet new dependencies before adding them: prefer well-maintained packages and avoid ones you cannot verify.
- Never log secrets, tokens or personal data.
- When you change anything security-related, explain it in plain English and say how to verify it.

# Security rules

- Never hard-code secrets, API keys, tokens or passwords. Read them from environment variables on the server only.
- Never put secrets in variables with a NEXT_PUBLIC_, VITE_ or PUBLIC_ prefix: those are bundled into the browser.
- Check the session and the user's permissions on every API route, server action and Edge Function before returning or changing data.
- With Supabase, enable Row Level Security on every table and write owner-only policies. Never use a service_role or sb_secret_ key in client code.
- Set session cookies as HttpOnly, Secure and SameSite.
- Add rate limiting to login, signup, password reset and any endpoint that sends email or calls a paid API.
- Vet new dependencies before adding them: prefer well-maintained packages and avoid ones you cannot verify.
- Never log secrets, tokens or personal data.
- When you change anything security-related, explain it in plain English and say how to verify it.

Audit this repository for exposed secrets:
1. Search all source files, config files and .env files for API keys, tokens, passwords and private keys, including Supabase service_role and sb_secret_ keys.
2. List every secret in a variable with a NEXT_PUBLIC_, VITE_ or PUBLIC_ prefix, because those reach the browser.
3. Move each one to a server-only place (API route, Edge Function or backend) that reads it from a secret.
4. Make sure .env files are in .gitignore and tell me which keys I must rotate.
Explain each change in plain English.

Audit Row Level Security in this Supabase project:
1. List every table in the public schema and whether RLS is enabled.
2. Enable RLS on every table that has it off.
3. Add owner-only policies for select, insert, update and delete using auth.uid(). Flag any table that is meant to be public and explain why.
4. Find views over protected tables and set security_invoker = true.
Show me the SQL before running it and explain each policy in plain English.

Do a security review of this app before launch and fix what you find, most severe first:
1. Secrets: nothing sensitive in client code, git history notes or public environment variables.
2. Auth: every API route and server action checks the session and the user's permissions.
3. Database: access rules (RLS or equivalent) on every table, scoped to the owner.
4. Headers: Content-Security-Policy, Strict-Transport-Security, frame-ancestors, X-Content-Type-Options and Referrer-Policy.
5. Cookies: HttpOnly, Secure and SameSite on session cookies.
6. Abuse: rate limits on login, signup, password reset and paid or email-sending endpoints.
7. Production: source maps off, no .env or .git files deployed, debug routes removed.
Explain each change in plain English and tell me how to verify it.