Ship It Safe

Act as a careful security reviewer. Scan my project for secrets and explain what you find in plain English. I'm a [SKILL LEVEL].

Tech stack: [TECH STACK]
Services I use: [SERVICES]
Host: [HOST]

Please:
1. Search every file (including config files, scripts, and old or unused files) for anything that looks like an API key, secret, password, token, private key, or database connection string. List each one with the file and line. Show only the first 4 characters of any value, never the full value.
2. For each one, tell me: is it meant to be public (like a Supabase publishable key, called the anon key on older projects, or a Firebase web config), or must it stay secret (like an OpenAI key, a Stripe secret key, or a Supabase secret key, called the service_role key on older projects)?
3. Tell me which values end up in the browser. Explain how my framework decides this (for example NEXT_PUBLIC_ in Next.js or VITE_ in Vite), and flag any secret that's exposed that way.
4. Check that .env and similar files are listed in .gitignore.
5. For each secret that's in the wrong place, show how to move it to an environment variable used only on the server, one fix at a time.
6. Create a .env.example file with the variable names but no real values.

Don't print full secret values anywhere in your answer.

My app calls [SERVICE] directly from the browser, which exposes my secret key. Help me move it to the server.

Tech stack: [TECH STACK]
Host: [HOST]
Where the call happens now: [FILE NAME OR "PLEASE FIND IT"]

Please:
1. Explain in 2-3 sentences why a key in browser code is visible to anyone, even if it's in an environment variable.
2. Create a server-side route (API route, server action, or serverless/edge function, whichever fits my stack) that makes the call using the key from a server-only environment variable.
3. Update the front end to call my route instead of the service directly.
4. Make the route check that the user is logged in (if my app has logins) and validate the input before calling the service.
5. Return only the data the front end needs, never the raw key or full error details.
6. Tell me exactly where to add the environment variable on [HOST], and to remove any browser-exposed version of it.
7. List every file you changed.

I need to check whether any secrets were ever committed to my Git history, not just the current code. I'm a [SKILL LEVEL], so give me exact commands and explain them.

My computer: [WINDOWS / MAC / LINUX]
Repo hosted on: [GITHUB / GITLAB / NONE]
Is the repo public? [YES / NO / NOT SURE]
Services I use: [SERVICES]

