About Client-Side Protection

Fastly Client-Side Protection provides you with the ability to inventory and control the resources (e.g., scripts, images, and fonts) that load on an end user’s browser from defined areas of your web applications by building and enforcing content security policies (policies). In addition, you can provide a justification as to why each client-side script is or isn’t allowed. These capabilities help you guard against cross-site scripting attacks (e.g., Magecart attack) and enable you to maintain compliance with Payment Card Industry Data Security Standard (PCI DSS) 4.0.1 - Sections 6.4.3 and 11.6.1.

Prerequisites

To use Client-Side Protection, be sure you have the following prerequisites in place:

  • Client-Side Protection is disabled by default. To purchase and enable the product, contact sales@fastly.com. Once enabled, all users will be able to access the Client-Side Protection menu in the Fastly control panel and the items within it, but you'll only be able to view and manage the data on linked pages if you've been assigned the role of superuser. All other user roles will see an error message indicating you're not authorized to view the information.
  • For Fastly to be able to inventory the client-side scripts on your web application, the Next-Gen WAF must be monitoring that same web application.
  • If you have a Core WAF deployment, verify that the Next-Gen WAF agent and module versions that you're using support Client-Side Protection.
  • If you’ve written a custom module for integration with the Next-Gen WAF, update the module to support response header modification.

Supported Core WAF deployment options

The following Core WAF deployment variations support the Client-Side Protection product:

Deployment variationMinimum agent versionMinimum module versionNotes
Apache module1.10.0+
AWS Lambda4.64.0+
Envoy4.62.0+Envoy, Istio Envoy filter, and Istio Authorization policy are supported. If you use Ambassador Edge Stack and Gloo, you must configure the agent as a reverse proxy. Those environments do not support the Envoy external authorization features that are needed to modify response headers.
Golang4.61.0+If you've written a custom module for integration with the Next-Gen WAF and use the Golang module, the Golang module must be at least version 1.14.0.
HAProxy4.63.0+1.5.0+
Heroku4.61.0+
IBM Cloud4.61.0+
IIS module3.5.0+
Java module2.7.0+
.Net module1.7.1+
.Net Core module1.4.1+
NGINX Lua module1.7.0+
NGINX native module1.2.0+
Node.js module2.3.0+
Reverse proxy4.61.0+
VMware Tanzu4.61.0+

The following Core WAF deployment variations do not support the Client-Side Protection product:

  • PHP
  • Python

How it works

Client-Side Protection works alongside the Next-Gen WAF to inventory and control the resources that load on an end user’s browser from defined areas of your web applications. You define the areas by creating at least one website and Page. A website is a base URL (e.g., https://www.example.com) and a Page is a single path (e.g., /checkout) or collection of paths that describe a similar component or user experience on your web application (e.g., /checkout and /edit-cc). Together, a website and Page define the full URLs (e.g., https://www.example.com/checkout and https://www.example.com/cc) of the webpages that you want to monitor and protect.

Once you've created at least one website and Page, you can:

  • monitor the inventory that Fastly creates for each Page. An inventory is a collection of the client-side scripts and select response headers that Fastly observes for a Page. Reviewing changes to your inventory can help you identify security issues that should be investigated.
  • build and manage a policy that tells the end user's browser from where it is allowed to load certain types of resources for the Page. Maintaining a policy helps guard against cross-site scripting attacks.

About the inventory

An inventory is a collection of the client-side scripts and security-impacting response headers that Fastly observes for a Page. Each inventory is associated with a single Page.

To create and maintain the inventory, the Next-Gen WAF inserts the Content-Security-Policy-Report-Only header into a sample of responses for a Page. This header makes it possible for Fastly to observe and collect the scripts and response headers for the inventory.

TypeCollection frequency
Client-side scriptsEvery three days, Fastly pulls the observed scripts into the inventory and stores them. When Fastly fails to re-inventory a script for 90 days, Fastly removes the script from the inventory.
Security-impacting response headersFastly logs the security-impacting response headers for all responses that have the Content-Security-Policy-Report-Only response header.

Every three days, Fastly sends you a list of the response headers that changed to the email address you defined on the associated Page. The changes are grouped into 60-minute periods.

From the Inventory page in the Fastly control panel, you can:

  • add an authorization status and comment for each observed script to help keep track of the scripts that you've reviewed and why certain scripts are or aren't approved.
  • view the security-impacting response headers from the last-logged response.

If you think that a response header value is dangerous or that a script shouldn't be loading on your web application, investigate the issue and take action accordingly.

About the policy

Using the Fastly control panel, you can create a policy that applies to one Page. A policy is made up of directives, which tell the end user's browser what resources its allowed to load and from where. Each directive controls one type of resource. For example, the script-src directive controls the allowed sources for JavaScript.

Client-Side Protection works with the Next-Gen WAF to add your policy to responses that pass through the WAF for the associated Page. Depending on whether Client-Side Protection is in blocking or logging mode, the Next-Gen WAF adds the Content-Security-Policy or the Content-Security-Policy-Report-Only response header. These headers deliver the policy to the end user's browser, and in the case of blocking mode, tell the end user's browser to enforce the policy. For example, if Client-Side Protection is in blocking mode and the script-src directive doesn't list www.example.com as an allowed source, the end user's browser blocks all scripts from www.example.com.

In both blocking and logging mode, the end user's browser logs the policy violation and sends a report to Fastly. If the violation is unique, Fastly stores the report. Violation uniqueness is defined by the following properties:

  • Website and Page (e.g., www.example.com/cc)
  • Effective or violated directive (e.g., script-src)
  • Policy
    NOTE

    When you make a change to your policy and activate the change, the activated policy is considered different from the previous version of the policy.

  • Disposition (i.e., blocking or logging mode)
  • Blocked URI (e.g., https://example.com/js/library.js)
  • HTTP response status code
  • Sample of the script if the effective directive is script-src

If a policy violation is not unique, Fastly increases the count on the existing report for the identical violation by one. We store reports for 90 days.

You can access stored reports from the Reports page in the Fastly control panel. If you want to update your policy based on a report, make note of the relevant effective directive and blocked URI, go to the Policy page, and add a new value for the effective directive, being sure to adhere to fetch directive syntax.

Protection modeResponse headerActions taken when a resource violates the policy
BlockingContent-Security-Policy
  1. The end user's browser blocks the resource and logs the policy violation.
  2. The end user's browser sends a policy violation report to Fastly.
  3. If the violation is unique, Fastly stores the report. If not, Fastly increases the count on the report for the identical violation.
LoggingContent-Security-Policy-Report-Only
  1. The end user's browser logs the policy violation.
  2. The end user's browser sends a policy violation report to Fastly.
  3. If the violation is unique, Fastly stores the report. If not, Fastly increases the count on the report for the identical violation.
OffNone, the policy is not sent to the end user's browser.None
Was this guide helpful?

Do not use this form to send sensitive information. If you need assistance, contact support. This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.