[Owasp-leaders] OWASP DOM based XSS definition, which looked a little off

Achim achim at owasp.org
Thu Oct 24 13:40:59 UTC 2013

Hmm, it's hard to give a proper definition of XSS from a independent point
of view. The definition often (always?) depends on the context.
For example: if there is a rich content editor, the data needs to be stored
as is. And in this case it is *not* "stored XSS".

An this example is exactly, why I slightly diagree with Jims suggestion to
store anything sanatized, as it can break intended functionality, obviously.

My suggestion for developers is: check data at each boundary, and encode proper
when data leaves your control (aka output encoding). This encoding must be
according the sink. Where the sink can be any of HTML, CSS, JavaScript, href,
etc. (all in UI) or SQL (in backend). You see that each sink needs its own
encoding. Again, see what we suggested in
A similar concept should be used for other types of XSS.

This approach does not mean that only output encoding is necessary, you need
input checks for that data used under your control (your program).

Sanitation is a bad approach, IMHO. If input checks fail, ignore all data
(may be different in some less secure cases).

These rules work for all kind of injections, not only XSS.

Did I miss something?


Am 24.10.2013 14:15, schrieb Giorgio Fedon:
> It seems that dividing the issue by remediation is more complicated than
> what it may seem. In addition I think that in the search of a proper
> definition of DOMXss we need to define a correct definition of XSS, in a
> sense that we should say what XSS is and what XSS is not. As well as
> what DOMXss is.

> On 10/24/2013 01:10 PM, Jim Manico wrote:
>> I prefer to sanitize both on input to ensure I save "safe" HTML in the
>> database (and also as potential attack detection).

More information about the OWASP-Leaders mailing list