1

I understand CSP can be beneficial against multiple attack vectors (i.e clickjacking, XSS), but as it specifically relates to XSS -- why is it a solution?

My reason for asking this question stems from a question that i was recently asked. "If input sanitization / output encoding always works, then why has XSS still a thing?"

My initial thoughts were: Because it's not always that simple. XSS can come in multiple contexts, in different forms, etc and CSP (if done correctly) can be an easy way to prevent this. I have primarily always viewed it as a defense in depth measure that should never be used as the sole mechanism against XSS.

With that being said, are there any cases where sanitize input / encode output isn't sufficient against XSS?

3
  • In the title you ask why one should use CSP against XSS while in the question text you ask instead if there are cases when sanitizing input does not help against XSS. Please clarify what you really want to know, i.e. ask the same thing in title and question body. As to why CSP: fully securely sanitizing input is hard, CSP instead is much easier to do. Mar 10, 2020 at 15:04
  • What kind of CSP policy are you talking about? Specifically, script-src of a source list or of a nonce with or without 'unsafe-eval'. Mar 10, 2020 at 15:27
  • What do you mean by "sanitize input/encode output"? Sanitizing input x assuming it's HTML doesn't help if it ends up as the content of a <script src> attribute for example instead of just inlined where a document fragment is expected. Are you willing to assume that each value derived from an untrusted input is correctly sanitized / encoded for all the output contexts it reaches? Mar 10, 2020 at 15:30

1 Answer 1

1

"If input sanitization / output encoding always works, then why has XSS still a thing?"

Because input sanitization and output encoding are often not used, or implemented incorrectly.

With that being said, are there any cases where sanitize input / encode output isn't sufficient against XSS?

You theoretically do not need CSP when santization and encoding is done well. That is why it is a defense-in-depth security measure, it adds protection when an other measure fails. But a lot can fail: The visited website could have a programming flaw. The website's dependencies may contain flaws. The used browser could contain a flaw. And many more.

CSP decreases the attack plane: your browser has many features to serve website content to users. You as the website maintainer are (hopefully) somewhat aware which kind of features you use. Therefore, you could easily disable the features you do not need using CSP and other defense-in-depth measures. Some aspects will protect against XSS if the other measures failed blocking it.

On the other hand, CSP should not be used as the single measure against XSS. It is specifically designed as a fail-safe. It does not prevent the underlying issues that allowed for XSS in the first place, and thus may not cover every opportunity attackers have.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .