What is Content-Security-Policy (CSP)?

Short answer

Content-Security-Policy (CSP) is the response header that tells the browser from which sources the page can load scripts, styles, images, fonts and frames; content coming from a source that is not allowed is not loaded or run by the browser. This way, scripts injected into the page through XSS are largely prevented from running. In TR7, when Content-Security-Policy ("default-src 'self'" ) is selected in the Response Headers list of the Manage HTTP Security Headers action, the header is written with the default-src 'self'; value to the responses coming from the Backend Service; this value allows only the resources coming from the page's own origin and also blocks inline scripts. The value is fixed; if a different policy is needed, the header is written at the response stage with the Set HTTP Header action.

Where It Is Used in TR7

Where	Field / label	What for
Load Balancer → Actions (Policy Actions) → Manage HTTP Security Headers form	Response Headers → Content-Security-Policy ("default-src 'self'" )	Writing the fixed default-src 'self'; policy to the response
Load Balancer → Actions (Policy Actions) → Set HTTP Header form	Set HTTP Header	Writing an application-specific CSP value at the response stage

How Does It Work?

CSP consists of directives; each directive lists the allowed sources for one resource type (W3C Content Security Policy Level 3):

Directive	What it controls
default-src	The default list for the resource types whose own directive is not written (script, style, image, font, frame, connection…); it does not take the place of directives that are not related to resource loading, such as frame-ancestors
script-src, style-src, img-src, font-src	Script, style, image and font sources
frame-ancestors	On which pages the page can be shown inside an iframe

The default-src 'self' that TR7 writes is a single directive: all resource types are loaded only from the same origin (it does not control the page being shown inside an iframe; for that: What is X-Frame-Options?); since 'unsafe-inline' is not written, the scripts and styles embedded in the page do not run either. The header is added only to the responses coming from the Backend Service; the responses that TR7 produces itself (blocking and error pages) do not get this header.

Common Misconceptions

• "Adding CSP does not affect the application." default-src 'self' blocks content coming from an external CDN, an analytics service or an inline script; the change is first tried in a test environment.
• "CSP takes the place of the WAF." CSP works on the browser side; it does not block the attacks coming to the server, and for that a WAF is used.
• "If the Backend Service sends a CSP, TR7 adds a second CSP." Manage HTTP Security Headers deletes the Content-Security-Policy value of the Backend Service and writes its own value (overwriting the existing headers).

How it is done in the documentation

• Manage HTTP Security Headers · The Security Headers That Can Be Selected
• Manage HTTP Security Headers · Operational and Safe Usage Recommendations
• Set HTTP Header

Related questions

• Can I add security headers (CSP, HSTS, X-Frame-Options) without touching the backend?
• What are HTTP security headers?
• What is X-Frame-Options?