Most security advice is written for teams with a security budget. If you are one person shipping a side project this weekend, you do not need a 200-item audit. You need to catch the handful of mistakes that actually get small apps breached.
Here is the short list, in the order things usually go wrong.
What should a solo developer check before launching an app?
Check five things before launch: no hardcoded secrets in source, git history, or the built bundle; database rules locked to the authenticated owner; security headers and HTTPS enforced with source maps stripped; auth tokens actually verified rather than decoded; and dependencies pinned and audited. Everything else is refinement.
Secrets in the code
The single most common way indie apps leak is a hardcoded API key, database URL, or token that ends up in a public repo or a shipped bundle. Grep your project for anything that looks like a key before every release. Move it to an environment variable, and confirm the built output does not contain it.
This is not a rare failure mode. GitGuardian counted 28.65 million new hardcoded secrets pushed into public GitHub commits during 2025, a 34% jump year over year, and found that AI-assisted commits leaked secrets at roughly twice the baseline rate. If you are shipping code an assistant helped write, the odds are worse, not better. Two related posts go deeper: how indie apps leak their API keys and why deleting a secret does not remove it from git history.
Turn on GitHub push protection while you are at it. Secret scanning and push protection are free on public repositories and enabled by default, so a blocked push costs you a minute and an unblocked one can cost you a rotated production key.
Wide-open database rules
Firebase, Supabase, and similar backends ship with permissive defaults that are fine for a demo and dangerous in production. If your rules still say anyone can read and write, you are one curious visitor away from a data dump. Lock reads and writes to the authenticated owner before launch. The Firebase rules post walks through the specific default that catches people, and insecure infrastructure-as-code defaults covers the same class of problem one layer down.
Missing security headers
No Content-Security-Policy, no HTTPS redirect, source maps served in production. None of these will stop your app from working, which is exactly why they get skipped. They are also the first things an attacker checks.
This category is no longer a footnote. In the OWASP Top 10:2025, finalised in January 2026, Security Misconfiguration climbed to number two. The reasoning is squarely aimed at how small teams ship: continuous deployment without continuous checking widens the exposure window every time you push. Software Supply Chain Failures entered the list at number three, which for a one-person project mostly means your dependencies. Pin them, audit them, and know what you pulled in. Our OWASP Top 10 breakdown for solo developers translates the full list into things you can actually action alone.
You do not have to be a security expert. You have to not ship the five obvious mistakes.
Auth you wired up in a hurry
JWTs decoded instead of verified, sessions without expiry, password resets that leak whether an account exists. Auth is the part everyone copy-pastes at midnight, and it is the part that matters most. The decode-versus-verify confusion is the one that bites hardest, because the code looks like it works: you get the user ID back either way, and only one of those paths checks the signature. The JWT mistakes post covers that one in detail.
The bill as an attack surface
Worth adding to the list if you are on serverless or usage-billed infrastructure. You do not have to be breached to be hurt. An exposed endpoint that anyone can call in a loop turns into a four-figure invoice without a single record being stolen, which is why denial of wallet deserves a spending cap and a rate limit before launch rather than after the email from your provider.
Run the check before you ship, not after
The reason these slip through is not ignorance. It is that the check happens after launch, if at all. Make "am I safe to ship?" a step in your release, the same way you run the build. A one-minute scan of your source catches the boring, dangerous stuff while it is still cheap to fix. If you want the longer version of that question, the pre-ship audit walkthrough covers what a real check looks like, and the vibe coding post covers what changes when most of your code came out of a model.