Incident response check
Start hereFor the day something has already gone wrong.
$790
- Same-day start
- What is reachable right now
- Containment steps in order
- Key rotation and revocation list
- Findings report and fixes
Written for founders who built with an app builder.
Ordered by what a stranger reaches first. Each links to a self-check you can do today and to what our test adds.
Anyone who opens the app can copy the key from the downloaded JavaScript and read, change or delete every row in every table.
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
Anyone with the project URL and the public anon key, both of which sit in the app's JavaScript, can read, edit or delete every row in the table.
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
A script can hit the route in a loop overnight and the bill lands on your card, or the provider pauses your account mid-day when its own cap trips and every user sees errors.
When data is deleted or corrupted, whether by a bug, an agent or a person, there is either nothing to restore or a backup nobody has proven they can actually bring back.
Anything the agent decides to run, or is tricked into running by text it reads, executes with the same power you have, including dropping tables or moving money.
Someone who once had a user's token, on a shared computer or through a leak, keeps access after the user logs out or changes their password.
In July 2025 a coding agent deleted data from a production database during a declared code freeze; the vendor confirmed it and rolled out separate development and production databases (Jason Lemkin (SaaStr), 2025). The two checks that decide how bad such a day is: whether a backup exists and has been restored at least once, and whether any agent or script holds production credentials. Both are in the list below.
In July 2025 a Replit agent deleted data from a production database during a user-declared code freeze; Replit's CEO confirmed it, said backups allowed a restore, and announced automatic dev and production database separation.
Jul 2025 · Jason Lemkin (SaaStr) · all sources
Moltbook, a social network for AI agents built with AI-generated code, ran a Supabase database without row-level security policies, leaving 1.5 million API tokens and 35,000 email addresses readable and writable without login.
Feb 2026 · Wiz Research · all sources
For the day something has already gone wrong.
$790
For anyone who wants the three riskiest areas checked fast.
$290
Compare all packages, or run the self-check first.
Thank them and ask for the exact steps. Rotate any key they mention. Check whether the same issue exists on similar tables or routes. Fix, re-test, and tell them it is fixed. If you want the assessment and containment order done for you within 24 hours, that is the incident response check.
Rotate it in the provider's dashboard now, redeploy so nothing still uses the old one, then read the usage and logs for the period it was exposed. If it was a database secret key, treat every row the app can reach as potentially read and check the tables for changes.
Check your provider's backups first: Supabase has daily backups on paid plans and point-in-time recovery as an add-on, Replit documents checkpoint rollback and restore. Restore to a copy, not over production, then compare. After recovery, test a restore on a schedule so the next time is routine.
Other moments: before you launch, before you take payments, before an investor or security review, before a client handover, you received a security email.