Content security policies
Content security policies (CSP) are used as a security layer to protects your browser from loading and running content from untrusted sources. The policies help detect and mitigate certain types of attacks on your application through a browser, including cross-site scripting (XSS) and data injection attacks.
When a browser loads a page, it is instructed to include assets such as style sheets, fonts, and JavaScript files. The browser has no way of distinguishing script that is part of your application and script that has been maliciously injected by a third party. As a result, the malicious content could be loaded into your application. CSPs help protect your application from such attacks.
Note: If an attack takes place, the browser reports to your application that a violation has occurred.
CSPs are a set of directives that define approved content sources that the user's browser may load. The directives are sent to the client in the Content-Security-Policy HTTP response header. Each browser type and version obey as much of the policy as possible. If a browser does not understand a directive, then that directive is ignored. In other situations, the policy is explicitly followed. Each directive governs a specific resource type that affects what is displayed in a browser. Special URL schemes that refer to specific pieces of unique content (such as data:, blob:, and filesystem:) are excluded from matching a policy of any URL and must be explicitly listed.
CSPs are instances of the Rule-Access-CSP class in the Security category.
To access the content security policies in an application, you can:
- Use the Application Explorer to list the content security policies in your application.
- Use the Records Explorer to list all the content security policies that are available to you.
You can specify a content security policy on the Integration & security tab of the Application rule form.
The value selected for Mode (refer above screenshot) of content security policy derives whether to enforce the policy, or to merely report usage of the policy:
- Reject and report – Enforce the policy
- Report only – Report, but do not enforce the policy
A content security policy helps reduce exposure to a variety of security threats by limiting the content in your application to only the sources that you place on an allow list.
Note: Pega throws a guardrail warning if the Content Security Policy is not defined for the application. This application's Content Security Policy on the Integration tab is left blank. It is recommended to use a default policy or create your own before migrating to a production environment.
If the Mode of the Content Security Policy is set as Report only then Pega throws the following guardrail warning on Application rule form:
This application's Content Security Policy mode has been left in Report-Only mode. This mode will not restrict content on your user's browsers, greatly weakening the policy's usefulness. The policy mode should be set to Reject and Report mode.
It is a best practice that you set the mode of Content Security Policy as Reject and Report to strengthen the security of your application.
If the Content Security Policy is enforced, the browser blocks to run the script or resources and displays the following message on the browser console:
Content Security Policy of your site blocks some resources because their origin is not included in the content security policy header
The Content Security Policy (CSP) improves the security of your site by defining a list of trusted sources and instructs the browser to only execute or render resources from this list. Some resources on your site can't be accessed because their origin is not listed in the CSP.
To solve this, carefully check that all of the blocked resources listed below are trustworthy; if they are, include their sources in the content security policy of your site. You can set a policy as a HTTP header (recommended), or via an HTML <meta> tag.
Caution: Never add a source you don't trust to your site's Content Security Policy. If you do not trust the source, consider hosting resources on your own site instead.
The following image is an example of an error message displayed on the browser console if the Google Maps is not added as a trusted source and if the application is referring to Google Maps:
Refused to load the script 'http://maps.googleapis.com/maps/api/js?v=3&key=AIzaSyD1k79C-9eU80kfMdyR-8k3ZcqswwmPgM4&sensor=true&callback=pega.ui.maps.mapsScriptLoaded' because it violates the following Content Security Policy directive: "script-src 'unsafe-inline' 'unsafe-eval' 'self' http://www.google-analytics.com https://ssl.google-analytics.com https://unpkg.com/swagger-ui-dist@3/swagger-ui-bundle.js". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
As a best practice, develop a customized content security policy rather than using the Pega out-of-the-box pxDefaultAllowAll or pxDefaultSecured to hide the warning.
Note: The SECU0009 security alert is generated when a browser reports a violation of your application's Content Security Policy. The alert message describes the violation as an attempt by an untrusted source to load content.
For details on how to set content security policies, see the help topic Policy definition tab on the content security policies form.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?