Learn about CSP-based XSS protection
Ákos Hajba (Software Engineer, Avatao)
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.
Content Security Policy in practice
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.
Reading Time: 9 minutes The cloud data system has numerous advantages as well as many dangers. 80% of companies have had at least one data breach in the past months.
Reading Time: 7 minutes Companies understand the way you handle data security has a direct impact on their bottom lines. This has led to most companies requiring all vendors to have a special compliance certificate called an SOC2.
Reading Time: 7 minutes Our team attended Hacktivity, the biggest IT security conference in Central and Eastern Europe – a whole day full of interesting presentations and workshops. Click to see how we liked it!