Hey Craig,
I did open this
discussion somewhere else:
https://discourse.wicg.io/t/xss-prevention-in-the-browser-by-the-browser/3518/4
On 4/24/19 5:55 PM, joris wrote:
Yes,
in a way it would do the same job as a sanitizer,
but it is more than that.
I think that a simple sanitize function could
Yes,
in a way it would do the same job as a sanitizer,
but it is more than that.
I think that a simple sanitize function could
be wrong.
A function to disable JS would
be the last barrier for an XSS.
While a sanitize function
would just be another
barrier between XSS Code and
the Browsers JS
Hi Joris,
I think we should follow Anne's advice and discuss this elsewhere.
But what you're suggesting is starting to look a lot more like a browser
provided sanitiser function:
document.getElementById('xss_output').innerHTML = *sanitize*(*user_input*);
There is some discussion about it at:
Yes.
But: this would still shrink the masking/sanitizing efforts,
because you could just use a tag that nobody else should use
inside user input like:
onload="disableScripts(document.getElementById('xss_output')">
let user_input; //Load user_input without masking
let pattern
Hey Joris,
This isn't really the place to discuss new web platform features.
https://discourse.wicg.io/ might be a better starting place.
https://whatwg.org/faq#adding-new-features might also help in getting
a handle on what it takes to add new features to the web platform.
Kind regards,
Anne
Hi Joris,
I think this suffers from the same issue...
In a previous Mail I talked about
a noscript tag, that if set on a HTML Element would
direct the Browser not to execute any Scripts inside
that Element, thus behaving like JS would be disabled
globally. But this approach has the disadvantage of
being enabled and disabled entirely in HTML,
thus
