Content Security Policy (CSP) is a browser security control that websites can voluntarily adopt by sending a 

The basic principle of CSP is to enhance the security of a website by restricting what can happen on the site and from where resources such as scripts can be loaded.

CSP is essentially an implementation of the principle of least privilege on the client side, meaning that the website is only given the necessary privileges. This way, in the event of an attack, the attacker will have limited privileges to cause damage.

At the bottom of the page, there are ten labs where you can practice using CSP in different practical situations!

CSP is primarily an effective protection against 

, although for CSP to provide effective protection, it must be implemented correctly.

In addition, CSP can protect against other attacks similar to XSS, in which attempts are made to load styles (CSS) that do not belong to the web application.

Finally, with CSP it is possible to protect against some framing attacks (such as clickjacking) by limiting which (if any) external sites are allowed to frame the page (e.g. using the IFRAME element).

However, XSS protection is the main purpose of CSP.

What are XSS (Cross-Site Scripting) attacks then?

XSS refers to vulnerabilities that allow an attacker to make malicious changes to code executed by a browser in an application. This vulnerability is covered more extensively in Hakatemian's 

Assume that the website has such search functionality:

The functionality is vulnerable to XSS attacks because the application builds HTML in an insecure manner. The URL parameter 

 is directly inserted into the HTML string, allowing the manipulation of the HTML structure.

An attacker can exploit the vulnerability by constructing the following types of links in the application:

When the victim opens the link, the application insecurely constructs an HTML response and sends it to the victim's browser as follows:

, the attacker would, of course, do something else such as stealing user information or performing unwanted actions in the application.

XSS vulnerability

How does CSP protect against XSS vulnerabilities in practice?

Consider Hakatemian's website as a practical example. Load the page and simulate an attack by adding 

 to the HTTP response using the Burp Suite tool.

"XSS" alert window does not appear. Why? The answer can be found in the browser console. Hackademy's CSP prevents the attack because it does not allow inline scripts like this.

In practice, CSP works so that the web server returns in its HTTP response (in the 

 header) a policy that defines, for example, what kind of resources the site is allowed to load or execute.

The browser then interprets this policy whenever a supported CSP function occurs on your website, and either allows it or denies it. If denied, a red error message will appear in the browser console, as well as a report to your CSP report handler if you have enabled one with the 

