Cybersecurity until recently has been a very underground topic. Most people took it for granted, but as we see a rise in website production, many are starting to realize it is something we should consider before banging our chests impenetrable. Following the vibe of the National Cybersecurity Month, October, which we have an extensive take on, this post, part of our Security series, is aimed to bring attention to a new feature which will surely be of great benefit in the upcoming years.
Review our Serie 1 → Security Hardening Essentials to Keep Your Site Safe
The browser is the universal tool which we all use in order to access every chunk of data on the Internet. As advanced and yet comprehensible to the masses as it is, it also holds within itself the possibility of potential security flaws. Depending on the browser you are using and its version, certain things on the same website will load in different ways.
An example of this can be seen in the linking of external stylesheets (CSS). We use them in order to align certain texts, create margins and gain an overall better look for our websites. However, if this external information does not come from a trusted source, it may be used to display content on your website which is outside of the limitations of what you would like it to perform.
Ready for the Impact
Here is where the Content Security Policy (CSP) comes into play. According to W3’s website, Content Security Policy (CSP) is:
A tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
Distributed via the HTTP header, similar to HSTS or HTML meta tags, this security protocol acts as a barrier between proper usage and external implementation with malicious intents, by mapping resources prior to them being loaded on the website. This means that even in the case of a successful injection of malicious code, the Content Security Policy would be triggered and the attack will be mitigated.
CSP works with a handful of directives, which are basically the options which let you configure which types of information will be let to reach your website. The official rulesets are:
style-src – Defines valid sources of stylesheets.
- img-src – Defines valid sources of images.
- connect-src – Applies to XMLHttpRequest (AJAX), WebSocket or EventSource. If not allowed the browser emulates a 400 HTTP status code.
- font-src – Defines valid sources of fonts.
- object-src – Defines valid sources of plugins, eg
- media-src – Defines valid sources of audio and video, eg HTML5
- frame-src – Defines valid sources for loading frames. child-src is preferred over this deprecated directive.
- report-uri – Instructs the browser to POST reports of policy failures to this URI. You can also append -Report-Only to the HTTP header name to instruct the browser to only send reports (does not block anything).
- child-src – Defines valid sources for web workers and nested browsing contexts loaded using elements such as
- form-action – Defines valid sources that can be used as a HTML
- frame-ancestors – Defines valid sources for embedding the resource using
<applet>. Setting this directive to ‘none’ should be roughly equivalent to X-Frame-Options: DENY
- plugin-types – Defines valid MIME types for plugins invoked via
<embed>. To load an
<applet>you must specify application/x-java-applet.
Using the above, you can configure your website to allow/restrict content such as:
- Stylesheets (CSS)
- Forms (Text submission fields such as user/password logins)
- Embedded fonts (.woff2 / .ttf)
- iFrames (Website within a website, massively exploited)
- Media (Audio/Video)
- Loading objects from either external server, or localhost (Server IP)
- Disallow vulnerable strings (“'”)
At this point in time the Content Security Policy is compatible with all major browsers and shows no signs of slowing down of its production updates. With that being said, it is also safe to assume that even more browsers will soon support it in their newly released versions, tightening the grip of control we have over our distributed content. Although CSP 1.0 is reasonably supported by modern browsers only Chrome and Opera support most of CSP 2, which give the more security features which such as hash-source, nonce source, which allow you to remove the use of unsafe-eval. Browsers that don’t support it will simply ignore it.
Keep the list blank
The most common and basic way to apply CSP would be:
script-src 'self' affiliate.fastcomet.com fonts.google.com;
This will allow the website to gather it’s loading assets from
- affiliate.fastcomet.com (for example, if you have an affiliation banner is pulled from our server)
- fonts.google.com (which is one of the most major embedded code for fonts/styling)
- self (assets from the server on which the website itself is hosted on)
Out of the box
You do not even need to have prior experience or extensive knowledge in coding. Tutorials on the topic are given with plain explanations and detailed guidelines. You can find and read about the various ways to implement CSP into your website here.
Mozilla has also a Firefox addon which auto-generates a Content Security Policy for a website.
It works wonders
Weighing down on the pros/cons, when implemented correctly, I would say Content Security Policy protocol is most definitely worth adding to your website(s). With the abundance of possible XSS attacks which could potentially be executed on near every website, being able to limit 3rd party scripts sources will without a doubt be a great helping hand in preventing malicious activities, and gain an even greater level of security for your website.