Goals of Content-Security-Policy (CSP)

The deployment of Content-Security-Policy (CSP) helps organizations with the following goals, as defined in the Mozilla: Content-Security-Policy Level 3 (section 1.2):

• Mitigate the risk of content-injection attacks by giving developers fairly granular control over.
  • Resources can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker.
  • The execution of inline scripts.
  • Dynamic code execution (via eval() and similar constructs).
  • The application of inline style.
• Mitigate the risk of attacks that require a resource to be embedded in a malicious context (the “Pixel Perfect” attack described in [TIMING], for example) by giving developers granular control over the origins that can embed a given resource.
• Provide a policy framework that allows developers to reduce the privilege of their applications.
• Provide a reporting mechanism that allows developers to detect flaws being exploited in the wild.

Goals

The grading of the deployment of CSP should try to assess the fulfillment of each of the following goals:

• Prevent Content Injection Attacks
• Prevent Resource Embedding Attacks
• Prevent the Reduction of Application Privileges
• Detect Attack Attempts via CSP Reporting

Prevent Content Injection Attacks

Effective implementation requires an application to be designed or refactored in a way that eliminates inline Javascript or adds specific controls to its execution via the hash or nonce values.

The following checks can be made:

• Presence of unsafe-inline or unsafe-eval in script-src and unsafe-inline in style-src. Policies using these values reflects a website that is not optimized to take advantage of CSP and does not protect the user from code-injection attacks.
• Absence of host specific script-src, style-src and object-src? directives. A CSP that does not specify at least one authorized host for its script and style directives does not protect against code injection attacks.

Prevent Resource Embedding Attacks

Websites should specify the origins that are allowed to embed resources in the website's document to prevent attacks that take advantage of embedding malicious resources.

The following checks can be made:

• Using the frame-ancestors directive to prevent the website resources from being loaded inside iframe prevents resource embedding attacks such as the pixel perfect attack or clickjacking.
• For X-Frame-Options, verify the header is not set. They achieve the same objective.
• If upgrade-insecure-requests is present, there’s no penalty on the presence of any HTTP links within an HTTPS page. Any check for the presence of mixed content is skipped.

Prevent the Reduction of Application Privileges

Reduction of application privileges follows the security principle of least privilege and directs that any application should not be given access to processes or files in excess of what the application needs, at minimum, to complete its tasks.

The following checks can be made:

• Assess the level of restriction of all the fetch directives: All the fetch directives either through the default-src or specifically defining each one of them should contain at least one host specific value, or none, and no wildcards.
• Limit the use of objects and plugins that can be used by the application (plugin-types).
• Limit the actions of the current document (form-action).

Detect Attack Attempts via CSP Reporting

One of the features of CSP is its ability to report violations of the policy to the website owner. These reports may represent simple errors in the application or in the policy but they may also represent real attack attempts against the application, such as XSS vulnerabilities being exploited or malicious software modifying user’s browsers to target the application. This feature should be used and the reports monitored for events that may require action (e.g., correcting an XSS vulnerability). The following checks should be made:

• Reporting policy violations: Ensure the report-to header being used when reporting policy violations.
• Check if the policy is report only: If the policy is report only, it is not being enforced and consequently not protecting the application and its users directly. However, this demonstrates that violations are being monitored for response or for debugging of a future implementation of an enforcement policy. This effort is relevant and should be considered.
• X-Frame-Options: Prevents resource embedding attacks. Use only when X-Frame-Options is present and correctly set.
• No reporting: Use only when there is no place to log violations.
• Content-Security-Policy record is report only: For report-only records. If there is no regular CSP header, there should already be an annotation indicating that the required header is missing.