. In the example above, there are two directives: Script restriction (

The directives are separated by a semicolon (;) and include sources from which the specific resource can be downloaded.

Each resource that CSP can restrict has its own directive.

, the resource is not restricted in any way. This is the default state for all web pages.

, the resource is initially completely blocked and only the sources listed in the directive are allowed.

 directives will take their value from it if they are not set directly.

Certain sources listed in the directives override other sources.

 keyword and URL-based allowances. We will come back to what these mean a little later.

Restricting execution of JavaScript code on a page

The most important task of CSP is undoubtedly to restrict the execution of JavaScript code on a website. The purpose is relatively simple: Allow all JavaScript that is intended to be executed on the site and block everything else.

Implementation can be either easy or it may require some tinkering and modifications to the protected application.

Understanding the different directives of CSP and their effects on each other is essential for creating an effective CSP.

Next, let's see how script restriction is typically done.

Start by either completely blocking scripts or allowing them only from your own domain

If your application downloads scripts from its own server (like most applications do), you can allow it as follows:

If your application does not load scripts from your own server at all, you can block scripts completely by default.

 (without quotes) means a URL that starts with the word "none".

If you want to allow a specific script from the internet or perhaps all scripts from a specific address, you can do so with URL-based whitelisting. Note that 'wildcards' are not used in URL-based whitelisting.

Allowing a specific script from https://cdn.example.com address

Allowing all scripts from https://cdn.example.com address

If your application uses inline scripts and you cannot or do not want to get rid of them, CSP offers two completely insecure and two reasonably secure ways to allow them.

Inline scripts, in the context of CSP, practically refer to anything that an attacker could inject into HTML that would directly execute a script.

The most common example of an inline script is a script tag that contains JavaScript code:

CSP considers inline scripts as well as a wide range of other XSS vectors such as JavaScript event handlers (

Be careful not to totally omit the script-src restriction.

 which, as the name implies, allows insecure inline scripts and renders the entire CSP useless.

 keyword is that its usage is not actually always wrong but it is an important part of compatibility with older browsers, but we will come back to this later.

: Inline scripts are allowed, for example based on the SHA256 hash of the script's content.

: Inline script (or even external script) is allowed to be re-generated on each page load based on a randomly generated value provided as an attribute to script tags. This dynamic approach requires a specific kind of traditional shaped web application where HTML is built on the server side for each page load.

Allowing inline script, for example with SHA256 hash, is fairly simple. Just return the following keyword in the script-src directive:

But how do you get the Base64 value from the content of the script SHA256 hash? The easiest way is to let Google Chrome browser do the work for you. Follow these steps:

Set (in your local development environment) a CSP header that completely blocks inline scripts, for example 

Make sure that the script you want to allow is on the website.

Download the page in Google Chrome browser. The script does not execute because CSP blocks it. Now open the console and find the CSP error message that blocked the script. The error message includes a precalculated Base64-SHA256 of the script that you can add 

The images are from an exercise found at the bottom of the page.

Important notice about seals and backward compatibility

automatically loses power. In other words, the keyword 

. This is important because very old browsers do not support the 

 keyword, so it is recommended to also add 

 if you use hashes to prevent the website from breaking on old browsers.

Allowing inline scripts with a random identifier (nonce)

Oletetaan, että sivustolla on tällainen hakutoiminnallisuus: 

```php
echo "<p>Search results for: " . $_GET('search') . "</p>"
```



Toiminnallisuus on haavoittuva XSS-hyökkäyksille koska sovellus rakentaa HTML:ää turvattomasti. Url-parametri **search** asetetaan suoraan osaksi HTML-merkkijonoa, jolloin pääsee muuttamaan HTML:n rakennetta.

Hyökkääjän on mahdollista hyödyntää haavoittuvuutta rakentamalla sovellukseen seuraavanlaisia linkkejä: 

```html
https://www.example.com/?search=<script>alert('XSS')</script>
```



Kun uhrin avaa linkin, sovellus rakentaa turvattomasti HTML-vastauksen joka lähetetään uhrin selaimeen seuraavanlaisena: 

```html
<p>
  Search results for:
  <script>
    alert('XSS')
  </script>
</p>
```

Koodin **alert('XSS')** sijasta hyökkääjä toki tekisi jotain muuta kuten varastaisi käyttäjän tietoja tai suorittaisi sovelluksessa ei-haluttuja toimintoja.

XSS-haavoittuvuus

Sinulla on tällainen nappi etkä voi tai halua refaktoroida sitä muotoon jossa inline-tapahtumankäsittelijää ei tarvittaisi.

```html
 <button onclick="alert('Hello!')">
```

Sen sijaan, että vähentäisit merkittävästi turvallisuutta lisäämällä **'unsafe-inline' **avainsanan **script-src** -direktiiviin,  voit käyttää **'unsafe-hashes'** avainsanaa yhdessä tiivisteen kanssa joka sallii funktion, seuraavasti:

```yaml
script-src 'unsafe-hashes' 'sha256-0KAUGUNSAE9SmnRfyY+2MhbftgtqjBwh4sNjtk8aJKM='
```



Tiivisteen saat vaikka [report-uri ](https://report-uri.com/home/hash)palvelusta.

![](sanity:image-d1b5c745c0a344751bac993a04fe12c4afa7482f-1408x496-png)

'unsafe-hashes'

Oletetaan että meillä on GTM (Google Tag Manager) käytössä ja tarkoitus on antaa kaikkien GTM:n sivulle lataamien skriptien suorittua.

Aloitetaan lisäämällä GTM-skripti sivulle.

```html

<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;var n=d.querySelector('[nonce]');
n&&j.setAttribute('nonce',n.nonce||n.getAttribute('nonce'));f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXX');</script>

```



Avataan sitten sivu, katsotaan tiiviste Google Chrome -selaimen konsoliin ilmestyneestä herjasta ja sallitaan skripti sitten **script-src** -direktiivissä. Nyt skripti suoriutuu mutta se ei vielä saa ladata sivulle lisää skriptejä.

Tätä varten lisätään script-src -direktiiviin myös **'strict-dynamic' **-avainsana. Nyt valmiiksi luotettu skripti saa ladata vapaasti lisää skriptejä sivulle.

GTM tarvitsee myös **'unsafe-eval'** avainsanan toimiakseen.

Lopuksi lisätään **'unsafe-inline' **ja **https:** jotta sivusto toimisi edelleen myös hyvin vanhoilla selaimilla.

```yaml
script-src 'sha256-abcdefg' 'strict-dynamic' 'unsafe-inline' 'unsafe-eval' https:
```

GTM-salliminen tiivisteellä ja 'strict-dynamic' avainsanalla

Oletetaan että haluat ladata tyylejä omasta alkuperästä sekä https://cdn.example.com osoitteesta, voisit tehdä seuraavanlaisen politiikan.

```yaml
style-src 'self' https://cdn.example.com/
```

style-src

Oh no! Someone has hacked the website and added a malicious script to the page. Can you fix the CSP to prevent the script from running and still keep the rest of the website operational? While you are at it, prevent the dog image from showing but keep the cat.

CSP Challenge - Level 1

Oh no! Someone has hacked the website and added a malicious script to the page. Can you fix the CSP to prevent the script from running, still allowing the legitimate inline script to execute?

CSP Challenge - Level 2

Oh no! Someone has hacked the website and added three malicious scripts on the page, one inline, one from the Internet and one from the application's own domain! Can you fix the CSP to prevent the evil scripts from running and still keep the rest of the website operational? Most importantly let's pretend you don't really know what scripts the legit inline script will load (as is often the case with third-party scripts, think Google Tag Manager) so it should be able to load any other script.

CSP Challenge - Level 3

Oh no! You sent the CSP header you built in level 3 to the QA team and they said it broke the website for old browsers completely! Can you fix the CSP by adding fallbacks for old browsers?

CSP Challenge - Level 4

Oh no! Someone has hacked the website and injected a fake login form to the page. It sends the user's credentials to the attacker's server. Can you fix the CSP to prevent the form from being submitted.

CSP Challenge - Level 5

Oh no! Someone has hacked the website and injected a base tag to the page. It changes the base URL of the page, redirecting all links to the attacker's page. Can you fix the CSP to prevent the base tag from being applied? While you are at it, prevent frames from external sources and legacy HTML elements such as embed or object from being used on the page. You may have some problems even submitting the update CSP form because of the rogue base tag, perhaps you should use the browser's developer tools to remove the base tag from the page first?

CSP Challenge - Level 6

Oh no! Someone has hacked the website and injected a CSS file that makes everything look like a 90s website. Can you fix the CSP to prevent the CSS file from being loaded?

CSP Challenge - Level 7

Oh no! Someone has hacked the website and injected a library card skimming script to the page that sends your customer's library card information to the atacker's server. Can you fix the CSP to prevent the HTTP connection to the attacker's server from being established?

CSP Challenge - Level 8

Oh no! The security team has informed you that the website is vulnerable to clickjacking. Can you fix the CSP to prevent the website from being loaded in an iframe?

CSP Challenge - Level 9

The final challenge. You get hired by a company to implement a strict, backwards compatible CSP on their website. Can you do it?

CSP Challenge - Level 10

Content Security Policy (CSP)

The browser is a versatile environment, with code from completely different parties running in different tabs and windows, and these web applications are still able to communicate with each other. Such an environment has its risks!

The browser is a versatile environment where code from different sources is running in different tabs and windows, and these web applications are able to communicate with each other. There are risks in such an environment!

Let's go through browser-side attacks and, above all, defense mechanisms in the course.

Content Security Policy (CSP)

What is CSP?

Learn to hack — start here