Content security policies
The Content Security Policy (CSP) is a set of directives that inform the user's browser of locations from which an application is allowed to load resources. These locations are provided in the form of URL schemes, including the use of an asterisk (*) to represent all URLs. Each directive governs a specific resource type that affects what is displayed in a browser. Collectively, the directives are sent to the client in the Content-Security-Policy HTTP header. Each browser type and version obey as much of the policy as they can. If a browser does not understand a directive, it is ignored; otherwise it is explicitly followed.
Content Security Policy
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 clickingand selecting an instance.
For most of the source directives, you can choose from the following restrictions.
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The Script-Src directive restricts the scripts that the protected resource can run, protecting users against script injection attacks (for example, XSS). Pegasystems recommends adding specific websites to the Allowed Websites list. Avoid using Allow-All. Pega Platform applications must have unsafe-eval and unsafe-inline checked. For more information on specifying unsafe-eval and unsafe-inline, see CSP: script-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 Using Access Control Checks Next topic Securing your application with a content security policy