jmanico
commented
6 years ago This library is for encoding only. It does not do HTML sanitization. Also, DOM XSS is best defended against buy using safe JS API’s like .textContent (not escaping). You also need CSP. You should also consider HTTPOnly cookies. And the X-XSS-Protection header.
So we’re not trying to address any of those other defenses; just encoding.
Where do you propose we make it (more) clear this is for encoding only?
Aloha, — Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805
On Mar 29, 2018, at 12:44 PM, vikxcoder notifications@github.com wrote:
I think we need to make clear somewhere in the documentation clear that customers need to take additional steps for preventing DOM based XSS when using this library. Current documentation says about how to encode in direct CSS/HTML contexts but does not talk about how to encode when inserting Untrusted Data into HTML Subcontext within the Execution Context.
There are many such examples in [1] and I think its worth it to make a note of it somewhere in the documentation of this document.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
ghost
I think we need to make clear somewhere in the documentation clear that customers need to take additional steps for preventing DOM based XSS when using this library. Current documentation says about how to encode in direct CSS/HTML contexts but does not talk about how to encode when inserting Untrusted Data into HTML Subcontext within the Execution Context.
There are many such examples in [1] and I think its worth it to make a note of it somewhere in the documentation of this document.
[1] https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_then_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_HTML_Subcontext_within_the_Execution_Context