“Content Security Policy” is a declarative policy that allows the application developers to inform the client about the sources from which the application can load the resources. Content security policy does not help as a first line of defense against code injection attacks, but it can be best used as defense-in-depth to reduce the harm caused by such attacks. To take advantage of this policy, the application developers need to make use of “Content-Security-Policy” HTTP header. Background: Content security policy header was originally developed by Mozilla Foundation. Experimental implementations of this header in various browsers was done by names like X-Webkit-CSP in chrome , X-Content-Security-Policy in browsers like Mozilla, SeaMonkey, etc. “Content-Security-Policy” is the standard header name proposed by the W3C document. Workings of the CSP header: The content-security-policy header is sent in the server response. On encountering this header in the response, the client judges from where or from where not the content should be loaded in that page. This is done by the browser by using the directives and the values present in the CSP response header. CSP header is applicable per page. Hence, it is advised to add this header for every response. CSP directives and their usage: CSP provides a wide range of directives each one specific for a content type. The directives provided by content security policy are as follows: script-src connect-src frame-src Child-src frame-ancestors img-src media-src object-src style-src sandbox default-src Before getting into the directives, let us look at few basic keywords that are used as part of CSP directive values. – * (asterisk) – allow anything – none : matches nothing. – self: matches the current origin, but not its subdomains. – https: allow resources only over HTTPS – unsafe-inline: allows inline JavaScript and CSS – unsafe-eval: allows text-to-JavaScript mechanisms like eval Now, let us look into each of the content security policy directives with related examples – Script –Src: Script-src is a directive that controls a set of script-related privileges for a specific page. It restricts which scripts the protected resource can execute and controls other resources, such as XSLT style sheets, which can cause the user agent to execute the scripts. Grammar: Content-Security-Policy: script-src directive value; A probable example could be as follows – Content – Security – Policy: script-src ‘self’; This type of header would restrict scripts being executed from different domains. Only the scripts that belong to the same domain as the domain of the page will be executed. Similarly, we can have script – src value set to other directive values as follows – -> Content – Security – Policy: script-src www.abc.com; Such a setting would allow scripts to get executed only when they belong to the domain specified. Here in this example, the script belonging to the “abc.com” domain would be executed. -> Content – Security – Policy: script-src ‘unsafe-inline’; This would allow all the inline scripts present on the page to be executed by the browser. -> Content – Security – Policy: script-src ‘unsafe-eval’; With this directive value set, the browser would allow all the eval functions to be executed without any restriction. One can always set multiple directive values to a directive. Example- Content – Security – Policy: script-src ‘self’, https://www.xyz.com; In the above example, we have specified self and xyz.com domain as valid sources of scripts. Therefore, the browser would interpret this and allow execution of scripts to be executed only if they belong to same domain or xyz.com domain. In case there is some script that is interpreted to be from an invalid source according to the browser, the browser would display an error message as follows – Refused to load the script ‘script-uri’ because it violates the following Content Security Policy directive: “CSP directive set by you“. This error message may vary according to the browser. Connect – Src: This directive defines valid sources for fetching the XMLHttpRequest, WebSocket, and EventSource connections. These connections may be to external server to send/receive information, eventSource open HTTP connections to a server for receiving push notifications, WebSockets for communication between and a server, and XMLHttpRequests to make arbitrary HTTP requests on your behalf. The connect-src directive allows you to ensure that these sorts of connections are only opened to origins you trust. In case the connect-src is absent, then the browser looks for default-src or it will take the default value to be * and will fetch all the connections. Grammar: Content – Security – Policy : connect-src directive value; An example could be- Content – Security – Policy: connect-src ‘self’ , www.xyz.com; The above setting of the connect-src directive would allow the connections only from same domain or the xyz.com domain. Frame-src: Frame-src restricts the sources from where a resource can be embedded into the frame. It decides the valid sources of content for nested contexts, web workers. Grammar: Content – Security – Policy: frame-src value; Example: Content – Security – Policy : frame-src www.test.com; This would instruct a browser that the content in a frame can be loaded only from test.com domain. The Frame-src directive is now deprecated and most of the browsers are not implementing it now a days. Instead of this, child –src is being implemented. Child –Src also does the same work as the frame-src directive. The grammar is also same as the frame-src directive. Frame-ancestors: This directive specifies valid parents that may embed a page using the and