Update: XSS Prevention Cheat Sheet to show common failed anti-patterns attempted as XSS defense

[kwwall]

What is missing or needs to be updated?

The current XSS Prevention Cheat Sheet is great at describing what developers should do to prevent XSS vulnerabilities and that definitely should be (and is) its primary focus. But despite that, there is a lot of bad advice elsewhere on the Internet (e.g., Stack Overflow is one such common source of misinformation out there) where developers ignore the advice in this XSS Prevention CS in search of a short cut so that they can avoid providing specific output encoding at or near the hundreds or more given XSS sinks that SAST or DAST or manual code reviews discover.

Instead of using the approaches recommended in the XSS Prevention CS, I often find developers trying to solve XSS vulnerabilities with a single, simple, stop-gap solution, such as only using CSP headers as a defense or only using HTTP interceptors to provide HTML sanitization or output encoding in a single specific context (usually HTML). While those approaches might be useful as a defense-in-depth layer (depending on the situation), the never actually fully remediate the XSS vulnerabilities.

If this were just a few cases it would be easy enough to deal with, but for every case where I find these misguided approaches during code review, or every time that @xeno6696 or I correct someone asking an ESAPI-related XSS question on Stack Overflow, I am confident that we are missing several others. However, both Matt and I have seen these approaches both in code and discussed as "solutions" frequently enough to realize that it is a common anti-pattern.

Therefore, I think it would be useful to have a small section in the XSS Prevention CS to call out how NOT to defend against XSS vulnerabilities.

How should this be resolved?

To partially address this problem, I have wrote up the detailed ESAPI wiki post, XSS Defense: No Silver Bullets that I now refer developers I find doing this (which are a lot) to that wiki page. However, as I mentioned in https://github.com/OWASP/CheatSheetSeries/issues/517#issuecomment-1435757162, I think this advice would be more effective if the essential parts of it can be distilled and included in the XSS Prevention Cheat Sheet where I think many more developers look first.

So, I am proposing to create a PR that will highlight the main points from the ESAPI wiki page in the XSS Prevention CS and then link to it for anyone wanting to see more details.