The Content Security Policy (CSP) was introduced as a defensive mechanism that allows site owners to define what assets are authorized to be consumed by the browser in the context of a given website. CSP is an effective countermeasure against Clickjacking, XSS, mixed content and content injection attacks. By simply defining what sources you allow browsers to load on your site, you can protect your visitors from a slew of content injection attacks.
- Opening almost any website (e.g. www.google.com) in your browser
- Open the browser developer tools (press F12 or ctrl+shift+i)
- Click on the Console tab
While you may argue that this does not constitute a vulnerability because we’re essentially attacking ourselves, the fact remains that if an attacker can manage to reflect content to the HTML source (e.g. Reflected XSS) then they can reflect any malicious payload they choose, such as a script that steals credentials or the session token enabling session hijacking. In other words, if there are any XSS vulnerabilities on the site (and based on the OWASP Top 10 we know they’re everywhere), then its game over.
You can easily inspect the CSP for www.mozilla.org because its returned in the server response headers in every request. As you can see below, Mozilla locks down which assets and which 3rd party domains are trusted:
Cross Site Scripting attacks are successful because the allow malicious users to modify the page’s contents. CSP provides a way that website owners can tell visiting browsers what content should be loaded, everything else is blocked. By implementing a solid CSP, you provide a secondary defence against XSS, block attackers from framing your site (Clickjacking) and help protect against Sidejacking attacks by preventing mixed content. In a follow up post, I’ll go into more details on how to implement and debug CSP.