When protecting web applications, companies often use multiple technologies to create a layered defense. These controls typically take the form of software—like firewalls—as well as other cybersecurity measures like two-factor authentication, which both serve to keep unwanted and malicious guests away from their internal systems.
Unfortunately, one area that doesn’t get as much attention is the client-side attack surface. This is the entire surface of a company’s website or web application that is accessible by customers and partners via their personal web browsers. Many companies are reluctant to put aggressive safeguards in place to protect their web assets, since some policies can be disruptive and slow down the overall customer experience.
One of the best ways to protect the client-side of your business is by deploying a content security policy (also known as CSP). This is a simple security measure that can be implemented on any website and serves as an added layer of security.
Here, we’ll explain the details of what a content security policy is, and show how any business with a digital experience can implement one to help provide more safety and security to their own web applications.
Content Security Policy (CSP): Added Security Layer
A Content Security Policy (CSP) is an added layer of security that helps businesses and security teams detect and mitigate certain types of client-side attacks. CSP can help uncover cross-site scripting (XSS), JavaScript code injection, and data skimming attacks. Threat actors try to circumnavigate CSP in order to steal data, distribute malware, or deface websites.
Essentially, a content security policy works by identifying and preventing malicious scripts, which are a primary client-side security threat. By repelling these scripts, a content security policy can stop an attack before it begins.
Stopping these attacks is extremely important, as so many companies now do the majority of their business online. If your website is compromised and your company is no longer able to sell products or communicate with customers, it can cause a major blow to your revenue as well as your public reputation.
Considering that 98% of the top US websites are vulnerable to client-side attacks, many organizations need to consider implementing CSP that have not already done so.
CSP Example
There are two different ways to set up your content security policy so it offers protection to your web assets without causing issues for the IT team or the individual managing it.
Here are some examples of common content security policy scenarios:
Allow everything but only from the same origin
default-src ‘self’;
Only Allow Scripts from the same origin
script-src ‘self’;
Allow Google Analytics, Google AJAX CDN, and Same-Origin
script-src ‘self’ www.google-analytics.com ajax.googleapis.com;
Using these and other directives, the individual setting up the CSP can define which data sources are allowed through the filter, keeping out those that are malicious and allowing in anything that they have whitelisted.
CSP Implementation Basics
A content security policy is a complex filter, and there are many ways to set it up to ensure that it excludes everything malicious without disrupting the function and flow of your website. It does this using an intricate set of directives that tell each webpage what content source can be trusted, and which should be denied access.
This is a delicate balance. Someone with the right expertise needs to set up the content security policy to ensure that it permits approved sources through without leaving too many loopholes open to exploitation. A loose content security policy that can easily be exploited by a malicious actor may as well not be there at all.
How to Deploy a CSP
A content security policy is a layer of code that can be deployed in two different ways; added as a server header or through a meta tag. Both deployment models can be verified through the use of Google Chrome Development tools.
How to Configure a Content Security Policy
When you first start configuring a content security policy for your website, most seasoned developers recommend starting in Report Only mode. This doesn’t repel any content, but instead sends you a list of all the content that would have been blocked if you had set the CSP to enforcement mode.
This helps you to identify which third-party apps and vendors need to be able to access your site and should be whitelisted. During this period, you’ll receive many reports, which will assist in the creation of a whitelist that actually works for your needs and leads to less work for you and your team in the long run.
More Resources
A content security policy is a great resource that every business should be using to defend the client side of their web applications and websites. If you have any more questions about how it works, you can check out more of our resources on it, including our in-depth blog post.
Feroot is dedicated to helping companies, both big and small, protect their web assets, and is passionate about offering solutions that can make client-side security easier. Two of our biggest resources are our client-side security solutions Inspector and PageGuard.
These solutions both work silently in the background, scanning your site for anomalies and immediately reporting on any issues they find. Their robust reporting features allow your team to focus their attention on the day-to-day operation of your business, stepping in to deal with issues as they come up without spending all their time on monitoring and maintenance.
Feroot also developed DomainGuard, a product specifically designed to make content security policies easy to manage, maintain and enhance. DomainGuard automatically generates custom content security policies based on crawls of specified web applications. Once the CSP is deployed, DomainGuard tracks versions and reports on violations.
Demo Inspector, DomainGuard and PageGuard to see these security solutions in action!