Free resource
Vibe Coding Security Checklist
30 AI audit prompts that check your vibe-coded app and website for security, quality, and launch gaps before real users do.
How to use this
Paste one audit prompt at a time. Use a mode that answers without editing files. Read the report, choose which finding IDs to fix, then paste the fix prompt in a mode that can edit. Re-run the same audit prompt afterwards and read that report too.
Read this first — honest limits
- An AI review is a to-do list to verify, not a certificate. It can miss things and it can be wrong.
- Run these inside your coding tool on your own repo. Never paste production secrets or real customer data into a chat window.
- If a prompt finds a live key or credential, rotate it immediately — deleting it isn't enough.
- For apps that handle payments, health data, or sensitive information at scale, add a human security review. Legal pages produced by prompt 28 are drafts for a lawyer to check.
Prompt 28 also covers six pre-launch legal traps (age on signup, fonts loaded from Google, session replay, marketing email, subscription terms, and a DMCA agent) and India's DPDP Act. It is a checklist for a lawyer, not legal advice. Open prompt 28.
How to run these prompts
- Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
- Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
- Read the report. Keep the IDs you agree with.
- Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
- Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.
- Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.
- Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.
- Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.
Which prompts should I run first?
01
Secrets & Credential Leak Sweep
A private key left in a repo or a shipped app can be copied and abused. Public client keys are a different thing and should not be treated as leaks.
02
Test Data & Seed Cleanup
A demo admin, a weak password, or an OTP bypass left in the login path can ship as a back door. Placeholder copy can ship as if it were real.
03
Database Rules & Row-Level Access
If the database is called from the browser, the rules are the security of the app. A default or test-mode rule can leave every row readable.
04
Auth, Roles & Admin Route Lockdown
Hiding an admin link is not security. If the route or API answers anyone who requests the URL, it is open.
05
Input Validation & Injection Defense
Form fields, URL parameters, headers, and file names are attacker-controlled. Most injection bugs start with one that was never checked on the server.
06
File Upload Safety Test
An upload can store malware, fill storage, or overwrite a file if the server trusts the browser's file name and type.
07
Rate Limits & Abuse Protection
Without limits, one client can guess passwords, spam users, or run up an API bill before anyone notices.
08
Personal Data Flow & Storage Audit
A console.log of a user object can land in a host's logs, where anyone with dashboard access can read it.
09
Payments & Webhooks Deep Check
Payment bugs spend real money: access without paying, a double charge, or a paid order that never unlocks.
10
Debug Logs & Error Leakage Cleanup
A stack trace or a logged token shown to the wrong person reveals paths, queries, and sometimes keys.
11
Pre-Deploy Production Readiness Check
Many launch incidents are missing safeguards a short checklist would have caught before the first real user.
12
Try to Break Your App: Attacker's-Eye Review
Many bugs are not obvious when you read code top to bottom. They show up when you follow an attack path or a clumsy user path.
13
Performance & Load Simulation
An app that feels instant in one browser tab can stall when many people use it at once.
14
Slow Network, Offline & API Failure Handling
Apps are often tried on fast Wi-Fi. Users are on crowded mobile networks, and third-party APIs fail more often than a demo suggests.
15
Mobile Layout & Responsive Testing
A layout that looks finished on a laptop can be unusable on a phone, which is where many first visits happen.
16
Accessibility Pass
Accessibility failures exclude people. Some laws and app stores also treat them as compliance issues.
17
Code Quality & Maintainability
The cost of messy generated code shows up when someone has to change it safely later.
18
Database & Query Health
A query can look fine on a small test database and time out after real data arrives.
19
Dependency & Supply Chain Risk
You can review every line you wrote and still ship a bug that lives in a package you did not write.
20
Mobile App Security (Android/iOS)
Anything in an APK or IPA can be unpacked. A secret in the client is not a secret.
21
API Design & Contract Quality
An inconsistent API often fails later, when a second client expects a different response shape.
22
Test Coverage & Quality
A test suite that does not check the real outcome can create false confidence.
23
Cost & Resource Efficiency
The bill that ends a side project is often one loop calling a paid API, not the base hosting fee.
24
Error Handling & Observability
The failures that hurt are often quiet: the user leaves, and nobody is alerted.
25
SEO & Shareability Foundations
If a crawler or a chat app cannot read a page, the site is hard to find and shared links look empty.
26
Conversion & CTA Audit
A site can look finished and still give a visitor no clear next step.
27
UX States: 404, Loading, Errors & Thank-You
The happy path is the easy part. Loading, empty, and error states are what make a product feel finished.
28
Legal & Trust Pages
A missing age check, a font loaded from a third party, or a marketing email with no unsubscribe can create legal exposure before the first sale. This is a checklist for a lawyer, not legal advice.
29
Analytics & Measurement Setup
If you cannot see what visitors do, you find out a launch failed only after the chance to fix it has passed.
30
Images & Page Weight
Oversized images are a common reason a good-looking site feels slow on a phone, and speed is part of the page experience and of search quality signals.