Everything before this section was about producing a working project. This section is about the ways a working project turns into a problem: someone gets a key that lets them spend your money, someone reads data that belongs to your users, you collect information you had no right to keep, or an automated action destroys something you cannot get back. None of these require an attacker with skill. Most are ordinary publishing accidents, made faster by a tool that can write forty files while you read one.
The material here is narrow. It is a set of failures that actually happen to solo builders shipping small real apps, written so you can act on them in an afternoon, and it will not make your project resistant to a determined attacker.
Three things worth doing before you read on
Each takes a few minutes and none of them depends on the rest of the section.
- Find out whether a server-only key is in your frontend. From your project folder, run
git grep -n "sb_secret_\|sk_live_\|sk_test_\|SERVICE_ROLE". Supabase's secret key and Stripe's secret key both act with full authority, and either one belongs only in code that runs on your server. A match inside a page or a component is the thing to fix before anything else here. A clean result is good but not proof, because it only searches the files you have now, which is what How secrets leak picks up. - Find out which of your providers can cap your spending, before you need the cap. Model APIs, email sending and hosting bandwidth all charge per unit, and a public route with no limit in front of it is how a small project gets a four-figure invoice. The controls are uneven and named differently: Anthropic's Console has spend limits per workspace, Vercel calls it Spend Management under team settings, and Resend has no self-service limit at all. Set the ones that exist and write down which providers have none.
- Check that you have a backup and know how long your logs are kept. The section's last page assumes both, and Backups is where the first one comes from.
The five sections
- How secrets leak: the four routes a key takes into public view, why deleting it from a file does not remove it, and why you rotate before you investigate.
- Five mistakes that expose user data: the handful of access-control errors behind most small-app data exposures.
- What you are allowed to store about people: practical orientation on collecting less, saying what you collect, and honouring deletion. Not legal advice.
- What to never let an AI do unsupervised: the specific actions that need a human at the keyboard, and the reversibility test that decides the rest.
- When it has already gone wrong: the calm order of operations after a leak, a bad deploy, or a deletion you cannot undo. Written for the worst moment. If you have not launched yet, read it once, then do the one thing in its closing section that you can do on a calm afternoon: check that a backup exists and read your log retention setting.