Content Security Policies
Completing the Policy Definition tab
Content Security Policies
|
|
Set the policy directives for each category displayed. Click the title of a category to display or hide its fields.
In many sections you have the option of allowing access to the website (or a behavior such as form-action) from a list of websites. To add a website click the + icon in the appropriate policy section. Enter the website URL and, optionally, a note to explain why this site should have access.
The Base-URI directive governs the JavaScript document variable "base." Most websites use a system of "relative links" which inform a web browser where a file is relative to its current location. The browser uses the document's base URI and the relative link to create a full path to that resource. An attacker who can control the base URI can force the user's browsers to pull potentially malicious content from the attacker's site instead of from the site under attack.
Pega recommends accepting the default configuration.
The Connect-Source directive manages outbound connections from a user's browser. This includes, but is not limited to, EventSource, WebSocket, and XMLHttpRequest connections. XMLHttpRequest is the driving force behind AJAX, so limiting its connection sources can protect your users from a wide range of attacks where an attacker forces a user's browser to make connections without alerting the user.
As a best practice, add specific websites, as described above, if users may make Cross Origin requests as part of a Cross Origin Resource Sharing (CORS) system. Avoid using Allow-All.
The Font-Source directive controls content sources of web page fonts imported using the CSS "at-rule" @font-face. Although it is unlikely for an attacker to create a font file that directly attacks a user, there have been a number of vulnerabilities exploited by attackers that target the browser's font generation. Such an attack could compromise a user's browser.
As a best practice, add specific websites, as described above, for Cross Origin Resource Sharing (CORS) requests. Avoid using Allow-All.
The Form Actions directive governs the URIs that can be used as the action of HTML form elements. An attacker who gained access to this directive could submit potentially confidential information to the attacker's website, compromising the user's data.
As a best practice, add specific websites to the Allowed Form Actions list, as described above. Avoid using Allow-All.
The Parent Frame-Source directive allows you to define web sites that can display your application in an iframe. Restricting this permission prevents an attacker framing your application in a malicious site, getting users to visit the site, and logging every keystroke and mouse click the user makes while using your application.
As a best practice, add specific websites to the Allowed Websites list, as described above. Avoid using Allow-All.
The Child Frame-Source directive manages the content sources that your application can include in frames. If an attacker can control one of your frame sources, the frame's source could pull malicious data, including Cross Site Scripting attacks, into your user's browser, compromising that user.
As a best practice, add specific websites to the Allowed Websites list, as described above. Avoid using Allow-All.
The Image-Source directive controls the sources your application can pull images from. Attackers can use the HTML <img> tag to obtain confidential information via a Cross Site Scripting attack, read page content, and make an image request to their own malicious site requesting a non-existent image and appending the page content; the attacker can then view the malicious site's logs to read your page's content.
As a best practice, add a short list of reliable web sites to the Allowed Websites list, as described above. Avoid using Allow-All.
The Media-Source directive manages sources from which your application can download rich media such as videos and audio files. If an attacker can compromise a page to load a malicious object, the user's computer could be compromised.
As a best practice, add specific websites to the Allowed Websites list, as described above. Avoid using Allow-All.
The Object-Source directive manages sources from which your application can download plugins. Plugins include Flash files, Java applets, scripts in other languages, and generic text documents. Given the power of Flash files and Java applets to run any kind of code, if an attacker can compromise a page to load a malicious object, the user's computer could be fully compromised.
As a best practice, add specific websites to the Allowed Websites list, as described above. Avoid using Allow-All.
The Plugin Types directive contains a list of allowed MIME types for plugins. This directive in conjunction with other directives, particularly the Object-Source directive, can ensure that any content loaded is the right kind of content. If an attacker were able to upload malicious content, such as a Java applet, to a source defined in Object-Source, a user could still be compromised; however, if this directive does not explicitly allow applets, that content could not be loaded.
As a best practice, add allowed plugin MIME types to the list, as described above, or leave the list blank and use other directives carefully to ensure a user's safety.
The Referrer directive informs the user's browser under what circumstances to send the Referer Header. The header could be used by an attacker to view the page locations users came from, if a request is made to an outside location from your application. This can disclose some information, but is not directly an attack vector.
As a best practice, select Origin in most cases; or Cross Origin, if you utilize Cross Origin Resource Sharing (CORS) and want to share the referrer information with that other resource location.
The Reflected XSS directive utilizes the browser's built-in capabilities to allow, filter, or block content that the browser thinks may be vulnerable scripts. Some modern browsers have rules that check JavaScript to determine if that content looks like an attack, namely a Cross Site Scripting attack, and report on or block it.
As a best practice, select Filter so the page will still load, but the potentially malicious code will not execute.
The Sandbox directive controls the sandboxing capabilities of a frame. Use this directive in conjunction with the Child Frame-Source directive. If your application has a page that loads content via a frame, use the "sandbox" attribute to define certain abilities of the child frame. If these settings are too permissive, and an attacker is able to load a malicious site via a frame, that site’s content could affect a legitimate user.
As a best practice, leave all options here unselected. Only check individual options if they are absolutely necessary to your application.
The Script-Source directive handles all content relating to the HTML tag to prevent the launch of a Cross Site Scripting attack on your users either by loading content from a malicious source or by directly injecting JavaScript to run on the web page. A guardrail-compliant application should be immune to malicious inline JavaScript, so the primary concern is external content loading.
As a best practice, maintain a short list of good web sites by adding sites to the Allowed Websites list, as described above. Avoid using Allow-All.
The Style-Source directive governs all content relating to the HTML tag <style>. Attackers can use the <style> tag to describe CSS stylesheet content or external sources of stylesheets. While not a direct attack vector, a stylesheet loaded from a malicious site may make your application unusable by overriding content with images, odd colors, or decreasing opacity; or by entirely removing your content.
As a best practice, maintain a short list of good web sites by adding sites to the Allowed Websites list, as described above. Avoid selecting Allow-All.
Security category
Help Home