Learn
The security baseline for indie devs and small operators: the whole standard set
The minimum security every indie developer and small operator should have — only the industry-standard controls, in one place. MFA, secret hygiene, dependency CVE monitoring, backups and more, ordered as 'keys to the kingdom → secrets and code → app → detect and recover', with this site's take on what to fix first.
For: indie developers and small operators who aren't sure "how much is the minimum" for security. No attack steps here — just the foundation considered industry-standard, in priority order. Each item links to a deeper article, so you can start here and read only what you need.
This site's view: not 'do everything' but 'fill in this order'
A solo or small team can't do everything at once — which is exactly why order is everything. If the top layer, the "keys to the kingdom," is taken over, every control below it becomes meaningless (the attacker resets everything as you). Fill from the foundation up and you cut your incident probability the most for the time you have. This article is written not as exhaustive knowledge but as a map that lets you instantly decide what to fill next.
Tier 0 — keys to the kingdom
MFA · domain · DNS · email · payment
Tier 1 — secrets and code
keep secrets out of git · pre-commit detection · key separation/rotation
Tier 2 — the app itself
input validation · auth/session · TLS/headers · email auth
Tier 3 — patch, detect, recover
dependency CVEs · OS updates · SSH/FW · logs · backups
Tier 0 — protect the keys to the kingdom (first)
This is the premise for everything else. If your domain, email, or hosting panel is taken over, every other control is nullified. The attacker resets passwords as you, rewrites DNS, walks into your server. So this is what you lock down first.
Put phishing-resistant MFA in place
Treat email as the 'parent key,' guard it hardest
Store recovery and backup codes safely
Separate accounts to reduce single points of failure
Tier 1 — don't leak secrets or code
This site's founding incident, and many in the wild, come from a gap here: secrets like .env files and API keys slipping into code or a public repo.
Keep secrets out of source and docs
.env and exclude them from git (.gitignore). Not writing them in at all is the strongest control.Stop secrets by machine before the commit
If it leaked, assume it ALL leaked — rotate everything
Scope tokens tightly and keep them short-lived
Self-hosting Git? Extra caution
Self-hosting because GitHub's "accidental public" scares you doesn't remove the accidental commit. With none of GitHub's built-in secret blocking, a pre-commit secret hook is mandatory on self-host. See self-hosted Git vs GitHub: which is safer.
Tier 2 — harden the app itself
The minimum for the web app you expose. The point isn't stopping novel attacks but closing the common, well-known holes. This site reframes each into defense on its glossary pages.
Never trust input (close the classic holes)
Get auth, session, and access right
Make TLS and security headers count
Prevent email spoofing
Tier 3 — patch, detect, recover
The foundation for "keep damage small and recover fast even after a breach." Dependency monitoring like osv-scanner lives here.
Machine-monitor dependency CVEs continuously
Auto-update the OS and server
Harden SSH and the firewall
Least privilege to shrink the blast radius
3-2-1 backups + a tested restore
Keep logs so you can notice anomalies
Where to start
"All of it, right now" isn't realistic. Compare the order people tend to take with the one this site recommends.
The order people tend to take (inefficient)
- start with flashy application-vulnerability work
- leave MFA on "later" indefinitely
- have backups but have never tried a restore
- secrets are in
.envbut there's no detection hook
The order this site recommends
- Tier 0: lock the keys to the kingdom first (MFA, email, domain)
- Tier 1: structurally stop secret leaks (pre-commit detection + rotate-all policy)
- Tier 2: close the app's classic holes
- Tier 3: get to "recoverable" with dependency monitoring, updates, restore-tested backups
This site defends in this order too
This site applies this same foundation to itself: a dedicated server with no co-tenancy (blast-radius separation) / a distinct key per host / secrets never in git or docs / dependency CVE monitoring before every deploy and daily / offsite backups to a separate server / external requests through a safety boundary. A site that teaches security can't have holes of its own — so we run this priority order on ourselves first. Our founding incident, too, came not from a novel attack but from a single gap in this foundation. That's why we keep saying: the foundation before the flashy work.
Read next
- Org / team version: the security baseline for mid-to-large organizations
- Self-hosting: self-hosted Git vs GitHub: which is safer
- Dependencies: installing and using osv-scanner · not falling behind on CVEs
- Secrets: .env files and secrets · incident a key leaked and billed for fraud
- Tools: security headers check · email auth checker · CVE/KEV lookup
FAQ
QWhat's the first security control an indie dev should set up?
Protect the 'keys to the kingdom': put phishing-resistant MFA (passkeys/hardware keys) on your domain registrar, DNS, hosting panel, email, and payment accounts. If those are taken over, every other control is nullified — so they come first.
QAre all baseline controls equally important?
No. There's a clear order. This site recommends filling it as: 1) keys to the kingdom, 2) secrets and code, 3) the app itself, 4) patch/detect/recover. With finite resources, top-down reduces incidents the most.
QDoes dependency CVE monitoring count as baseline?
Yes. Continuously machine-checking dependencies for known vulnerabilities with osv-scanner or pnpm audit is now industry standard. Most serious breaches come from neglected known holes (CVEs), not novel attacks.