Skip to content
ITDWeb Security Platform
ITD
Search

Security Guides

#security basics#MFA#secrets management#backups#AI-era readiness

The security baseline for indie devs and small operators: standard controls in priority order

The minimum security controls for indie devs and small operators, in priority order: MFA, secret hygiene, dependency CVE monitoring, backups and more.

Published 2026-06-11 Updated 2026-10-04 9 min read
On this page

For: indie developers and small operators who aren't sure "how much is the minimum" for security. No attack steps here — just the basic controls 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 matters most. If the top layer (admin accounts, domain and email) is taken over, every control below it becomes meaningless (the attacker resets everything as you). Work from the most important layer down and you cut your incident probability the most for the time you have. This article is written not as exhaustive knowledge but as a list for quickly deciding what to fill next.

Tier 0 — admin accounts, domain, email

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

This site's priority order. The higher the layer, the more a takeover nullifies every other control. Work top-down.
minutes
until an exposed secret is exploited
known vulnerabilities
cause of most serious breaches
one spot
lose admin accounts or email and every other control is bypassed
order
what makes limited time count

Tier 0: protect admin accounts, domain and email (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.

1

Put phishing-resistant MFA in place

Require MFA on your domain registrar, DNS, hosting panel, email, and payment. Strength: passkeys/hardware keys (FIDO2) > authenticator app (TOTP) > SMS. SMS is breakable via SIM swap — last resort only.
2

Guard email most strictly

Almost every service's password reset lands in email. If email is taken over, your other accounts can be taken over one by one. Email alone is worth a hardware key.
3

Store recovery and backup codes safely

Keep MFA recovery codes in a password manager or a physically safe place. Lose these and you lock yourself out.
4

Separate accounts to reduce single points of failure

Avoid reused passwords on critical accounts; make every one unique with a password manager so one breach doesn't spread to other services.

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.

1

Keep secrets out of source and docs

Separate API keys, passwords, and connection strings into .env and exclude them from git (.gitignore). Not writing them in at all is the strongest control.
2

Stop secrets by machine before the commit

A pre-commit hook (gitleaks, etc.) automatically blocks commits containing secrets — the same check GitHub's push protection provides, set up yourself (→ self-hosted Git vs GitHub).
3

If it leaked, assume it ALL leaked — rotate everything

At any suspicion, immediately revoke and reissue the affected keys/tokens. Don't leave it on "probably fine." This is what works most in real incident response (→ a key leaked and billed for fraud).
4

Scope tokens tightly and keep them short-lived

Don't mint one all-powerful token. Use least privilege, short expiry, and per-service tokens so one leak is contained.

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 vulnerabilities. This site reframes each into defense on its glossary pages.

1

Never trust input (prevent common vulnerabilities)

Stop user-input-driven SQL injection, XSS, SSRF, and path traversal with escaping, parameterization, and allowlists.
2

Get auth, session, and access right

Defend CSRF, enforce access checks against IDOR (viewing others' data), and set frame controls against clickjacking.
3

Make TLS and security headers count

Require HTTPS, set HSTS, CSP and friends. Grade your own site with the security headers check (build CSP with the CSP builder).
4

Prevent email spoofing

If you send mail from your own domain, set SPF/DKIM/DMARC. Find gaps with the email auth checker.

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.

1

Machine-monitor dependency CVEs continuously

Neglected published CVEs are the top cause of incidents. Run osv-scanner or pnpm audit in CI/cron (→ not falling behind on CVEs).
2

Auto-update the OS and server

Automate OS security updates (unattended-upgrades, etc.). Don't neglect patches for your Git server and middleware either.
3

Harden SSH and the firewall

SSH keys only (password auth off, no direct root login), firewall open only the ports you need, fail2ban to slow brute force.
4

Use least privilege to limit how far a breach spreads

Run services non-root, never expose DB/internal services, a distinct SSH key per host — so one breach can't cascade.
5

3-2-1 backups + a tested restore

Three copies, two media, one offsite. Encrypted. And not just "it's running" — actually try a restore once.
6

Keep logs so you can notice anomalies

Retain access, auth, and error logs so odd signs are visible. The later you detect, the wider the damage.

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 .env but there's no detection hook

The order this site recommends

  • Tier 0: secure admin accounts, email and domain with MFA first
  • Tier 1: structurally stop secret leaks (pre-commit detection + rotate-all policy)
  • Tier 2: close the app's common vulnerabilities
  • 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: the app and database in separate containers, the database only on an internal network (limiting the scope of impact at the container/network layer) / 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 leave vulnerabilities in its own setup, 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 these basic controls. That's why we keep saying: the basics before the flashy work.

FAQ

QWhat's the first security control an indie dev should set up?
A

Protect the accounts whose takeover nullifies everything else: 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?
A

No. There's a clear order. This site recommends filling it as: 1) admin accounts, domain and email, 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?
A

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 vulnerabilities (CVEs), not novel attacks.