Application hardening references
Application-level security: the settings, middleware and configuration that live in the code you deploy, organised by the framework you are working in.
Every page names the exact setting, how to prove it actually took effect, and what it breaks before it breaks it.
Frameworks
Section titled “Frameworks”How to read a page here
Section titled “How to read a page here”Every control page has the same four parts, in the same order:
- The fix — the actual setting or middleware, above the fold.
- Verify it worked — how to prove it took effect, and where to run that: a shell, the framework’s own CLI, an HTTP response, or browser devtools. Green appears nowhere else on this site.
- If you see this — the literal error strings the misconfiguration emits, each shown with the file it was read in. If a string is quoted here, it was read in the source.
- Before you ship this — what the control breaks and how to stage it. A page that only tells you what to turn on is not finished.
Severity means the exposure a control closes — not how hard it is, and not how often
it gets recommended. Several pages here are rated low and say so, and several are
verify pages because the framework’s shipped default is already correct.
More on the rules behind that in how these pages are written.
What is in scope
Section titled “What is in scope”Configuration that belongs to the application. Configuration that belongs to the server underneath it — TLS termination, daemon config, firewalls, container runtimes — is not covered here, and the line between them is on application vs server.