Security · Interactive
Eight deployment security gaps, properly cited
Most security checklists are written from memory. This one links each item to the standard it actually comes from — OWASP's Top 10:2025, NIST's special publications, or the CIS Critical Security Controls — so you can go read the primary source instead of taking a blog post's word for it. Check items off as you address them; your progress is saved in this browser.
Two items here have deeper, implementation-level companions on this site: secrets handling and rate limiting. This page is the honest overview; those guides are the how-to.
The checklist
Work through it once, then revisit it after every architecture change
Each item names the failure mode, not just the fix — knowing how something breaks is what makes the fix stick.
A secret that touches git history is compromised for good — deleting the file later doesn't remove it from history, and public repositories are scanned by automated bots within minutes of a push.
How it fails: a .env file gets committed by accident, an API key sits in a config file "temporarily," or a secret hardcoded during debugging never gets removed before merge. Treat anything that touched source control as burned — rotate it immediately rather than just deleting it.
Development, staging and production should never share credentials or a direct path to the same data — a bug in a staging script shouldn't be able to touch anything real.
How it fails: the same database password gets reused "just for now" across dev and prod, or a staging environment holds a copy of real customer data behind weaker access controls than production has.
Every credential, key and service account should be scoped to only the actions it actually needs — not broad admin access because it was faster to set up.
How it fails: a deploy script is granted full account-owner permissions, so a single leaked deploy key can now touch every resource in the account instead of just the one it was meant to deploy.
Every connection should be encrypted in transit, not just the login page — and HSTS tells browsers to never even attempt an unencrypted connection again.
How it fails: an internal API or admin panel is left reachable over plain HTTP "because it's internal," and HSTS is skipped so a single mixed-content redirect can be intercepted on an untrusted network.
Most real-world breaches trace back to a known, already-patched vulnerability in a dependency — not a novel exploit nobody saw coming.
How it fails: a project pins dependency versions at launch and never revisits them, so a critical vulnerability patched upstream months ago sits unpatched in production.
A backup you have never restored from is a hypothesis, not a safety net — the restore procedure itself needs to be exercised, not just the backup job.
How it fails: nightly backups run successfully for a year, then a real incident reveals the restore script was broken the whole time, or restores to a schema that no longer matches production.
Failed logins, permission changes and unusual access patterns are only useful if something is watching them in something close to real time.
How it fails: logs are collected and stored, technically satisfying an audit checkbox, but nobody is alerted when they show a clear break-in attempt until weeks later during an unrelated review.
Any endpoint reachable from the internet without a limit is an invitation for credential stuffing, scraping, or denial-of-wallet abuse against usage-billed services.
How it fails: a public API or login form has no request cap, and a single scripted attacker runs millions of guesses or triggers enough billed invocations to produce a very large bill overnight.
Sources
- OWASP, "OWASP Top 10:2025" — A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A06 Insecure Design, A09 Security Logging and Alerting Failures. owasp.org/Top10/2025/. Accessed 26 Jul 2026.
- NIST, SP 800-34 Rev. 1, "Contingency Planning Guide for Federal Information Systems" — backup and disaster-recovery planning, including tested restore procedures. csrc.nist.gov/pubs/sp/800/34/r1/upd1/final. Updated 11 Nov 2010. Accessed 26 Jul 2026.
- NIST, SP 800-57 Part 1 Rev. 5, "Recommendation for Key Management: Part 1 – General" — cryptographic key and credential lifecycle, rotation and compromise handling. csrc.nist.gov/pubs/sp/800/57/pt1/r5/final. Published May 2020. Accessed 26 Jul 2026.
- Center for Internet Security, "CIS Critical Security Controls v8.1" — prioritized, prescriptive safeguards including vulnerability and supply-chain management. cisecurity.org/controls. Accessed 26 Jul 2026.
- DeployCloud, "Secrets Management Guide" and "Rate Limiting Guide" (this site) — implementation-level companions to items 1 and 8. deploycloud.allfrontierglobal.com/secrets-management-guide and /rate-limiting-guide.
FAQ