Update: Recommend Input sanitization as supplementary defense

[timurozkul]

What is missing or needs to be updated?

The current cheats do not recommend input sanitization:
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html]

I agree that input sanitization is not a strong prevention method for a sophisticated attacker for preventing malicious input but it is still a valid way of preventing. All other recommendation on input validation require individual implementation making it high workload and more error prone vs implementing a sanitization library as middleware which is quick win. Sanitization libraries help fend off a degree of attacks (ie DOMPurify). Many organization use sanitization libraries if they follow the OWASP guide and remove the sanitization libraries I would guess that they all would be worst off.

How should this be resolved?

OWASP should recommend input sanitization as supplementary defense instead of primary however it should still be recommended none the less.

[randomstuff]

It makes sense for HTML (and some XML-based languages) under very specific circumstances but in many cases you actually want to do proper escaping instead. However it is actually recommended in this case:

HTML Sanitization

When users need to author HTML, developers may let users change the styling or structure of content inside a WYSIWYG editor. Output encoding in this case will prevent XSS, but it will break the intended functionality of the application. The styling will not be rendered. In these cases, HTML Sanitization should be used.

HTML Sanitization will strip dangerous HTML from a variable and return a safe string of HTML. OWASP recommends DOMPurify for HTML Sanitization.

For other contexts (such as SQL), I don't believe it makes sense and is opening up a huge can of worms 🥫 🪱 🪱 🪱 🪱.