ShipCheck

Weekly security, SEO and uptime checks for vibe-coded apps. Free scan at

[ShipCheck @runshipcheck]

Rotating a leaked Stripe key? Stripe can keep the old key working for up to 7 days. In a breach, pick "Now" (an hour at most).

Webhook secrets are the same: Roll secret allows up to 24h. A leaked whsec_ lets someone fake "checkout completed".

https://t.co/dtY4iHLpdt

[ShipCheck @runshipcheck]

Two outages no prompt or deploy will cause:

1. Your SSL certificate expires
2. Your domain expires

Most hosts renew the certificate for you. The domain is on you: check its expiry date, turn on auto-renew, and make sure the card at your registrar still works.

[ShipCheck @runshipcheck]

Host breached? Rotate every secret stored there, in this order:

1. Money (Stripe sk_live_)
2. Full data access (DB passwords, service_role)
3. Paid AI keys (OpenAI, Anthropic, OpenRouter)
4. AWS, GitHub, email keys

Then redeploy and check each old key fails.

[ShipCheck @runshipcheck]

API key in your frontend?

Public by design: Supabase anon key (with RLS on), Stripe pk_live_
Never public: OpenAI, Anthropic, OpenRouter, Stripe sk_live_, service_role

VITE_ and NEXT_PUBLIC_ vars ship in your JS.

Leaked one? Revoke it first: https://t.co/8epCAV653x

[ShipCheck @runshipcheck]

@erramix01 Thanks! Staging noindex is a sneaky one, it can sit there for weeks before anyone notices the site isn't showing up in Google.

[ShipCheck @runshipcheck]

@ayushdoesdev Thanks Ayush, great additions. Pairing uptime with Sentry or GlitchTip for real stack traces is smart advice. And agreed on keys: ShipCheck's scan already looks through your public JS for exposed secrets, so that one's covered.

[ShipCheck @runshipcheck]

Live for weeks and still not on Google? Check these before blaming the algorithm:

/robots.txt doesn't say Disallow: /
/sitemap.xml returns real XML, not your homepage
no X-Robots-Tag: noindex header
canonical points at your real domain

Guide: https://t.co/wC1hCjDtYV

[ShipCheck @runshipcheck]

5 response headers most vibe-coded apps ship without:

Strict-Transport-Security
Content-Security-Policy
X-Frame-Options (or CSP frame-ancestors)
X-Content-Type-Options: nosniff
Referrer-Policy

See yours: curl -sI YOUR_URL

Most hosts let you set them in one config file.

[ShipCheck @runshipcheck]

Supabase RLS isn't one switch. It's a policy per action.

Test with your anon key, logged out:
SELECT: only rows meant to be public come back
INSERT / UPDATE / DELETE: should fail

Common miss: SELECT locked down, but an UPDATE policy left as USING (true).

[ShipCheck @runshipcheck]

@johndavidback Agree. For non-technical builders a short checklist beats "think about security": no secret keys in the live site's JS, RLS on every database table, and a logged-out test of every page and API route. Those three cover a lot of the leaks that actually happen.

[ShipCheck @runshipcheck]

@Gaufire Good list. On map files: check the live site too, not just npm packages. If your production JS has a matching .map file that loads, your original source (comments included) is public. Most bundlers let you turn production source maps off or upload them privately.

[ShipCheck @runshipcheck]

@ShinNagasada The part that bites later is usually drift: a later prompt puts a key in the frontend, or a new table ships without RLS. Cheap habit: after each deploy, open the live app logged out and check what it exposes. Uptime alerts and tested backups cover most of the rest.

[ShipCheck @runshipcheck]

@denk_tweets For a solo builder, "head of security" can be small and boring: a list of every key and where it lives, spend caps on paid APIs, RLS on every table, and a regular logged-out look at the live site. Those basics cover more real risk than chasing every CVE.

[ShipCheck @runshipcheck]

@dhalishiva Forgetting RLS on a new table is the classic one. Two guards: a Postgres event trigger that enables RLS on every new table in public, and a logged-out test with the anon key after each migration. Supabase's Security Advisor also flags "RLS disabled in public".

[ShipCheck @runshipcheck]

@isbkch Solid prompt. One step I'd add to Phase 3: verify the deployed URL, not the local build. curl your domain and look for the <title> and body text, then Search Console > URL Inspection > View crawled page. Prerender setups can work locally and get skipped by the host's build.

[ShipCheck @runshipcheck]

@X_Naufil A few exist. Free first steps: Supabase's Security Advisor (flags tables without RLS), gitleaks on your repo, and DevTools search of your live JS for sk_ and service_role. I'm building one for the live-site side (keys, exposed files, headers, SEO): https://t.co/C1NMbuxrpU

[ShipCheck @runshipcheck]

@jayypatel18 For most vibe-coded apps, honestly: when the bill arrives. Cheap early warnings: spend limits and budget alerts on OpenAI/Anthropic and AWS, GitHub secret scanning on the repo, and after rotating, call the API once with the old key to confirm it really fails.

[ShipCheck @runshipcheck]

Many hosts answer every URL with 200 + your index.html, so "does /.env return 404?" can lie.

Open these on your live site and read the body, not the status code:
/.env
/.env.production
/.git/HEAD
your JS source maps (.map)

Free scan that checks them: https://t.co/C1NMbuwTAm