Table of Contents
Web Backend Security Headers
Background
Content Security Policy (CSP) is a security standard introduced to prevent cross-site scripting, clickjacking and other code injection attacks. It is widely supported by modern browsers.
Usage
The response header is provided with the following attribute:
Content-Security-Policy
This header name is supported by recent versions of Google Chrome, Firefox, and other Chromium-based browsers. Internet Explorer 10 and 11 can also support CSP, but it would need to use the experimental header X-Content-Security-Policy.
How it works
When a client (i.e. a browser) sees the Content-Security-Policy header, the client enforces a whitelist policy.
Depending on the policy, the following things can be disabled:
- Inline Javascript code
- Inline CSS statements
- Dynamic Javascript code evaluation (i.e.
eval()) - Dynamic CSS statemenets (i.e.
CSSStyleSheet.insertRule())
The features above are considered bad practice in general, so this is incredibly useful to have to ensure malicious attacks are guarded against. Do note that, large scale applications migrating to the usage of CSP may need to tweak the policy or relax the policy to retain its current functionality - a large refactor may be needed.
Source of Usage
Web application frameworks such as React or AngularJS can support CSP, however it is only needed if CSP contents somehow depend on the web application's state. In normal circumstances, CSP would be set in the response header from a load balancer or web application server. Setting this header on a load balancer is relatively straightforward, while for web application servers, it depends on the web framework. For example, if the web server is spun up with Django, you can have a middleware to add CSP to the response headers.
Coming up next
We will go over CSRF Headers next to address one of the most popular vulnerabilities: cross-site script attacks.