I have talked a lot about Same Origin Policy in one of my post on “Same Origin Policy”. Same Origin Policy prevents my kinds of attacks and provides a secure environment for web developers to build web applications. But in that post I also explained some ways by which we can bypass same origin policy. So we can say the same origin policy provided by the browser is not enough to prevent XSS attacks. In this post we will look at Content Security Policy which can block XSS attacks and provide more security layer to Same Origin Policy.
What is Content Security Policy(CSP)?
Sources information can be provided to browser via HTTP response header or meta tags.
Passing sources list via HTTP Header
We can provide source list to browser via the above headers. For compatible in all browser we can use Content-Security-Policy and X-Content-Security-Policy together.
In meta tag attribute http-equiv we can assign the header name and assign content attribute to header value.
We need to assign CSP header a list of directive and associated a directive value. Directive represent content type and its value represents trusted source.
These are the directives for CSP:
- default-src: Sources for all types of content
- style-src: Sources for stylesheets
- img-src: Sources of images
- connect-src: Sources for XMLHttpRequest, WebSocket and EventSource
- font-src: Sources for fonts
- object-src: Sources for <object>, <embed> and <applet>
- media-src: Sources for <audio> and <video>
- frame-src: Sources for frames
- sandbox: Browser treats the page like it is loaded inside a sandboxed iFrame. To learn more about sandboxed iFrame follow this links Link1 Link2
- report-uri: Browser posts a report on policy failures to specified URL. We can also append “-Report-Only” to the CSP header to not block anything just send reports.
All those attributes that end with -src support values called as source list values.
- * -> Wildcard, allows everything.
- ‘none’ -> Prevents loading resources from any source.
- ‘self’ -> Allows loading resources from the same origin (same scheme, host and port).
- data: -> Allows loading resources via the data scheme (example: Base64 encoded images).
- domain.example.com -> Allows loading resources from the specified domain.
- *.example.com -> Allows loading resources from any subdomain under example.com
- https://my.example.com -> Allows loading resources only over HTTPS matching the given domain.
- https: -> Allows loading resources only over HTTPS on any domain.
- ‘unsafe-eval’ -> Allows use of dynamic code evaluation.
For sandbox directive we can pass the following values:
- allow-forms -> This allows submission of forms in the page.
- allow-top-navigation -> Allows use of window.top.location and target=”_top”. Without this value there will be no effect.
- allow-scripts -> Allows script execution.
- allow-popups -> Sandboxed document will create new window or dialogs when window.open and target=”_blank” is used. This value allows creation of new windows and dialogs.
‘unsafe-inline’ and ‘unsafe-eval’ values
Dynamic code evaluation comprises of use of eval() function and string arguments for both setTimeout and setInterval. Thus restriction can be bypassed by assigning script-src attribute to unsafe-eval.
Points to remember
Multiple values can be space separated.
* and ‘none’ cannot be used with any other values.
‘self’, ‘none’, ‘unsafe-inline’ and ‘unsafe-eval’ needs to be put inside single quotes.
If the page is loaded inside an iFrame or not but you want to make it sandboxed and also allow form submission and data access. Then,
For development purpose you might not want to want to block anything but only get reports on possible blocks. Than
You want to block and also get reports then:
CSP provides the best XSS protection. I tried to cover all possible directives and values related to CSP. You can try playing around with it. And also I recommend you to use CSP to protect your websites.