WP What is Content Security Policy (CSP) | Header Examples | Imperva

Content Security Policy (CSP)

App SecurityEssentialsThreats

What is Content Security Policy?

A Content Protection Policy (CSP) is a security standard that provides an additional layer of protection from cross-site scripting (XSS), clickjacking, and other code injection attacks. It is a defensive measure against any attacks that rely on executing malicious content in a trusted web context, or other attempts to circumvent the same-origin policy.

With CSP, you can limit which data sources are allowed by a web application, by defining the appropriate CSP directive in the HTTP response header.

Content Security Policy evaluates and blocks requests for assets

Content Security Policy evaluates and blocks requests for assets

Why is a Content Security Policy Important?

Mitigating Cross Site Scripting

The main purpose of CSP is to mitigate and detect XSS attacks. XSS attacks exploit the browser’s trust in the content received from the server. The victim’s browser is exposed to execution of malicious scripts, because the browser trusts the source of the content.

CSP allows server administrators to reduce or eliminate the ability of an attacker to trigger XSS, by specifying which Internet domains browsers should consider as legitimate sources of executable scripts. CSP-compliant browsers only run scripts contained source files that are retrieved from whitelisted domains, and ignore all other scripts (including inline script and HTML event handling attributes).

Mitigating Packet Sniffing and Enforcing HTTPS

In addition to whitelisting domains from which a browser may load content, servers can also specify the allowed protocols. For example, the server can specify that browsers must load content via HTTPS.

A comprehensive data transfer protection policy involves not only implementing HTTPS in data transfer, but also marking all cookies with the secure attribute, and automatically redirecting HTTP pages to HTTPS. Additionally, sites may use HTTP Strict-Transport-Security headers to ensure that browsers only connect to the site via encrypted channels.

CSP Header Examples

The web server can add an HTTP header called Content-Security-Policy to each response. You can set the following properties in the CSP header:

  • default-src—an optional method if no other attributes are defined. In most cases, the value of this property self—meaning the browser can only upload resources from the current website.
  • script-src—locations from which external scripts can be loaded. If your website or application does not use client-side scripting, set the value to none.
  • img-src—locations from which images can be retrieved.
  • media-src—locations from which rich media like video can be retrieved.
  • object-src—locations from which plugins can be retrieved.
  • manifest-src—locations from which application manifests can be retrieved.
  • frame-ancestors—locations from which another web page can be loaded using a frame, iframe, object, embed, or applet element.
  • form-action—URLs that can be used as part of an action in a <form> tag, meaning the browser restricts where form results can be sent. The form action does not revert to default-src, so this is a mandatory property if you are using form elements on your site.
  • plugin-types—the set of plugins that can be invoked via objects, embeds, or applets, defined using MIME types.
  • base-uri—allows URLs in the src attribute of any tag.

Refer to the complete and up-to-date list of properties from Mozilla.

Which Vulnerabilities Can CSP Prevent?

One main challenge CSP can prevent is that attackers may attempt to access your resources over an unsecure protocol.

You can use CSP to enforce the HTTPS protocol to any value defined in *-src attributes, by adding the https:// prefix to any URL in your whitelist. This way resources will never load over an unencrypted HTTP connection. You can achieve the same effect by adding the block-all-mixed-content property.

In addition, CSP can prevent the following common vulnerabilities:

  • Unsigned inline CSS statements in <style> tags
  • Unsigned inline Javascript in <script> tags
  • Dynamic CSS using CSSStyleSheet.insertRule()
  • Dynamic Javascript code using eval()

It is best to keep the script and CSS in separate files that are referenced by the HTML page. If your site needs to allow this, you can enable it using the keywords unsafe-eval and unsafe-inline.

When to Use CSP

In general, complex web applications are more sensitive to XSS, making CSP important to use.

Use CSP for any application that manages sensitive data, such as administrative user interfaces, device management consoles, or any products hosting files, documents or messages created by users. In modern frameworks, adding CSP is easy and can provide high return of investment in terms of added security.

When Not to Use CSP

CSP may not be the best choice in these cases:

  • Static applications hosted on their own domains or subdomains without login or cookies.
  • Applications that have experienced XSS in the past, or have known vulnerabilities in templates or frameworks they are using. In this case the best approach is to invest in patching or fixing vulnerable code, because CSP on its own will not provide sufficient protection. CSP should be added on top of a secure application with no known vulnerabilities.

Implementing Content Security Policy

The best way to add CSP retroactively to an entire website is to define a completely empty whitelist, essentially blocking everything. Initially, run CSP in report-only mode, which means the browser evaluates rules but does not block the content yet.

You can then review errors and see which of them should be added to the list (allowed) or not (disallowed).

The difficult part is deciding how much to block. For example, if you are using a script hosted through a CDN and you allow the addresses, you accept all traffic coming from those CDNs, which could include malicious traffic.

Running CSP in report mode for a few weeks, or at the most a few months, should give you all the possible cases of errors. When you feel your set of rules captures all relevant use cases, disable report-only and start blocking resources that are not on the whitelist.

XSS Protection with Imperva Application Security

Imperva provides advanced protection against cross site scripting, using its web application firewall (WAF), a cloud-based solution that permits legitimate traffic and prevents bad traffic, safeguarding applications at the edge.

In addition to XSS protection, Imperva provides multi-layered protection to make sure websites and applications are available, easily accessible and safe. The Imperva application security solution includes:

  • DDoS Protection—maintain uptime in all situations. Prevent any type of DDoS attack, of any size, from preventing access to your website and network infrastructure.
  • CDN—enhance website performance and reduce bandwidth costs with a CDN designed for developers. Cache static resources at the edge while accelerating APIs and dynamic websites.
  • Bot management—analyzes your bot traffic to pinpoint anomalies, identifies bad bot behavior and validates it via challenge mechanisms that do not impact user traffic.
  • API security—protects APIs by ensuring only desired traffic can access your API endpoint, as well as detecting and blocking exploits of vulnerabilities.
  • Account takeover protection—uses an intent-based detection process to identify and defends against attempts to take over users’ accounts for malicious purposes.
  • RASP—keep your applications safe from within against known and zero‑day attacks. Fast and accurate protection with no signature or learning mode.
  • Attack analytics—mitigate and respond to real security threats efficiently and accurately with actionable intelligence across all your layers of defense.