5 Things to Check Before You Share Your Lovable or Bolt App With Anyone

You just finished building something with Lovable, Bolt, Replit, or v0 and it works. Before you drop the link anywhere public — Product Hunt, X, a subreddit, your own group chat — run through these five checks. Each one takes seconds, and every issue has a copy-paste fix you can paste straight back into the tool you built it with.

1. View your page source and search for "sk_" or "service_role"

Right-click your live app → View Page Source (or Ctrl/Cmd+U), then search the page for sk_live_, service_role, or AKIA. If any of these show up, a live secret key shipped straight to the browser — and anyone who does exactly what you just did can copy it and use it as you.

If you find one: move that key to a server-side environment variable, rotate it (generate a new one and revoke the old), and ask your AI builder to make sure secret keys never end up in client-side code.

2. Try loading your /.env and /.git/config paths

Type yourapp.com/.env and yourapp.com/.git/config into your browser. Either should return a 404 or an empty response. If either one loads and shows content, your entire config — often including every secret key your app uses — is sitting in public.

If you find one: this usually needs a hosting-level rule blocking those paths, or in some cases a redeploy from a clean build that doesn't include them.

3. Open a second browser (or incognito) and log in as a different test account

If your app has accounts, create two test users. Log in as user A, note an ID from a URL (an order number, a profile ID). Log in as user B and try swapping that ID into the URL. If you can see user A's data while logged in as user B, that's an access-control gap — sometimes called IDOR — or a sign your database's row-level security isn't scoping data to the logged-in user.

If you find one: this is usually a Row-Level Security or backend authorization fix — ask your AI builder specifically to "restrict access to each user's own records at the database level," not just hide the button in the UI.

4. Check your security headers

Paste your URL into a header checker (or ShipShield does this automatically) and look for Content-Security-Policy, X-Frame-Options, and HSTS. Missing headers don't break anything visibly — that's exactly why they're so often skipped.

If they're missing: most hosting platforms (Vercel, Netlify, etc.) support adding these with a short config file — a one-time fix.

5. Confirm your API only talks to your own domain

If your app has a separate backend/API, check its CORS settings. If it's configured to accept requests from any origin (*), any website on the internet can call your backend directly from a visitor's browser.

If it's wide open: lock the allowed origin down to your actual production domain.

Why bother with all five

None of this requires you to become a security expert — it requires five minutes before you hit "share." The uncomfortable truth is that roughly a third of publicly scanned AI-built apps have at least one issue this serious, and the apps that get found first are usually the ones that got attention first — right after a launch post goes up.

Skip the manual version: paste your URL into ShipShield's free scanner and get all five checks (plus more) run automatically, with a grade and copy-paste fixes for anything that needs one.