Shipping fast is fine, but there is a short list worth reviewing before you open your app to the world. None of it requires being a security expert — and all of it is checkable from the outside in a couple of minutes. Here is what actually matters, why each one bites, and how to fix it.
How attackers find these in minutes
Most breaches of AI-built apps are not clever hacks. Someone opens your site, presses F12, reads the JavaScript your app already shipped to their browser, and copies a URL your app already calls. Automated scanners do the same at scale, hitting common paths like /.env or /.git on thousands of sites a day. Everything below is something they can check without any access to your code — which is exactly why you should check it first.
1. No secrets in the frontend
API keys and tokens belong on the server only. When an AI assistant "connects" a service, it often drops the key straight into client code, where anyone can read it in DevTools. A leaked Stripe sk_live_ key can move real money; a Supabase service_role key hands over your whole database. Keep secret keys in server environment variables and expose only the public keys designed for the browser. See the secrets your app leaks in the browser.
2. HTTPS and security headers
Serve everything over HTTPS and redirect HTTP to it, so no one can read or tamper with traffic. Then add the headers that browsers use to defend your users: Content-Security-Policy to contain injection, Strict-Transport-Security to lock in HTTPS, and X-Frame-Options to block clickjacking. Most generated apps ship with none of these by default. See HTTP security headers explained.
3. Database rules (RLS) on every table
If you use Supabase or Firebase, your app talks to the database straight from the browser, so the database rules are the only thing standing between a visitor and your data. Enable Row-Level Security on every table (not just the important ones) with a deny-by-default policy, and never rely on hiding a button in the UI. Without it, anyone with the public key reads and writes your tables without logging in — the exact flaw behind the Lovable RLS vulnerability.
4. No exposed sensitive files
Make sure .env, .git, database backups and source maps are not reachable from a browser. It is surprisingly common: a single request to /.env can hand over every secret your app uses, and published source maps let anyone rebuild your original code. Block these at your host or framework config.
5. CORS locked down
A permissive CORS policy that reflects any origin with credentials lets a malicious site read your users' data using their session. Restrict allowed origins to the domains you actually control, and never combine Access-Control-Allow-Origin: * with credentials.
6. Cookies and sessions configured right
Session cookies should carry Secure (HTTPS only), HttpOnly (unreadable from JavaScript, so an XSS can't steal them) and SameSite (defends against CSRF). These three attributes are one line of config and close a whole class of account-takeover bugs.
Your 2-minute pre-launch checklist
- No
sk_live_,service_roleor private keys in your JavaScript. - HTTPS enforced, with CSP, HSTS and X-Frame-Options set.
- Row-Level Security on every database table.
.env,.git, backups and source maps not reachable.- CORS limited to your own origins, no wildcard with credentials.
- Cookies with Secure, HttpOnly and SameSite.
Just get it done
Instead of checking all this by hand, run Scanaris: it verifies these points and around 40 more on your live site in 30 seconds, ranks the findings by impact, and gives you a ready-to-paste prompt to fix each one with your AI — before someone else finds them.