Content Security Policy (CSP)


 Trust is the fundamental key to the Internet. You trust your internet service provider to keep your connection up-to-date. It is important to your developers that you trust the architecture provider when they say that your servers will remain available and that customers trust that you’re safely securing their data. Additionally, they trust that what they see on your website is what you intend for them to see.

The most common attacks people face in a web application are Cross-site scripting, Clickjacking, and some injection attacks. So, an Internet Service Provider is responsible for providing them security. There is a Policy that helps secure your application from these types of attacks. That policy is called Content-Security-Policy.

In this article, we will discuss Content-Security-Policy (CSP). Before we start, Let's talk about ‘Cross-Site-Scripting' attacks. 

What is Cross-Site-Scripting?

Cross-Site-Scripting (XSS) is an Injection attack in which an advisor (attacker) can inject a malicious payload or code and gain user credentials, important data, cookies, tokens, etc.

Cross-Site-Scripting attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end-user.

Scenario 1:

“Now the main thing is how to protect your application from XSS attacks.”


So, if you want to protect your application from XSS attacks, you must know about Content-Security-Policy (CSP).

What is Content-Security-Policy?

    Content Security Policy is the most powerful browser security feature to prevent Cross-Site-Scripting, Clickjacking and some Injection attacks. It can use the X-Frame-Options of the security header or Meta tag to prevent Cross-Site-Scripting (XSS).

  A Content Security Policy mostly restricts the sources and types of content and where on the page that content can be presented, or rendered. In terms of preventing Cross-Site-Scripting, "inline JavaScript" tends to be the first vector for malicious content. Basically, Inline JavaScript is when code is placed in a "<script>", "eval()", "<img>", "<svg>" tag in the body of the HTML document. In addition, preventing inline JavaScript will also stop code from executing on event listeners such as "onClick" or "onHover" attributes, which are common vectors for XSS. Typically speaking, it is bad practice to use inline JavaScript - Using a CSP to prevent inline JavaScript from executing is not only a great security feature, but it also enforces good code hygiene.

How to use Content-Security-Policy?

Content-Security-Policy acts as a Rakshak (Protector) against Cross-Site-Scripting and injection attacks.

Every developer and researcher should be aware of CSP. Let’s look at ‘how CSP can be used as a Rakshak?’

In addition to helping and caring for his soldier, Rakshak also knows how to manage him. Similarly, we must be able to configure a Content-Security-Policy clearly. CSP cannot protect Web Applications if there is any misconfiguration. And now directives are like soldiers. So, how should you manage your soldiers or directives? It's totally up to you.

  👉Mostly usable CSP directives and their usage:

Content-Security-Policy provides a wide range of directives, each one specific to a content type. As part of the content security policy, the following directives are provided:













Before moving into the directives, here are a few basic keywords that are used in CSP directive values:

* (asterisk): Allow anything

none: Won't allow loading of any resources

self: Only allow resources from the current origin

unsafe-inline: Allow use of inline resources

unsafe-eval: Allow use of dynamic code evaluation

https:  Allow resources only over HTTPS

Syntax of Content-Security-Policy:

  👉 Content-Security-Policy Header

Content-Security-Policy: <policy-directive>; <policy-directive>

 👉 Content-Security-Policy Meta Tag

<meta http-equiv=“Content-Security-Policy” content=“<policy-directive>” />

Where <policy-directive> consists of: <directive> <value> with no internal punctuation.


Now let's examine each of the content security policy directives with examples:


default-src :

The default-src directive defines the default policy for fetching resources such as JavaScript, images, frames, CSS, AJAX requests, Fonts and HTML5 Media. Always remember that the default-src directive is not applicable to all directives.

Example of default-src Policy:

default-src 'self';


img-src :

The img-src directive defines a valid source of images.

Example of img-src Policy:

img-src 'self';


connect-src :

The connect-src applies to XMLHttpRequest (AJAX), WebSocket, fetch(), <a ping> or Event Source. The browser emulates a 400 HTTP status code if it is not allowed.

Example of connect-src Policy:

connect-src 'self';


media-src :

The media-src defines a valid source of audio and video, (e.g., HTML5 <audio>, <video> elements).

Example of media-src Policy:



frame-src :

The frame-src defines valid sources for loading frames. In CSP Level 2 frame-src was deprecated in favor of the child-src directive. CSP Level 3, has undeprecated frame-src and it will continue to defer to child-src if not present.

Example of frame-src Policy:

frame-src 'self';


object-src :

The object-src defines valid sources of plugins, e.g., <object>, <embed> or <applet>.

Example of object-src Policy:

object-src 'self';


script-src :

The script-src defines a valid source of JavaScript.

Example of script-src Policy:

script-src 'self';



The frame-ancestors defines valid sources for embedding the resource using <frame> <iframe> <object> <embed> <applet>. Setting this directive to 'none' should be roughly equivalent to X-Frame-Options: DENY

Example of frame-ancestors Policy:

frame-ancestors 'none';



Enables a sandbox for the requested resource similar to the iframe sandbox attribute. The sandbox applies a same origin policy, prevents popups, plugins and script execution is blocked. You can keep the sandbox value empty to keep all restrictions in place, or add values: allow-forms, allow-same-origin, allow-scripts, allow-popups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox, and allow-top-navigation.

Example of sandbox Policy:

sandbox allow-forms allow-scripts;



The child-src defines valid sources for web workers and nested browsing contexts loaded using elements such as <frame> and <iframe>

Example of child-src Policy:

child-src 'self'



The style-src defines valid sources of stylesheets or CSS.

Example of style-src Policy”:

style-src 'self';

Scenario 2:

Using Multiple Content-Security-Policies:

     It is possible to specify multiple policies for a resource using the Content-Security-Policy header, the Content-Security-Policy-Report-Only header, and the <meta> element.

So, you can use the Content-Security-Policy header more than once. Using multiple Content-Security-Policies results in better security for the web application.


Content-Security-Policy: default-src 'self';
                          connect-src 'none';

Content-Security-Policy: connect-src;



    Content security policy is one of the best features to prevent Cross-Site-Scripting attacks, when used correctly. It is important to develop a strategy that will be effective when implementing your CSP. By doing so, you will be able to control which scripts are allowed in your applications more strictly. The styles used in applications are the same.

   Using a CSP that is supported by a wide range of browsers would be a great advantage. Chrome supports all CSPs. With a CSP, you will be able to keep converting scripts so that your website will be secure. You can generate an automatic content Content-Security-Policy from



Contributed by Manab Jyoti Dowarah

Post a Comment