Active content on websites (i.e. JavaScript, CSS, ActiveX) can be a security risk for internet users and website operators since they can be manipulated by cross-site scripting. The Content Security Policy (CSP) was introduced to ensure that internet sites could be used to their full extent without having to worry about any security risks. The security standard is designed to protect against malicious attacks and is now supported by most web browsers. The security concept protects both websites and internet users. But what is behind it and how does CSP work?
The Content Security Policy dates back to 2004 when it was still known as 'Content Restriction'. The reason for this effort was an increasing number of vulnerabilities in internet scripts. Cross-site scripting (XSS) is a criminal method of infiltrating malicious code into a website, and poses a major risk for users. Users access a trustworthy website, but there is a script running that loads malicious data from an external source. Cyber criminals often make use of security vulnerabilities in the website’s commentary functions. By doing this, they can gain access to personal computers without internet users knowing it. Website operators won’t even notice that strange code has been introduced.
To solve this problem, the Mozilla Foundation promoted the development of the CSP. The advantage behind the security standard is that rules can be set up in the browser to tell the software which scripts it is allowed to load and which it isn’t. To do this, the Content Security Policy uses HTTP headers.
The Mozilla Foundation is behind the development of the Firefox browser. The non-profit organization is responsible for the orientation of Mozilla’s projects and innovations to do with the internet. The Foundation was founded by former Netscape employees, who developed one of the first web browsers.
When communicating online, clients and server exchange data via the Hypertext Transfer Protocol (HTTP). HTTP header fields are an important part of the requests and responses: parameters and arguments are transferred in these, which are important for exchanging information between the two call participants (server and client). They are generally divided into inquiry and response fields, and can contain information such as character set, language, and cookies. CSP is implemented as a response header field. This means that the server delivers the information and the browser processes it.
The Content Security Policy header is created by the website operator and inserted on every subpage of the website where you want the security standard to be applied. As the operator of the website, you have the possibility of defining different security precautions for each individual page. You can implement the security concept more easily by creating .htaccess files, which are located in the same (or hierarchically higher) folders as the corresponding web pages, or by embedding CSP directly into the server configuration.
If you want to check whether your browser supports the Content Security Policy, you can use the CSP browser test. This test attempts to load scripts and images from unknown (harmless) sources and tells you if this was successful.
In terms of the Content Security Policy and preventing cross-site scripting, website operators should store all scripts in separate files instead of embedding them directly in the website’s source code. The CSP then works in a similar way to a whitelist: in the header, the sources, from which scripts and data can be loaded, are named. If an unknown script has slid undetected into the HTML code of the page and is now trying to load external data, the user’s browser needs to prohibit this. By default, the CSP blocks all scripts that can be found directly in the code (inline scripts). This protects both the website and the internet user as well as any sensitive data.
Cross-site scripting is relatively easy for cyber criminals to manipulate. Almost every website has an input field i.e. comment function, search bar, or log-in field. Instead of simple text, it’s possible to also enter scripts. If the server is not adequately secured, criminals can implement phishing interfaces, bringing the entire website to a standstill or gaining control of the user’s web browser using malicious software. CSP (or to be more precise: the corresponding header field) tells the web browser which sources it is permitted to load data from. If the policy is implemented in the website’s code, attempting to retrieve XSS-implemented code will be met with an error message.
The Content Security Policy also enables website operators to change many other settings. This can be done through these directives:
These directives only apply if they are explicitly set. Otherwise, they are open by default and therefore pose a security risk. However, this can be changed using default-src: you can set the default state of all directives ending with -src. For example, instead of leaving it open, you can specify that only data from your own website may be loaded unless you have specified otherwise in the HTTP header of the individual web page. In separate directives, you add additional sources.
You can enter any number of directives into the header field. If you want to include several directives, separate them with semicolons. In addition, you as the website operator must specify all sources within a directive. Multiple entries of the same directive with additional sources are not permitted (such as in the following example):
script-src example1.local; script-src example2.localIn this case, only the first source is relevant, the second one is ignored by the client. Instead, you must record both sources in one directive:
script-src example1.local example2.localIf you do not need certain types of content for a page or the entire website, you can enter the value 'none' in the header – so you can specify that no sources may be loaded at all. You can also use the value 'self' – this means that the browser can only load content from the same source. Both values must always be quoted in single quotation marks, otherwise none and self will be interpreted as domains.
There are different header options for defining a Content Security Policy:
Not all browsers support every term. However, the W3C (the body responsible for defining web standards) suggests Content Security Policy. Therefore, all modern browsers have adapted to this security standard in the meantime (the other two versions are considered obsolete). To make sure that you reach as many internet users as possible (even those with out-of-date browsers) with your CSP, it is advisable to include all header fields. If a corresponding web browser can’t handle the Content Security Policy header, it will simply ignore it and display the website without any problems – however, additional protection isn’t given to the affected users.
Usually, you will set HTTP headers across your entire domain. For sub-directories, you can use the .htaccess file. You then use the CSP security standard to set special rules for individual subpages. For example, if you have implemented a social media button on one page, but not on the next one, it makes sense to only allow access to the external source on the first page.
Sources can be entered as addresses, in their own way or as wildcards. The following entries are therefore allowed:
A Content Security Policy basically stipulates that scripts may only be loaded from files, not directly from the website code. If you want to bypass this, you can use the command script-src 'unsafe-inline'. However, you should be aware that you are weakening security. The safety standard also prohibits the eval () feature. This command can be used to convert text into JavaScript code – but this can also pose a security risk. If you still need this function, you can reactivate it with script-src 'unsafe-eval'.
you can secure unsafe-inline using a detour. Hash values or nonce source close this vulnerability as much as possible.
If scripts are no longer allowed to appear directly in the code, you must create a separate file for each script. The script’s function is stored in a .js File. The website’s code only refers to these:
<script src='example.js'></script>What the script does in the end is described in the example.js. You must also store style elements in separate stylesheets. If you want to implement an internet security policy as a website operator, it is not enough to simply insert the header. You also need to check and customize your website’s source code.
do you want to know how secure your own website is? Mozilla has provided an easy-to-use test: Observatory by Mozilla scans your website and gives you a grade after it’s completed, and tells you how to make your site safer
As an example, we now show you how to implement a Content Security Policy header and explain what can be achieved with it.
You can see that every CSP variant appears in the header so that as many different browsers as possible can be addressed. Inside each header name, the content is identical: sources are listed one after the other, and the directives are separated by a semicolon. The syntax is always the same. In fact, only the name of the field changes, so you can easily duplicate the content.
First, we determine that, unless otherwise specified in a directive, data should not be loaded from just any source (default-src). This makes things a little bit safer. You should always define default-src first. This will prevent a potentially forgotten directive from leaving a gap in your Content Security Policy.
Next, we define the source from which scripts can be loaded (script-src). In the example, we determine that the browser only loads scripts from the same source and from example.com including all subdomains (you assign the wildcard using *). Furthermore, we determine that clients are only allowed to load stylesheets from their own sources (style-src). Images are only allowed from their own source as a data URL (img-src). According to our Content Security Policy header, fonts may only be downloaded from Google’s own sources. In the example, we specify a location to which notifications are sent if someone attempts to violate the security standard (report-uri).
You might have noticed that we haven’t included all the directives in the header. This doesn’t cause any problems: In this case, we don’t need any more whitelists, and the default src turns off all other sources.
several Content Security Policy generators are available on the internet. With offers such as CSP Is Awesome or Report URI, you can create CSP header fields easily and reliably.
Have you ever heard of cross-site scripting (XSS)? This is when unauthorized users take advantage of security gaps in internet browsers and on web servers to plant malware and run it anonymously. But what lies behind these attacks and how can website operators and users protect themselves?
Would you leave your window open at night if you knew there were intruders lurking about? Obviously the answer to this question is ‘no’. Many companies and individuals leave their virtual window open to cyber criminals by not adequately protecting their websites. Website security is an extremely important topic. Only by regularly carrying out security checks and following the proper precautions...
The same-origin policy (SOP) prevents client-side scripting languages, such as JavaScript, from accessing objects located on another URL that are not part of the running internet application. A convenient way to perform this cross-domain query regardless is through the JSON application JSONP. We explain what exactly this involves and how this method works.
You access a website and, in the background without your knowledge, content is loaded from a third-party server. This is a security risk and is rightly prevented by the same-origin policy (SOP). But what do you do if you need the connection to both servers? Cross-origin resource sharing (CORS) provides secure technology for creating exceptions.
Provide powerful and reliable service to your clients with a web hosting package from IONOS.
View packages