Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Content security policy directives

Updated on July 1, 2021

The Policy Definition tab contains a section for each source directive. Set the policy directives for each category displayed by clicking the category title to display or hide its fields.

You can create a content security policy or open an existing instance from the navigation pane by clicking RecordsSecurityContent Security Policy and selecting an instance.

For most of the source directives, you can choose from the following restrictions (exceptions are described in the relevant section below):

  • None – Do not allow any location or URL.
  • Allow-All – Allow all locations for this resource.
  • Self – Match the location of the containing document but not subdomains or other domains.
  • Data – Match inline resources defined using data.

For most source directives, you can also list individual allowed websites. For more information, see Allowing a website as an exception to a content security policy directive

You can configure the following source directives on the Policy Definition tab.

Default-Src

The Default-Src directive serves as a fallback for the other CSP fetch directives. For each of the following directives, if the directive is not explicitly stated, the user or agent applies the value for the default-src directive: child-src, connect-src, font-src, img-src, media-src, object-src, script-src, style-src.

Base-URI

The Base-URI directive governs the document base URL. Most websites use a relative link system, which informs a web browser where a resource is relative to its location. A browser uses the document's base Uniform Resource Identifier (URI) and the relative link to create a full path to that resource. An attacker who controls the base URI can force the user's browsers to pull potentially malicious content from the attacker's site.

Connect-Src

The Connect-Src directive restricts the URLs that the protected resource can load. This restriction includes, but is not limited to, EventSource, WebSocket, and XMLHttpRequest (the driving source behind AJAX) connections. Limiting the XMLHttpRequest connection sources can protect users from attacks where an attacker forces a user's browser to make connections without alerting the user. Use this directive if your application’s users make cross-origin requests as part of a cross-origin resource sharing (CORS) system.

Font-Src

The Font-Src directive controls the locations from which fonts can be loaded. An attacker can exploit several vulnerabilities that target the browser's font generation. Such an attack could compromise a user's browser.

Form-Actions

The Form-Actions directive governs the URLs that can be used as an action of the HTML <form> element. An attacker who gains access to this directive could compromise a user’s data and submit potentially confidential information to the attacker's website.

Frame-Ancestors

The Frame-Ancestors directive restricts access from websites that can embed your application by using a <frame>, <iframe>, <object>, <embed>, or <applet> element. An attacker can embed your application in a malicious site, and log each keystroke and mouse click made by users who visit the site to use your application.

Child Frame-Src

The Child Frame-Src directive manages the content sources that your application can include in <frame> and <iframe> elements. An attacker can control the frame source and make it pull malicious data, including cross-site scripting attacks, into your application user's browser. Avoid using Allow-All.

Image-Src

The Img-Src directive controls the sources from which your application can load images. Attackers can use the HTML <img> tag to extract confidential information through a cross-site scripting attack and make an image request to their own malicious site to request a non-existent image and append the page content. The attacker can then view the malicious site's logs to read your page's content.

Media-Src

The Media-Src directive manages sources from which your application can download media such as videos and audio files. An attacker can compromise a page to load a malicious object that can compromise a user's computer.

Object-Src

The Object-Src directive manages sources from which your application can download objects by using the <object>, <embed>, and <applet> elements. Such objects include Flash files, Java applets, scripts in other languages, and generic text documents. Flash files and Java applets can run any kind of code; if an attacker can compromise a page to load a malicious object, the user's computer could be compromised.

Plugin-Types

The Plugin-Types directive contains a list of allowed resource types that can be retrieved and used to instantiate plug-ins. This directive in conjunction with other directives, particularly the Object-Src directive, can ensure that all the content that is loaded by the plug-in is the correct content. An attacker is able to upload malicious content, such as a Java applet, to a source that is defined in Object-Src.

Sandbox

The Sandbox directive specifies an HTML sandbox policy that the user applies to the protected resource. These policy settings are closely aligned with the World Wide Web Consortium (W3C) specification. If these settings are too permissive, an attacker can load a malicious site through a frame.

Script-Src

The Script-Src directive restricts the scripts that the protected resource can run, protecting users against script injection attacks (for example, XSS).

Style-Src

The Style-Src directive governs the sources of styles (stylesheets) that can be used. Attackers can use the <style> tag to describe CSS style sheet content or external sources of style sheets. A style sheet loaded from a malicious site might make your application unusable by overriding content with images, odd colors, decreasing opacity, or by entirely removing your content.

  • Previous topic Creating a content security policy
  • Next topic Allowing a website as an exception to a content security policy directive

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us