security-hardening

Security Hardening

Assume every input is hostile, every user is an attacker, and every secret in the repository is already public. Then check whether the code agrees.

Scope: defensive security — finding and fixing weaknesses in code the user owns or is authorised to assess. Never scan, probe or send traffic to infrastructure without explicit confirmation of ownership or authorisation. Produce fixes and detections, not weaponised exploits.

---

The order of operations

Findings are not equal. Work top-down; the first three account for most real breaches.

1. Secrets — anything committed is compromised.
2. Broken access control — the most common critical finding in real systems.
3. Injection — SQL, command, template, LDAP, NoSQL.
4. Authentication weaknesses — sessions, tokens, resets, MFA.
5. XSS and content injection.
6. SSRF and unvalidated redirects.
7. Insecure configuration — headers, debug modes, exposed endpoints.
8. Supply chain — dependencies, install scripts, build pipeline.
9. Cryptographic failures — at rest, in transit, in tokens.
10. Logging and monitoring gaps — an undetected breach is an unbounded one.

references/owasp-checklist.md carries the full per-category checks.

---

1. Secrets — start here, always

git log --all --full-history --name-only -- '*.env' '*.pem' '*.key' '*.p12' '*credential*' | head -30
git ls-files | grep -E '(^|/)\.env($|\.)' | grep -v example

Plus the pattern scan in scripts/secret-scan.sh / .ps1.

Anything found in history is disclosed, even if a later commit removed it. It lives in every clone, every fork, every CI cache. The remediation order is fixed:

1. Rotate the credential. Immediately, before anything else.
2. Check for abuse — provider audit logs, unexpected usage, unfamiliar IPs.
3. Purge the history (git filter-repo, or BFG) and force-push, with every collaborator re-cloning.
4. Prevent recurrence — secret scanning in CI, pre-commit hooks, .gitignore.