How these pages are written
Organised by framework, not by vulnerability
Section titled “Organised by framework, not by vulnerability”Pages are grouped by the framework you are working in, because that is how the problem actually arrives: you are not looking for “CSRF”, you are looking for how CSRF works here, in this version, with this proxy in front of it.
Each framework has:
- an overview with the full checklist, which assembles itself from the control pages rather than being maintained by hand;
- control pages — one hardening action each;
- threat pages — a specific exposure, how it is reached, and what closes it.
The rules the content follows
Section titled “The rules the content follows”These are worth stating because they are what make the pages worth trusting.
Version boundaries are marked, not glossed. Where a framework major changed a default or removed an API, the page says which version and shows both sides, with a badge carrying it. Most bad application-security advice is not wrong so much as expired.
Quoted error strings were read in the source. Every “if you see this” block names the file the string came from. None are reconstructed from memory or tidied up for readability, because an invented error string is indistinguishable from a real one until it wastes someone’s afternoon.
Facts carry a date. Each page records when its claims were last checked and against which version. Frameworks move faster than servers do, and a reference that hides its own age is worse than one that admits it.
Severity means the exposure closed. Not effort, not popularity. Some widely recommended controls close very little, and those are rated low here and say so.
A secure default gets a verify page, not a fix page. Several controls here turn out
to ship correct — Django’s nosniff and referrer policy, Spring Boot’s error handling,
Express’s 100kb body limit. Those pages tell you what to check rather than inventing a
change you do not need.
What is deliberately not here
Section titled “What is deliberately not here”No benchmark you can hand to an auditor, no scanner, no ranking of frameworks against each other. Where a control maps to a published OWASP ASVS requirement the id is shown, and only when it has been read in the standard itself.