Please:
1. Explain in plain English why deleting a key from my code doesn't remove it from Git history.
2. Recommend a free, well-known secret scanning tool (such as gitleaks or trufflehog), with exact install and run commands that scan the full history.
3. Tell me how to read the results and how to spot false alarms.
4. Tell me whether my repo host has built-in secret scanning or push protection and how to turn it on. (On GitHub, secret scanning runs free and automatically on public repos, and push protection for personal accounts blocks known secret types in pushes to public repos by default. Private personal repos usually aren't covered, so a local scanner still matters.)
5. If a real secret is found: tell me to rotate it at the provider FIRST (point me to Section 8 of my security pack), and only then explain the options for cleaning history (such as git filter-repo), including the downsides (rewriting history, force-pushing, and forks or clones that still have the old copy).

Don't ask me to paste any secret values into this chat.

Help me organize the environment variables for my app properly.

Tech stack: [TECH STACK]
Host: [HOST]
Services: [SERVICES]

Please:
1. List every environment variable my code uses (search for process.env, import.meta.env, Deno.env, etc.) and what each is for.
2. Mark each as "safe for the browser" or "server only," and make sure server-only ones don't use a browser-exposing prefix.
3. Recommend using separate keys for development and production where the service supports it (for example Stripe test keys vs live keys) and explain why.
4. Make the app fail with a clear error message at startup if a required variable is missing, without printing its value.
5. Show me where to set these on [HOST], including which environments (production, preview, development) each one needs.
6. Update .env.example and .gitignore.

Act as a database security reviewer. Audit Row Level Security (RLS) in my Supabase project. I'm a [SKILL LEVEL].

App: [APP IDEA]
Tables I know about: [TABLE NAMES OR "PLEASE LIST THEM"]
Who should see what: [WHO SHOULD SEE WHAT]

Please:
1. Explain in plain English what RLS is and why the publishable key (the anon key on older projects) being public makes it essential. Mention that tables created in the Supabase Table Editor get RLS turned on automatically, but tables created with SQL (including by an AI tool or a migration) don't unless the SQL turns it on.
2. Give me a SQL query I can run in the Supabase SQL editor that lists every table in my exposed schemas (usually public) and whether RLS is enabled.
3. Give me a query that lists all existing policies.
4. For each table, tell me: is RLS on? Do the policies match "who should see what"? Flag any table with RLS off, any policy that uses "true" for everyone, and any table with RLS on but no policies (which blocks all access).
5. For each problem, write the fix as SQL, one table at a time, using auth.uid() to match rows to the logged-in user. Cover select, insert, update, and delete separately.
6. Check table grants too: RLS decides which rows a role can reach, but grants decide whether the anon and authenticated roles can select, insert, update, or delete at all. Suggest revoking anything a role doesn't need.
7. Check views, functions (especially SECURITY DEFINER ones), and storage buckets, which have their own rules.
8. Give me a way to test each policy as two different users. Remember that the SQL editor runs as an admin role and skips RLS, so a query working there doesn't prove a policy works.

Don't suggest using the secret key (or legacy service_role key) in the app to "fix" access errors.

I'm adding a new table to my Supabase database. Write it with Row Level Security from the start.

Table purpose: [TABLE PURPOSE]
Columns I need: [COLUMNS OR "SUGGEST THEM"]
Who can read: [WHO CAN READ]
Who can create, edit, delete: [WHO CAN CREATE, EDIT, DELETE]

Please:
1. Write the CREATE TABLE SQL with an owner column linked to the user (if it fits) and sensible defaults.
2. Enable RLS in the same migration.
3. Write separate policies for select, insert, update, and delete, explaining each in one sentence.
4. Make sure users can't set the owner column to someone else's ID on insert or update.
5. Add indexes on columns used in policies, if helpful.
6. Give me two test queries showing an allowed and a blocked action.

Review my Firebase security rules and help me lock them down. I'm a [SKILL LEVEL].

Products used: [FIRESTORE / REALTIME DATABASE / STORAGE]
My current rules: [PASTE RULES]
My data structure: [MY DATA STRUCTURE]
Who should see what: [DESCRIPTION]

Please:
1. Explain in plain English what my current rules allow, including anything open to everyone or open until a date (test mode).
2. Explain why the Firebase web config being public is normal, and why that makes rules essential.
3. Write new rules that require login and match request.auth.uid to the owner, with separate read and write rules.
4. Add basic validation for writes (required fields, types, sensible size limits).
5. Tell me how to test the rules with the Firebase Emulator or Rules Playground before publishing.
6. Mention App Check: it helps block requests that don't come from my real app, which protects against some abuse, but it complements security rules and doesn't replace them.

Review the authentication setup for my app and flag risky settings. I'm a [SKILL LEVEL].

Auth provider: [AUTH PROVIDER]
Login methods: [LOGIN METHODS]
Host and live URL: [HOST, URL]

Please check and explain each in plain English:
1. Redirect URLs: are only my real domains allowed (no wildcards that allow other sites, no leftover localhost in production)?
2. Email confirmation: is it required before users can access data, and should it be?
3. Password rules and leaked-password protection, if my provider offers it.
4. Rate limits or bot protection (like CAPTCHA) on sign up, login, and password reset.
5. Session settings: how long sessions last and how logout works.
6. Whether sign ups should be open to anyone, or invite-only, for my app.
7. Whether there's an admin role, and how it's assigned (it should never be something a user can set on themselves).

For each item, tell me where to find the setting in my provider's dashboard and what you recommend.

Help me test whether one user can access another user's data in my app. Act as a friendly security tester and explain each step.

Tech stack: [TECH STACK]
Private data in my app: [PRIVATE DATA IN MY APP]
How data is fetched: [HOW DATA IS FETCHED]

Please:
1. List every page, API route, and database query that reads or changes private data.
2. For each, tell me where the "is this the owner?" check happens: in the database (RLS/rules), on the server, or only in the front end. Flag anything checked only in the front end.
3. Look for routes that take an ID from the URL or request body (like /api/notes/123) and check whether they confirm the logged-in user owns that ID.
4. Give me a manual test plan: create two test accounts, then try to view, edit, and delete User A's data while logged in as User B, and while logged out. Include how to do this from the browser DevTools console or with curl.
5. Fix each problem you find, one at a time, and list the files changed.

My app has [ADMIN PAGES / PAID-ONLY FEATURES / MODERATOR TOOLS]. Make sure they're properly protected.

Tech stack: [TECH STACK]
Auth provider: [AUTH PROVIDER]
How roles are stored now: [HOW ROLES ARE STORED NOW]

Please:
1. Find where roles or paid status are checked. Flag any check that happens only in the front end (hiding a button doesn't protect the action).
2. Check whether a user could make themselves an admin or paid user, for example by updating their own profile row.
3. Move role checks to the server or database, and show how to store roles where users can't edit them.
4. Protect every admin API route and database action, not just the admin page.
5. Give me a test: as a normal user, try to call each admin action directly.

Add input validation to my app. Explain it simply, because I'm a [SKILL LEVEL].

Tech stack: [TECH STACK]
Forms and API routes: [LIST OR "PLEASE FIND THEM ALL"]

Please:
1. Explain in 2 sentences why front-end validation alone isn't enough (anyone can send requests straight to my server).
2. Find every place that accepts user input: forms, API routes, server actions, URL parameters, and file uploads.
3. Add server-side validation for each, using a schema library that fits my stack (such as Zod), checking type, required fields, length limits, and allowed values.
4. For file uploads, limit file type and size, and don't trust the file name.
5. Return friendly error messages that don't reveal internal details.
6. List every file changed and give me 3 bad inputs to test each form with.

Check my app for common web vulnerabilities. For each one, first explain in one or two plain sentences what the attack is, then check my code.

Tech stack: [TECH STACK]

Check for:
1. Cross-site scripting (XSS): user content shown as HTML without escaping (e.g. dangerouslySetInnerHTML, innerHTML, v-html, or Markdown rendered without sanitizing).
2. Injection: database queries or shell commands built by gluing user input into strings, instead of using parameters or the query builder.
3. Insecure direct object references: routes that trust an ID without checking ownership.
4. Open redirects: redirecting to a URL taken from user input.
5. CORS set to allow any origin on routes that use cookies or return private data.
6. Error messages or logs that reveal stack traces, keys, or private data to users.
7. Missing basic security headers where my host doesn't set them.

For each finding: the file and line, how serious it is (high/medium/low) and why, and the fix. If you find nothing for an item, tell me what you checked.

Check that my webhook endpoint is secure.

Tech stack: [TECH STACK]
Webhook from: [WEBHOOK FROM]
Endpoint file: [FILE NAME OR "PLEASE FIND IT"]

Please:
1. Explain in plain English why anyone can send a request to my webhook URL, and why signature verification matters.
2. Verify the signature using the provider's official library and the webhook signing secret from a server-only environment variable. Make sure the raw request body is used if the provider requires it (Stripe does).
3. Reject requests that fail verification, with a 400 response.
4. Handle duplicate deliveries safely (providers retry), so the same event doesn't grant access or credit twice.
5. Confirm important details (like the amount and the product) from the verified event or the provider's API, not from data the browser sent.
6. Tell me how to test it locally with the provider's CLI or test mode.

Add rate limiting to my app. Explain it simply.

Tech stack: [TECH STACK]
Host: [HOST]
Expensive or sensitive routes: [EXPENSIVE OR SENSITIVE ROUTES]

Please:
1. List every route and rank them by risk (costs money, sends email, writes to the database, public).
2. Recommend a rate limiting approach that works on my host (serverless functions don't keep memory between requests, so explain if I need a store like Redis/Upstash or a host feature).
3. Add limits per logged-in user and per IP, with sensible starting numbers I can change, and explain why you picked them.
4. Return a clear "too many requests" response (status 429) and show a friendly message in the UI.
5. Tell me how to test that the limit works.

My app uses [AI PROVIDER] and I want to make sure it can't run up a huge bill.

Tech stack: [TECH STACK]
AI features: [AI FEATURES]
Who can use them: [WHO CAN USE THEM]
Monthly budget: [MONTHLY BUDGET]

Please:
1. Walk me through setting a monthly spend limit in the [AI PROVIDER] dashboard, and tell me clearly whether it's a hard stop or only an alert. Some settings only send an email while requests keep going, and even hard limits can let a little extra spend through before they kick in. If you're not sure how this provider works today, say so and tell me where to check.
2. In my code: require login for AI features (if appropriate), cap input length, set a max output tokens value, and limit conversation history length.
3. Add a per-user daily usage limit stored in my database, with a friendly message when it's reached.
4. Make sure the API key is only used on the server (if not, use the "Move My API Calls to the Server" prompt (1.2 in this pack) first).
5. Add basic logging of usage per user (no message contents unless I need them) so I can spot abuse.
6. Give me a rough way to estimate cost per user from the provider's published prices, and remind me to check current prices myself.

My app is getting [FAKE SIGN UPS / FORM SPAM / OTHER ABUSE: DESCRIBE IT]. Help me cut it down without annoying real users.

Tech stack: [TECH STACK]
Auth provider: [AUTH PROVIDER]

Please:
1. Explain the likely cause in plain English.
2. Suggest options from least to most annoying for users: rate limits, honeypot fields, email confirmation, CAPTCHA or invisible challenges (like Cloudflare Turnstile or hCaptcha), and blocking disposable email domains.
3. Implement the two you'd recommend for my app, with server-side checks (not front end only).
4. Tell me how to clean up existing fake accounts safely.

Before I install these packages, help me check they're real and trustworthy.

Packages the AI suggested: [PACKAGE NAMES]
Package manager: [NPM / PNPM / YARN / PIP / OTHER]

For each package, tell me how to check (and check yourself if you can browse):
1. Does it exist on the official registry, under exactly this name? Watch for typos and look-alike names.
2. Is it the well-known package for this job, or would a more popular, maintained option do the same thing?
3. How to look at weekly downloads, the linked source repo, recent updates, and the number of maintainers.
4. Whether it runs install scripts, and why that matters.
5. Whether I need it at all, or my framework already does this.

If you can't verify something, say "I couldn't verify this" instead of guessing.

Help me check my project's dependencies for known security issues and update them safely. I'm a [SKILL LEVEL].

Package manager: [NPM / PNPM / YARN / PIP]
Repo host: [GITHUB / OTHER / NONE]

Please:
1. Give me the exact audit command for my package manager and explain how to read the output (severity, direct vs. indirect dependencies).
2. For each high or critical issue, tell me whether it actually affects my app (for example, a dev-only tool vs. code that runs in production).
3. Suggest the safest fix for each: a patch update first, and warn me before any major version upgrade that could break things.
4. Tell me to commit before updating, then run the app and test the main features afterward.
5. Make sure my lockfile is committed.
6. Explain how to turn on automatic alerts (such as Dependabot on GitHub).

Act as a senior security reviewer doing a pre-launch review of my app. I'm a [SKILL LEVEL], so explain findings in plain English. Don't change any code yet.

App: [APP IDEA]
Tech stack: [TECH STACK]
Host: [HOST]
Database: [DATABASE]
Auth: [AUTH PROVIDER]
Paid services: [SERVICES]
Sensitive data I store: [SENSITIVE DATA I STORE]

Review these areas and, for each, say what you checked and what you found:
1. Secrets: any in front-end code, in the repo, or in Git history?
2. Database access: RLS / security rules on every table or collection, tested for two users.
3. Auth: redirect URLs, email confirmation, admin roles checked on the server.
4. Every API route: login check, ownership check, input validation, rate limit.
5. Payments and webhooks: signature verification, amounts confirmed on the server.
6. Cost exposure: AI and other paid APIs capped in code and at the provider.
7. Common web issues: XSS, injection, open CORS, leaky error messages.
8. Dependencies: known vulnerabilities, unfamiliar packages.
9. Privacy basics: what personal data I collect, and whether I need a privacy policy.

End with a table: issue, severity (high/medium/low), file or setting, and the fix. Order it by severity. Then tell me what you could NOT check from the code alone, so I can check it myself.

Before we call this finished, prove it works.

What you just changed: [DESCRIBE OR "THE LAST CHANGE"]

Please:
1. List every file you changed, with a one-line summary of each change.
2. Tell me exactly what you ran or checked to confirm it works. If you didn't run anything, say so plainly.
3. If you can run commands, run the app, the build, and any tests now, and show me the actual output.
4. Give me a short manual test I can do myself, including one test that should FAIL (for example, a blocked user trying to access data) to show the protection works.
5. Tell me anything you're unsure about or couldn't verify.

Don't say "done" until steps 1-5 are complete.

Review how my app handles errors and logging.

Tech stack: [TECH STACK]
Host: [HOST]

Please:
1. Find places where errors are shown to users and make sure users see a friendly message, not stack traces, SQL, or internal details.
2. Find logs that might print secrets, tokens, passwords, or full user data, and remove or mask them.
3. Make sure useful details still go to the server logs so I can debug.
4. Tell me where to find my logs on [HOST].
5. Suggest a simple error tracking option, if I want one, and what data it would collect.

I think I leaked a secret and I need step-by-step help, in the right order. Keep it calm and simple.

Which key: [WHICH KEY] (don't include the value)
Where it was exposed: [WHERE IT WAS EXPOSED]
For roughly how long: [TIME]
Where the app is deployed: [HOST]

Please give me:
1. Step 1, right now: how to revoke or rotate this specific key at the provider and create a new one. Tell me where to find this in the provider's dashboard (if you're unsure of the current layout, say so and point me to the docs).
2. How to put the new key into my host's environment variables and redeploy, so the app keeps working.
3. How to check the provider's usage, logs, or billing for activity I didn't cause.
4. Only after rotating: how to remove the key from my code and, if needed, Git history (and why rotating matters more than cleaning history).
5. Whether I should contact the provider's support (for example, about unexpected charges).
6. How to stop this from happening again (secret scanning, pre-commit hooks, server-only keys).

I think user data in my app may have been exposed. Help me respond calmly and properly.

What I found: [WHAT I FOUND]
Data involved: [DATA INVOLVED]
Database / host: [DATABASE, HOST]
Roughly how many users: [NUMBER OR "NOT SURE"]

Please:
1. First, help me close the hole now (turn on RLS / fix rules / rotate keys), with exact steps.
2. Show me which logs my database and host provide, and how to look for unusual access during the exposure window. Be honest about what the logs can and can't tell me.
3. Help me make a simple written timeline of what happened.
4. Remind me: this isn't legal advice, check your local rules.
5. Help me draft a short, honest notice to users, in case I need one.
6. List what to change so it doesn't happen again.

I've handled a security incident: [SHORT DESCRIPTION]. Help me do a thorough cleanup.

Tech stack: [TECH STACK]
Services: [SERVICES]

Please give me a checklist that covers:
1. Every key that might be affected (not just the one I noticed), and whether each has been rotated.
2. Old keys deleted at each provider, not just replaced.
3. Copies of the secret in other places: forks, clones, CI settings, local .env files on other computers, chat logs, screenshots, docs.
4. Secret scanning and push protection turned on.
5. Billing alerts and spend caps set.
6. A short note in my project brief or rules file (for example "never put keys in front-end code") so my AI tool remembers it.