You commented LOCK. Here's the full prompt from the reel, cleaned up so you can paste it straight into Claude Code (or Cursor, Lovable, Bolt) inside your project.
Run it before launch. Then run it again after any big change.
The prompt
You are a senior application security engineer. My app goes live soon and I don't want it hacked. Work through every step below, in order, on THIS codebase. For each step: check what's there, fix it if it's missing or weak, and note what you changed. Don't skip a step because it "probably" doesn't apply; tell me why it doesn't.
1. Authentication: put a proper login on every private page and API route. Use the auth my stack already supports (e.g. Supabase Auth, Clerk, NextAuth). No home-made auth.
2. API keys: move every secret key off the front end. Anything in client code or NEXT_PUBLIC_/VITE_ variables must be safe to be public.
3. Database: turn on row level security (or the equivalent) for every table, with policies so users can only read and write their own rows.
4. HTTPS: force HTTPS everywhere and redirect plain HTTP.
5. Passwords: make sure passwords are hashed with bcrypt/argon2 (or handled by the auth provider). Never stored or logged in plain text.
6. Validation: check every form and API input on the server, not just in the browser.
7. XSS: escape or sanitise anything users type before it's rendered. No dangerouslySetInnerHTML / v-html on user content.
8. Admin: lock admin pages and admin API routes so only admin roles get in, checked on the server.
9. Queries: use parameterised queries / the ORM everywhere. No string-built SQL.
10. Rate limits: rate-limit login, signup, password reset and any expensive endpoint.
11. CORS: only allow my own domain(s) to call the API.
12. Headers: add security headers (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, frame protection).
13. Cookies: session cookies must be Secure, HttpOnly and SameSite.
14. CSRF: add CSRF protection to any state-changing request that uses cookies.
15. Password reset: reset links are single-use and expire within an hour.
16. Uploads: only accept the file types and sizes I actually need, checked on the server, stored outside the public web root.
17. Payments: calculate and verify prices on the server and confirm payments via the provider's webhook. Never trust a price sent from the browser.
18. Debug: switch off debug mode, verbose errors and stack traces in production.
19. Dependencies: update anything with a known vulnerability (run the audit for my package manager).
20. Cleanup: remove packages and code I'm not using.
21. Exposed files: make sure no .env, backup, source map or config file is publicly reachable.
22. Git history: scan my Git history for old keys and secrets. List anything that leaked so I can rotate it, and add it to .gitignore.
23. Finally: try to break in yourself. Attempt the attacks above against the running app, then give me a report: what you found, what you fixed, and anything I still need to do by hand.How to use it
Paste it into Claude Code from the root of your project so it can read the whole codebase.
Let it work step by step. If it asks before changing auth or the database, read what it proposes first.
Step 22 is the one people skip. A key that was ever committed is leaked, even if you deleted it later. Rotate it at the provider.
Keep the final report. It's your checklist for the next launch.
This doesn't replace a professional pen test for an app holding payments or sensitive data, but it catches the stuff that gets most vibe-coded apps popped in week one.
Mike
PS. If you run a local business and want customers coming to you instead of the other way round, that's what we do at OptiMAX.