I'm wondering what this new technique will not protect us against.

As I see it, since inline scripts are disabled (and I assume that includes javascript: links) then it solves the issue of covert theft of sensitive data via auto-executed JavaScript.

However, it would still be possible to alter the data on the screen in unexpected ways, and possible to create a convincing Phishing scam by providing a link out to another website.

Is this accurate, or are out-links prohibitable also?

There may be tricky ways to capture sensitive data in an external resource call as well, as I am not familiar with the scope of CSP.

What is the scope of a would-be XSS attack with the presence of a tight CSP?

Edit: updated assumptions for the purpose of this post:

  • Users have a CSP 2 capable browser.
  • Inline style= is still going to be allowed by the policy. style-src ... unsafe-inline
  • We will only allow resources to be loaded from domains we control. (no external images)
  • We run our own CDN, so that domain has no 3rd-party content, and fits the same security standards as the main domain.
  • 1
    Not exactly what you asked, but this quote from the standard is relevant: "Content Security Policy (CSP) is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth..."
    – paj28
    Jul 28, 2016 at 12:33

3 Answers 3


However, it would still be possible to alter the data on the screen in unexpected ways, and possible to create a convincing Phishing scam by providing a link out to another website.

Is this accurate, or are out-links prohibitable also?

Yes it is accurate with one caveat: people on your site run modern browsers. For this exact reason, my team considers XSS without actual content injection (e.g. injecting into an unquoted tag attribute context) to be lower priority than a content injection bug itself because of CSP. We are blessed with having virtually no users on browsers that don't support some form of strong CSP.

What is the scope of a would-be XSS attack with the presence of a tight CSP?

Forgive me here if this sounds soapboxy, but your question does not define "tight CSP", so let me elaborate on some things many overlook.

For the sake of argument, let's say this is a policy that is proposed (line breaks added for clarity, this is not a valid header):

Content-Security-Policy: default-src 'self'; img-src https: data:; connect-src paypal.com api.example.com; script-src 'self' ajax.googleapis.com; style-src 'self' 'unsafe-inline'

Note: removing unsafe-inline from style-src is not practical today.

That's a pretty good policy with some obvious and not so obvious flaws, but inline script is not allowed. There are many more caveats to consider with CSP, it's not just about disabling eval and inline script (yes javascript: and on* event handlers are included).

Locking down 3rd parties to actually limit XSS

So many other vectors still exist

GitHub's CSP journey contains many points on how the policy was tuned to prevent certain attacks.

All of the below can be abused with the proposed policy.

  • Removing 'self' from script-src to prevent XSS via JSONP
  • Exfiltrating CSRF tokens via img and form tags
  • Moving hosted flash files to a different origin instead of 'self' because flash ruins everything.
  • Using dynamic policies to prevent unexpected use of APIs that should only be used from a specific set of pages.
  • Limiting use of 'self' for frame-src/child-src
  • Abusing the base tag.

Sometimes, CSP just doesn't apply.

It's possible to circumvent CSP entirely. See PDF content-type sniffing for an example where user-controlled data on a page can really mess things up.

There's literally nothing we can do about this from CSP's perspective.

And sometimes, the internet makes you cry.

See Stealing the pie without touching the sill where CSS can be used to steal AND exfiltrate data on a page without javascript.

Because removing 'unsafe-inline' is not practical, this attack is possible. However, this attack is difficult to execute.

  • I've edited my post to clarify that we control our own CDN, and can make any changes needed. All in all this is good information. Thanks. Jul 27, 2016 at 20:24

We need to consider exactly what a tight policy is. I have identified three levels:

Level 1 - Stop XSS

At this level, a tight policy will stop all XSS. If the site has XSS flaws, these will not be exploitable (assuming the user's browser supports CSP).

An XSS attacker could still reference resources on their own server, which creates a web beacon. They can see users' IP addresses, and deliver malicious content (e.g. exploiting image rendering bugs). They can also redirect forms, potentially creating a highly-realistic phishing form.

Level 2 - Stop beacons

At this level, all embedded resources can only be loaded from trusted sources, so web beacons are not possible. Form actions are also restricted, so direct form redirection is not possible.

An XSS attacker can still change the page contents and layout. This includes embedding malicious links. I'm not convinced this is a major phishing risk though: savvy users will check the address bar before entering credentials, and non-savvy users will fall for much simpler tricks.

Level 3 - Stop inline CSS

This reduces an attacker's ability to change the page layout - although they can sill control content and inject links.

CSP Auditor

I created the CSP Auditor tool to help assess policies. It only assesses whether policies meet level 1. It turns out that the majority of major sites with CSP have a policy that does not meet level 1. Levels 2 and 3 will be even harder to achieve - so much so, I'm not putting checks in the auditor (for now at least).

  • I've updated my question to clarify. So Level 2 is for me. Level 3 (disabling style=) is not practical in this case. And even if I were to take that approach, attackers would still be able to "change the page layout" to a lesser extent, with table language, etc., correct? Jul 27, 2016 at 20:27
  • @GeorgeBailey - I've not read the "Stealing the pie without touching the sill" link yet... it may be a crucial difference between level 2 and 3.
    – paj28
    Jul 27, 2016 at 20:36
  • "may be a crucial difference between level 2 and 3" I concur. Of course the best thing is to properly encode all user-defined input. CSP is a second extra layer of protection. I wonder if I can prevent outlinks, so that users can't click their way to an external site, nor can attackers load external resources? I'll have to post a question about that some time. Jul 28, 2016 at 12:28
  • @GeorgeBailey - there's no way to prevent outlinks with CSP 2. CSP 3 is a work in progress - you could submit a proposal!
    – paj28
    Jul 28, 2016 at 12:33
  • I think that would be a great addition to CSP 3. For example, an online business accounting system should not contain outlinks on most pages. I don't have time to make the W3 proposal right now though. Jul 28, 2016 at 15:30

CSP protects you against many script driven attacks. Your belief that "solves the issue of covert theft of sensitive data" isn't accurate. It may solve the issue of covert threat via scripts in that page, but it doesn't, for example, solve cross-tab issues, or proxy manipulation.

More broadly, there is no complete list of attacks, and so trying to enumerate "I'm wondering what this new technique will not protect us against" is an infinite set.

  • Meta: I know I'm not answering the question asked, and I do not see a trivial edit to make it answerable. Jul 27, 2016 at 20:36
  • Perhaps "I'm wondering what HTML injection attacks this new technique will not protect us against." ?
    – paj28
    Jul 27, 2016 at 20:38
  • Thanks @paj28 -- I wonder if there's HTML attacks that are not a superset of JS attacks. oreoshake makes mention of the scriptless attacks, don't know if CSP impacts them, which is sort of my point--ask "what does this do for us", it's crisper. Jul 27, 2016 at 20:52
  • "Your belief that 'solves the issue of covert theft of sensitive data' isn't accurate. doesn't, for example, solve cross-tab issues, or proxy manipulation" Don't get smart on me. Obviously Proxy Manipulation has nothing to do with CSP, and should be handled at the HTTPS level. I don't know exactly what is meant by "cross tab issues". Anyway, I've edited the question to clarify. Jul 28, 2016 at 12:23
  • "there is no complete list of attacks .. is an infinite set" Perhaps you are right. The reason I asked such a question, is because the majority of CSP articles describe how great it is, and on a basic level what it allows you to do. I think an article clarifying what it won't protect us against is very important, and potentially will create some useful canonical answers for future visitors. For that, I think an explanation of worst-case attacks, and likely attacks would suffice, without explaining every 'possible' attack. Jul 28, 2016 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.