I so wish this one sparrow would a summer make :) #xsshttps://twitter.com/garethheyes/status/1022392850183536640 …
-
-
Fully agreed, but what lots of developers believe in, is that CSP is a magic header that stops XSS, and such language ("our customers remain protected thanks to [..] CSP") only makes it worse.
-
I'm pretty sure developers know CSP is a magic header that breaks your website. The biggest problem with CSP is that it was enforced by web browsers, instead of by templating engines. In some sense it was browser developers pulling a "We must do something; this is something..."
-
However, around the time of CSP 2 browsers also needed a CSP-like mechanism for other reasons (app sandboxing in Firefox; extension sandboxing in Chrome) and also there was somewhat of a sunk-cost fallacy that's lasted until recently (IIUC) Google told Google it doesn't want CSP.
-
What I'm getting from it is that touting CSP is passé. I'm indifferent to that, what bugs me is that selling CSP as an XSS protection mechanism is not only technically wrong, it's harmful to the ecosystem & it makes my job explaining XSS to devs harder.
-
Sure. I'm trying to explain why they say that: CSP is "what browsers are doing about XSS." It's too hard to say "We tried to do something about XSS but it didn't work so we're not going to do anything now."
-
Interesting. Ultimately, everything combating XSS on client side likely relies on some browser feature. E.g. sanitizers rely on inert documents. The reason CSP did not fix XSS is maybe that the primitive was not fitting? Per document header instead of e.g. an API to use by libs?
End of conversation
New conversation -
-
-
It's definitely a better alternative. I'm looking forward to the next one :-)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.