Understanding Content Security Policy: A Comprehensive Guide
Problem of the Permission-less Web
Content-Security-Policy (CSP) introduces permissions to the web, a platform that is inherently permission-less. Without a proper CSP, websites and web applications remain fully exposed. They can, by default, send requests to any server globally, embed within any site, or load scripts from any source.
This openness allows for rapid deployment and integration of a vast array of external code into your site. In contemporary web design, over 70% of the code is often not authored by the site's developers but by third parties or open-source contributors.
However, this freedom also escalates the risk of security breaches, as each external resource operates within the same unrestricted environment, inheriting the ability to execute virtually any action within the site or application.
Yet today – web applications involve highly sensitive transactions via your users’ browser on an ongoing basis. A few examples:
- Managing sensitive personal information and transaction with online banking / health / insurance.
- Sending and receiving countless work and personal emails / chat messages.
- Interacting with maps and sharing location specific data.
- Using countless online SaaS products that run in your browser.
- Shopping with your credit card in e-commerce businesses.
Historically, the web's architecture was less security-focused, primarily designed for content consumption. However, today's web applications manage sensitive transactions and personal data, making robust security measures imperative. Activities like online banking, personal communication, location sharing, and e-commerce transactions, are highly vulnerable to cybersecurity threats, contributing to about 50% of all root-causes of security incidents.
Unfortunately, reconstructing the web with modern security defaults is impractical. Nevertheless, the W3C, along with browser developers, has progressively introduced missing security and permission controls through Security Headers, served via HTTP headers. Among these, the Content-Security-Policy (CSP) is pivotal, dictating what can be loaded on a web page and its permissible sources.
Introduction to Content Security Policy (CSP)
The CSP is a standardized allowlist mechanism, CSP enables developers and operators to dictate browser behavior, specifying what is permissible for a specific website or web application.
Let’s take an example OWASP’s recommendation of how to defend against Clickjacking:
Central to this defense is the frame-ancestors directive within the CSP. This directive delineates where a site may be embedded as a frame, essentially cordoning off unauthorized domains.
The syntax:
Content-Security-Policy:
frame-ancestors 'self' https://sub.site-i-allow.com;
report-uri https://mysite.ingest.csp.sh
This simple mechanism closes the attack surface on the ClickJacking attack as framing the site anywhere on the internet becomes forbidden. Moreover, when any attempt to frame the site, is blocked by the CSP – a report will automatically be sent to the report-uri (in this case useCSP reports ingester), that can shed light on the attack. Basically this is a built-in telemetry, that when used correctly – can alert on attacks / breaches in real-time.
However, CSP's arsenal extends beyond this. With a suite of directives addressing diverse scenarios, like script-src for defending against Cross-Site Scripting (XSS) and form-action for impeding formjacking, CSP provides a comprehensive shield. When combined correctly – these directives collectively offer unparalleled defense against a plethora of prevalent cyber threats.
The Necessity of CSP in Modern Web Security
In the recent years, adoption of Content-Security-Policy has increased significantly, due to the standardization of CSP and several powerful regulatory / industry forces demanding websites use this mitigation technique. Security assessments and checklists of all kinds check that you are properly managing content security policies on all your web assets:
-
Auditors requiring to see CSP headers
The PCI Standards Security Council requires CSP usage to mitigate JS supply chain attacks / Magecart:
Third party scripts should be monitored to detect changes and the changes be reviewed to identify any potentially malicious code before implementation. Using content security policies (CSP) to restrict compliant browsers from executing JavaScript from sources which have not been explicitly whitelisted is an added protection that should be incorporated.
And we can see that many PCI-DSS auditors are checking for CSP deployment, with the need to show retroactive evidence of proper usage:
As a PCI DSS assessor, I may be asking questions about where your CSP headers exist in your next assessment!
-
CSP in Penetration testers’ checklist
Web application vulnerabilities are by-far the most critical and frequent finding across penetration tests in all sectors, as can be seen in this report:
In 77 percent of cases, local network penetration vectors involved insufficient protection of web applications.
Source - Penetration testing of corporate information systems: statistics and findings in 2020
Many companies decide to implement Content-Security-Policy (CSP) and other security headers after having them as the remediation recommendation in the penetration test results.
-
Graders penalizing “Content Security Policy (CSP) Missing”
Risk assessment platforms like SecurityScorecard have made companies’ security posture public, and subject to automatic, ongoing scanning of your companies assets.
Your grade on these scanners now holds a significant portion of the enterprise vendor decision process – and your business cannot afford to have low grades (as this literally loses deals).
-
Legislators moving-target laws
The GDPR, CCPA and other legislation, has flexible language (on purpose) – allowing evolution of standards.
Take for example the CCPA, that requires to use reasonable security procedures and practices.
Any consumer whose nonencrypted or nonredacted personal information, as defined in subparagraph (A) of paragraph (1) of subdivision (d) of Section 1798.81.5, is subject to an unauthorized access and exfiltration, theft, or disclosure as a result of the business’s violation of the duty to implement and maintain reasonable security procedures and practices appropriate to the nature of the information to protect the personal information may institute a civil action for any of the following.
Source - SEC. 11. Section 1798.150 CCPA
But What accounts as reasonable?
Until recently, it was very hard to deploy a Content-Security-Policy. Only tech-savvy companies such as Google and Github could utilize dedicated internal security experts, with dedicated infrastructure to use CSP on some of their assets.
Hence, it was reasonable for companies with less resources – not to go this extra mile (of hiring experts), and they could get a pardon on failing to meet this “unreasonable” measure.
Today however, Generating a Content-Security-Policy for your sites can be automatic, and managing your CSP with useCSP (or some of the WAF providers that have a CSP feature), has become a much more approachable task.
This best-practice enforced approach to Content Security Policy does not require deep expertise / research / your own dedicated infrastructure. In fact – we’ve seen many cases of one Security / IT / DevOps / R&D engineer deploy CSP across dozens of an enterprise’s assets in a single day with useCSP.
Combined with the affordable pricing for managing CSP, it is now highly reasonable that all companies with PII / sensitive web assets use Content-Security-Policy as an HTTP header on all their assets.
We’ve also seen GDPR breaches fined heavily, for lack of adopting proper standardized security controls. Such as the ICO fining British Airways £20M for data breach affecting more than 400,000 customers (FYI: this fine was significantly reduced from the original £183M fine due to unusual constraints on airlines in the 2020 lockdowns).
Failure to prevent the attack: There were numerous measures BA could have used to mitigate or prevent the risk of an attacker being able to access the BA network. These include limiting access to applications, data and tools to only that which are required to fulfill a user’s role
Lack of awareness of the attack: ICO investigators found that BA did not detect the attack on 22 June 2018 themselves but were alerted by a third party more than two months afterwards on 5 September.
Note that the ICO clearly specifies two failures – not preventing the attack in the first place with proper mitigation AND having the skimming of PII and credit cards go on for two months!
Had British airways properly utilized a Content-Security-Policy on their site, both of these major infractions would have been solved – avoiding leaking data of 429,612 of their customers and staff, and saving BA from the lawsuit and bad PR.
-
Industry Requirements for Enterprise-ready Products and Services
The Minimum Viable Secure Product (MSVP) was recently launched as a collaboration of Google, Salesforce and other industry leaders – with the aim of providing externally recognized of security baselines to build your compliance efforts.
This minimalistic security checklist for B2B software and business process outsourcing suppliers, is designed with simplicity in mind. The checklist contains only those controls that must, at a minimum, be implemented to ensure a reasonable security posture – applicable to RFPs, security self assessments and vendors’ security posture questionnaires.
Google’s experts have been advocating for the usage of Content Security Policy and other Security headers as as an effective measure for years, so it’s not surprising that CSP is a now a formal requirement on this checklist also:
Set a minimally permissive Content Security Policy: This control measures that appropriate browser protections are in place within your product and/or service to protect against common web threats.
Benefits of Content Security Policy for Security / Compliance Teams
In addition to getting great security posture – by properly implementing CSP, you will be closing massive attack surfaces that are the most commonly exploited security vectors.
Having full monitoring / alerts of violations of your policy in your web assets when leveraging the useCSP threat detection module – has “been a godsend” quoting one of our customers.
Add to that the added sense of security of finally having control over that endless JS dependency supply-chain!
When done right – implementing CSP across your web assets is definitely the best ROI for your security posture.
Challenges of adopting CSP effectively
Enterprises trying to build their and maintain their Content Security Policies manually tend to encounter the following problems:
- Requires deep expertise – does your R&D team have time to read the endless documentation on the dozes of directives and controls?
- Requires dedicated technology – Violation reports to a dedicated CSP report URI. Do you really want to build one yourself?
- Time consuming – Deployment can take months if you are manually looking into your apps and trying to reverse-engineer their suitable CSPs.
- Risky when done improperly – there are many measures to take to build a Content Security Policy without breaking your site.
- Maintain a system of record – Do you register versions of your CSP? When they change? Where they get deployed? These questions will come up in your next audit – so your need proper evidence collection.
As you may have guessed by now, useCSP is working on building best tools in the world to deploy Content-Security-Policy at scale – in any site / company.