Security3 min read
The web application security checklist we run before every launch
Not a compliance document. This is the list we actually work through before a client site handles its first real user.
Application security guides on authentication, session handling, XSS and CSRF defence, secrets management, headers and dependency risk.
Not a compliance document. This is the list we actually work through before a client site handles its first real user.
The Top 10 is a list of categories, not bugs. Here is what each one looks like in a real codebase.
React escapes text by default, which handles most XSS. The remaining cases are the ones people write deliberately.
SameSite=Lax handles most CSRF. 'Most' is doing real work in that sentence, and the gap is where the interesting attacks live.
Parameterised queries have solved this for twenty years. Injection persists because of the one query someone built with string concatenation.
Six headers, most of them one line each. They will not fix a vulnerability, but several of them turn one into a non-event.
Your application is mostly other people's code. The security question is not whether you trust it, but what happens when one of them is compromised.
An API has no UI to hide behind. Every endpoint is directly reachable, and that is the correct way to think about securing one.
Forced quarterly rotation and mandatory symbols make passwords worse. Current guidance says length, breach checks and MFA.
Most sites need less than the compliance industry suggests and more than they currently do. The gap is usually consent and retention.
No spam. Just the occasional case study and craft breakdown.