Talk:XSS (Cross Site Scripting) Prevention Cheat Sheet
Rule #5 has a few concerning points: It mentions <a href=http://...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a >, but I think more common is <a href=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a > where the full href contents are untrusted. There should be some mention here about relative links too.
Is the following a contradiction?
"Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the %HH escaping format."
"Note that entity encoding is useless in this context."
The following is confusing and possibly nonsensical. "Including untrusted data in data: URLs should not be allowed as there is no good way to disable attacks with escaping to prevent switching out of the URL."
Other points about Rule #5:
DOM Based XSS
Consider cross linking and adding information to ESAPI4JS for DOM-Based XSS Protection.
For quick reference it has nearly the same API as ESAPI for Java EE
This also is a direct port of the Java EE Encoders
Agree with all above. In addition – article will greatly benefit from examples of evil input data examples. For instance statement “Most web frameworks have a method for HTML escaping for the characters detailed below. However, this is absolutely not sufficient for other HTML contexts” would be even bolder if accompanied with example of alert statement executable in different contexts after it was HTML escaped. Like for code
<% String url = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) ); %>
Following input : …
Will produce executable