Content Security Policy (CSP) is a security feature for web applications that can protect websites and users from cross-site scripting (XSS) and data injection attacks.
When you visit a web page, your browser usually reads out of the pages itself, as well as lots of other content - external images, scripts, pages embedded via iframe, etc. Examples of these are popular buttons for social sharing (Google +1, Facebook Like ...) Google Analytics, discussions on third-party articles, etc. Here's all right because if you've put these elements on your site on a voluntary basis, you probably agree to uploading them to your site.
Unlike the script hosted on https://apis.google.com, it downloads it, and the problem is in the world. The only one, who knows where to retrieve external resources, are you the site administrator, and this is what the CSP just mentioned.
CSP works on the principle that using a special Content-Security-Policy HTTP header, you specify a policy for where to upload resources. Let's show it straight on the example. If the web page together with the answer returned this:
Content-Security-Policy: script-src 'self' https://apis.google.com;
so the above malware script problem could not be jeopardized because the browser makes scripts only from https://apis.google.com and from itself ('self'). Another example might be:
Content-Security-Policy: font-src 'none'; img-src 'self' https: //*.domain.com;
Here we have determined that the fonts will not be uploaded to the site anymore, and we will get the images again only from ourselves and from any subdomain of domain.com via HTTPS.
If you want to define where the individual elements can be uploaded, you have several options. The first is direct definition:
https://domain.com - Only from domain.com using HTTPS
https: //*.domain.com - only from any subdomain of domain.com using HTTPS
domain.com - from domain.com using any protocol
*: //domain.com: 81 - any protocol from domain.com and port 81
https: - from anywhere but using HTTPS
You can use the wildcard operator instead of the log, the rest of the domain or port. Additionally, different keywords are specified instead of exact locations:
* - record sources from anywhere
, None '- sources cannot be recorded anywhere
, Self '- only by itself (the same protocol, domain and port)
, Unsafe-inline '- allows inline resources such as scripts and styles (to be discussed later)
, Unsafe-eval '- the same as inline but for the eval ()
So far, we have met the script-src, img-src, and font-src directives. Their complete list can be found, for example, on the Mozilla Developer Network. However, there is one exception, which is the default-src directive, which serves as the default value for all other directives unless specified. For example, here:
Content-Security-Policy: default-src 'self'; script-src 'none'; img-src *; media-src https://youtube.com;
We have set the default policy to 'self', which means that, for example, fonts (which are not specified here) can only be read by themselves. Additionally, we have disabled all scripts, images can be uploaded from anywhere, and media (audio/video) can only be inserted from YouTube over HTTPS.
The syntax is quite simple. After the Content-Security-Policy header is listed: always followed by a directive and an arbitrarily long list of sources separated by spaces and ending with a semicolon. If you give one directive multiple times:
Content-Security-Policy: script-src domain.com; script-src google.com;
This will ignore the other and so it will not be possible to run scripts from Google. The right option is:
Content-Security-Policy: script-src domain.com google.com;
If you do not have access to a web server and cannot set HTTP headers, of course you can use the meta tags:
The user will be redirected to a phishing site that may look exactly like the template and ask for login information. A less experienced user does not have to notice this and thus comes to an identity.
CSP solves this easily and elegantly - all inline scripts are forbidden. All you have to do is modify the web page so that everything is downloaded from external files. If it's not a large project, it's not that much of a problem, and more or less it's "best practice" - it's easier for caching, the web is more readable for other developers, the code can be optimized,
If you cannot get around with inline scripts for some reason, here is the option to set 'script-src' and 'style-src' as 'unsafe-inline'. This allows inline scripts to come up with one of the biggest CSP benefits. Indeed, inline scripts are quite common and can sometimes not be circumvented without them. Is there no compromise between total prohibition and risk clearance of everything? Yes, there is.
The first option is the so-called nonce. In this case, the CSP header could look like this:
Content-Security-Policy: script-src 'self' 'nonce-KIOdfLfdosfoDKlksdf'
Any script on a page to be executed must contain the same nonce (referred to as tag script parameter):
Sign up now