Websites are unfortunately prone to security risks. Thus, you have to stay concerned about its security. To make it not to get attacked, you must provide continues security to your site.
Maintaining security also means utilizing the proper security controls that best help address the dangers related to your site.
Although, there are various factors are involved when it comes to security. HTTP security headers are one of them. They offer another layer of security by helping to mitigate attacks and security vulnerabilities.
What are HTTP Security Headers?
The term is introduced in order to help to enhance the security of a website. When a user tries to access a page, his browser requests it from a web server. The server then responds with the content along with appropriate HTTP Response Headers which contain metadata, status error codes, cache rules and so on.
Moreover, the HTTP Security Headers instructs the browser on How to behave amid managing site’s content.
There are six different HTTP security headers and Content Security policy is one among them.
What is Content Security Policy?
As I mentioned above, it provides additional security layer by preventing attacks such as Cross Site Scripting (XSS) and other code injection attacks. It does this by defining content sources which are approved and ask the browser to load them.
Although CSP is complex in nature, and it can get messy if not deployed appropriately, a well-applied CSP can drastically decrease the chances of exploitation of most forms of cross-site scripting attacks.
All major browsers currently offer full or partial support for content security policy. In case, if a user accessing your site via an older browser, it won’t break delivery of the content if it does happen to be delivered to an older browser, it will simply not be executed.
CSP works with directives that can be used when creating your content security policy depending on what you want to achieve. There are multiple directives available to website owners who want to implement a content security policy. They are as follows:
- default-src: Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),
- script-src: Define which scripts the protected resource can execute,
- object-src: Define from where the protected resource can load plugins,
- style-src: Define which styles (CSS) the user applies to the protected resource,
- img-src: Define from where the protected resource can load images,
- media-src: Define from where the protected resource can load video and audio,
- frame-src: Define from where the protected resource can embed frames,
- frame-ancestors : Specifies valid parents that may embed a page using <frame>, <iframe>, <object>, <embed>, or <applet>.
- font-src: Define from where the protected resource can load fonts,
- connect-src: Define which URIs the protected resource can load using script interfaces,
- form-action: Define which URIs can be used as the action of HTML form elements,
- sandbox: Specifies an HTML sandbox policy that the user agent applies to the protected resource,
- script-nonce: Define script execution by requiring the presence of the specified nonce on script elements,
- plugin-types: Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,
- reflected-xss: Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,
- report-uri: specifies a URI to which the user agent sends reports about policy violation
Creating Content Security Policy:
Along with directives mentioned above, you can create configure a content security policy on your web server. Its syntax is as follows:
Content-Security-Policy: policy
Below, I will show you, how you can create CSP to load a resource from any origin using https://.
Content-Security-Policy: default-src https:
In above example, we used the directory named default-src that allows you create a policy for all resources type in case of a resource type dedicated directive is not defined.
Testing CSP:
For testing purposes, instead of defining your CSP as Content-Security-Policy: you may use Content-Security-Policy-Report-Only: instead. This will not enforce the policy rules on the web page but rather will simply provide you with feedback as to how the policy will react.
For Nginx, Place the following snippet in the configuration file:
add_header Content-Security-Policy-Report-Only: "default-src 'none'; script-src http://cdn.infophilic.com";
For Apache:
Header set Content-Security-Policy-Report-Only "default-src 'none'; script-src http://cdn.infophilic.com;"
Once this content security policy has been set, open your browser’s search console. You will find the feedback based on the directives set.
Now, your site will be less vulnerable to attacks. In order to keep track on any activity that is in violation of the content security policy, you can use report-URI directive. Using this directive, the browser will post a JSON formatted report to the defined URL of your choice. This directive can be appended to the end of your CSP.
Conclusion:
Having a CSP in place is an easy way to further increase the security of your website. Hope this guide successfully help you understand the use of CSP as a security layer.
 and other code injection attacks. Having a CSP in place is an easy way to further increase the security of your website.){kind=link}