Proper Content-Security-Policy (CSP) Implementation

⇤ Web Application Header Assessment

Required for HTTP/1.1 and HTTP/1.0

A properly configured Content-Security-Policy (CSP) can help prevent cross-site scripting (XSS) attacks by restricting the origins of JavaScript, CSS, and other potentially dangerous resources.

See finding messages.

• See the W3: Content-Security-Policy Level 2 and Mozilla: Content-Security-Policy documentation for more information about this directive.
• Goals of CSP.
• The overall Web Application Headers letter grade is computed from the weight of all required directives and the optional directives that are not present. See the assessed CSP directives.
• We check for the presence of mixed content within headers; If upgrade-insecure-requests is present, there’s no penalty on the presence of any HTTP links within an HTTPS page.

A good CSP should:

• Implement directives that set valid source restrictions from where the client can load frames and scripts as well as limit where the client can submit form data.
• Restrict plugins and specify a valid resource for reporting policy violations.
• Not contain “unsafe” keywords or include wildcards that are ineffective for restricting sources.

Example Policy

• Script source restrictions are inherited by the default-src value, which does not contain an “unsafe” keyword or a broad wildcard source.
• Frame embedding is restricted.
• Plugins are blocked.
• A form-action directive is in place.
• A valid reporting endpoint is provided.

default-src ‘self’; object-src ‘none'; form-action 'none’; report-to csp-endpoint;

Either X-Frame-Options should be good or it should include frame-ancestors.

Good X-Frame-Options:

X-Frame-Options: sameorigin

Includes frame-ancestors:

default-src ‘self’; object-src ‘none'; form-action ‘none’; frame-ancestors 'self’; report-to csp-endpoint;