Everything before this chapter was about producing a working project. This chapter is about the four 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 of them are ordinary publishing accidents, made faster by a tool that can write forty files while you read one.
The material here is deliberately narrow. It is not a security course, and it will not make your project resistant to a determined attacker. It covers the small number of failures that actually happen to solo builders shipping small real apps, and it is written so you can act on them in an afternoon. The last section is written for the worst moment, when something has already gone wrong and you need an order of operations rather than a lecture.
- 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.