Pillar
Web Security
Web security is application security as the browser sees it: HTML, cookies, CSP, Trusted Types, the origin. If it only exists in your API tests, it is not web security yet.
XSS defenses
Encode the sink, then Trusted Types
Open the list
WAF tools
Filter the edge, not the sink
Open the list
Bot management
Slow the script, not the customer
Open the list
Questions about Web Security
Why do Web Security and Application Security share the XSS list?
Because the failure is one failure. You encode in the application so the browser does not run the string. We show the list in both places so a reader who searched for either phrase does not hit an empty page. We will not clone it into a third ‘frontend security’ category.
What is on the XSS defenses list?
he, the OWASP Java Encoder, DOMPurify, sanitize-html, Trusted Types, and CSP. Encode the sink first. Sanitize when you must accept HTML. Use Trusted Types and CSP when you want the browser to refuse the miss.
Where does CSRF sit?
It belongs here. The long guide is already on the blog. A CSRF defenses list will appear under Web Security when we can score tokens, SameSite, and fetch metadata the way we score encoders.
Is CSP a product you can list?
CSP is a browser lock, not a vendor. It is a row on the XSS list because it is a control you ship with the page. Tools that only generate a policy will have to earn a different list.
What about cookies and session flags?
They will get a web-security list: Secure, HttpOnly, SameSite, and the cases where SameSite is not enough. Not published yet. Do not wait for the list to set the flags.
