The security model of web is rooted in the same-origin policy. Each origin is isolated from the rest of the web and codes should only have access to their origin’s data. Because of this model, browsers trust every code that shows up on a page as it’s a part of the pages’ security origin.
Cross Site Scripting (XSS) attacks exploit this behaviour by injecting malicious code into the page. Since the first formal reference to XSS in a CERT advisory in 2000, researchers and practitioners have investigated ways of detecting, preventing and mitigating this issue. Despite these efforts, it is still one of the most prevalent security issues on the web and new variations are being discovered as the web evolves.
Today, Content Security Policy (CSP) is one of the most promising countermeasures against XSS. It is a declarative policy mechanism that allows web application developers to define which client-side resources can be loaded and executed by the browser. By blocking inline scripts and allowing data only to be loaded from trusted sources, CSP aims to keep the application safe even if an attacker is capable of finding an XSS vulnerability. In addition of its primary goal, mitigating and reporting XSS attack, CSP also offers protection from clickjacking and mixed content vulnerabilities. It might appeal to use CSP as the sole mechanism to protect an application, but it is rather a defense in depth mechanism that is responsible to mitigate attacks breaking through the first line of defense.
There are a few cases when switching to CSP is not advised. The most obvious is a static website without any logged-in functionality where XSS is a minor threat. The second group consists of large applications using frameworks and template systems without sufficient protection against XSS. In this case, it is highly recommended to adopt safer frameworks and review the critical parts of the code.
To enable CSP, all you have to do is set the Content-Security-Policy header to a valid policy (it is possible to enable it in a meta tag, but that has limited options). Implementing CSP however can be a challenge. The security benefit is overwhelmingly concentrated in two directives that prevent script execution:
default-src in their absence. A high percentage of enabled policies underrate the importance of
To address this issue, CSP2 introduced whitelisted paths allowing developers to specify paths instead of domains (e.g. trusted-site.com/library/script.js). Unfortunately, this restriction has been relaxed. If a whitelisted source contains an endpoint returning a 30x response, that redirector can be used to load resources from a trusted source even if it does not match an allowed path.
Content-Security-Policy: script-src trusted.com cdn.com/trusted-script.js <script src="//trusted.com?redirect=cdn.com/evil-script.js">
Older browsers, which don’t support the CSP3 standard will ignore the
strict-dynamic keywords. A possible solution for that is to use the
unsafe-inline keyword in the
script-src directive as a fallback. This will result in no protection against XSS vulnerabilities, but will allow the application to function properly for every user.