← home

Learn

Straight answers about secrets, keys, and safely shipping AI-built apps.

• Is Shipshape legit? What it does and doesn’t do
  Shipshape is a passive pre-launch checkup for AI-built apps. Here is exactly what it checks, what it never does, and why it won’t false-flag your public keys.
• Supabase anon key vs service_role key: which is safe to expose?
  The Supabase anon key is meant to be public. The service_role key must never reach the browser. Here is the difference and how to check your app.
• Is the Firebase apiKey a secret? (No — and here’s why)
  The Firebase apiKey is safe to expose in client code. It’s an identifier, not a credential. Here’s what actually protects a Firebase app.
• Can I just ask ChatGPT to check my app’s security?
  ChatGPT can explain concepts but can’t see your deployed app. A scanner actually fetches your live URL and checks deterministically. Here’s the difference.
• The vibe-coder’s pre-launch checklist (Lovable, Bolt, Replit, v0)
  A short, practical checklist before you put your AI-built app in front of real users: secrets, database rules, source exposure, headers, and payments.
• How do I know if my Supabase database is exposed?
  If Row Level Security is off, the public anon key in your frontend can read every table. Here is how to check — safely — whether your Supabase data is downloadable.
• I leaked my Supabase service_role key — what now?
  A exposed service_role key bypasses all your database security. Here is the exact, ordered recovery: rotate, remove, lock down, and check for abuse.
• Is my Lovable app safe to launch? 5 things to check first
  Lovable apps are usually Supabase-backed React SPAs. Before you share yours, check these five things — three you can verify for free from the URL.
• How to check a Bolt, Replit, v0 or Cursor app before launch
  Whatever AI builder you used, the pre-launch risks are the same: leaked secrets, open database rules, downloadable source. Here is how to check any of them.
• Firebase security rules for a vibe-coded app
  Firebase quickstarts ship in test mode — open to the world. Here is how to tell if your rules are still open, and how to lock Firestore, Storage and Realtime DB.
• How to stop a runaway OpenAI / API bill in your app
  Calling a paid AI API directly from the browser exposes your key and your budget. Here is the safe pattern: a server proxy, rate limits, and spend caps.
• My .env file is downloadable — what to do
  If /.env loads in a browser, attackers can grab every secret in it. Here is how it happens, how to confirm it, and how to fix and recover.
• pk_test in production: why your checkout silently fails
  A Stripe test key on your live site is not a security leak — it is a launch bug. Real cards will not be charged. Here is how to spot and fix it.
• How to choose a security scanner for a vibe-coded app
  New scanners for AI-built apps appear constantly. Here are the honest criteria that actually matter — accuracy, real exploit-testing, and clear limits — not feature counts.
• How do scanners safely test your database rules?
  Testing whether a database is publicly readable sounds invasive. Done right, it reads a row count and nothing else — and only after you prove you own the app.
• Shipshape vs Vibe App Scanner: scanner results vs launch proof
  AI-app scanners increasingly check similar surfaces. The important difference is whether the tool can turn evidence into launch-state proof.
• Stripe webhook returned 200, but paid access still failed
  A webhook can succeed at the HTTP layer while your app never grants the user paid access. Shipshape checks the resulting state, not just delivery.
• Supabase RLS Launch Proof checklist
  RLS being enabled is not enough. Before launch, prove the public key cannot read protected rows and that policies match the app model.
• Gemini/API key wallet-drain checklist for AI apps
  AI app launches now need a wallet-drain check: exposed paid keys, unrestricted Google keys, client-controlled models, and missing rate limits.
• What Shipshape proof packs prove — and what they do not
  A proof pack is a dated attestation of checks run under a policy. It is useful for launch decisions, but it is not a security guarantee.
• A leaked API key or token in your frontend: what to do
  If a secret key or token from any provider ships to the browser, anyone can read it and use it on your account. Here is how to tell a real leak from a public-by-design key, and how to fix it.
• Missing security headers on your app: what they do and how to add them
  Security headers like CSP, HSTS, and X-Frame-Options are cheap defenses your AI builder probably skipped. Here is what each one prevents and how to add them.
• CORS misconfiguration: when "Access-Control-Allow-Origin: *" is dangerous
  A wide-open CORS policy can let any website read authenticated responses from your API. Here is when a wildcard is fine and when it leaks data.
• Exposed source maps: your original source code is downloadable
  If .map files ship to production, anyone can reconstruct your original, unminified source — comments, structure, and sometimes secrets. Here is how to turn them off.
• Unvalidated postMessage: a cross-window message handler without an origin check
  A window.addEventListener("message") handler that does not check event.origin can let any site send your app commands. Here is the one-line fix.
• Subdomain takeover: a dangling DNS record an attacker can claim
  If a subdomain still points (CNAME) at a deprovisioned host, someone else can register that host and serve content from your domain. Here is how to find and fix it.
• Debug artifacts, risky TODOs, and leaked AI prompts in your build
  Shipped debug pages, source comments, and system prompts can hand attackers a map of your app. Here is what to strip before launch.
• TLS and email checks: weak HTTPS and a spoofable domain
  A near-expiry or weak TLS certificate, and a domain without SPF/DMARC, are launch-blocking trust issues. Here is what to set.
• Sensitive data shipped to the browser: config, internal fields, and bulk PII
  Server config, internal-only fields, and large dumps of personal data sometimes get baked into the frontend. Here is why that is an access-control problem and how to fix it.
• An outdated frontend library with a known vulnerability
  Shipshape can see some client-side library versions and match them to known CVEs. Here is what that means and how to update safely.