Fix guides for AI-built apps
The security holes that sink vibe-coded launches — and exactly how to close each one. Plain-English steps, prioritized by real risk.
- critical→
How to add Row Level Security to a Lovable app
Lovable provisions a Supabase database but often leaves tables readable by the public anon key. Until you enable and write row-level security policies, anyone can read your users' data.
- critical→
How to enable Row Level Security on Supabase
A Supabase table without RLS is fully readable by anyone holding your anon key — which ships in your frontend. Enabling RLS correctly is the single most important step to securing a Supabase app.
- critical→
How to fix an exposed Supabase key
There are two cases. The anon key is meant to be public — if that's all that's exposed, RLS is your fix. But if your service-role key reached the client or a public repo, your entire database is exposed and you must rotate it immediately.
- critical→
How to rotate an exposed API key
An API key that shipped to the frontend or a public repo should be treated as compromised. One founder shipped a Stripe secret key to the frontend and 175 customers were charged before he could rotate it. Rotate fast, but in the right order.
- medium→
How to add security headers to your app
AI-generated apps almost always ship without security headers, leaving you open to clickjacking, protocol downgrade and content-injection attacks. Adding them is quick and high-leverage.
- medium→
How to fix a CORS error (the secure way)
The quickest 'fix' for a CORS error — allowing all origins with a wildcard — is also a security hole: it lets any website call your API from a victim's browser. The right fix allows only the origins you trust.
- critical→
How to secure your environment variables and secrets
AI-built apps routinely leak secrets by putting them in client-side env vars, committing .env files, or exposing them in the bundle. Anything in the browser is public — secrets must live server-side only.
- high→
Supabase RLS best practices
Enabling RLS is only half the job. Permissive or incorrect policies leave data exposed even with RLS 'on'. These are the practices that make Supabase row-level security actually protect your data.
- critical→
How to secure your Firebase security rules
The #1 cause of Firebase data leaks is rules left in test mode ('allow read, write: if true'), which makes your entire database public. Secure rules restrict every read and write to authenticated, authorized users.
Want it verified, not just fixed?
Fixing it is step one. A ClearedToShip review confirms the fix actually holds and gives you a signed, insured clearance to launch. Join early access: