Content Security Policy headers in response
After configuring my application to use a certain Content Security Policy I expect the CSP headers (Content-Security-Policy, X-Content-Security-Policy and X-Webkit-CSP) to be part of every document/xhr response I get from Pega. However, quite a number of (mostly document) reponses do not contain these headers. I haven't figured out a pattern yet, but I'm wondering:
Is there a reason for this behavior? Is there a way to change the behavior so the CSP headers are always part of the response?
***Updated by moderator: Lochan to add SR details***
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
PEG
GB
In order to make sure these header are set, please add the following setting:
Use Pega-Engine as the owning ruleset
prconfig/initialization/httpstreamduringassembly/default with a value of false
In order to make sure these header are set, please add the following setting:
Use Pega-Engine as the owning ruleset
prconfig/initialization/httpstreamduringassembly/default with a value of false
CSP header can potentially get skipped if there is direct streaming enabled.
In order to get CSP header on all request, you can disable direct streaming (via setting above). Performance will degrade slightly because of this.
Pegasystems Inc.
US
Hi,
I can't think of any reason which could cause the header missing issue if they are properly set in the first place.
Where have you set the content security policy headers? At the server (LB level) or at the application level using DSS http/responseHeader?
Some CSP header tag values will vary from browser to browser and version to version, therefore we may not expect all the three headers to appear on all the requests & all the browsers.
To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header (sometimes you will see mentions of the header X-Content-Security-Policy but that's an older version and you don't need to specify it anymore).
Check these specs link on CSP header values & usage in different browsers - https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
Identifying a pattern will certainly help like any browser specific, any functionality/module specific any version specific etc..
Thanks!
Atos
NL
Thank you for your response.
I’ve set the CSP headers by using the Content Security Policy rule type. (I’m using Pega 7.2.2, so the rule supports Content Security Policy level 2.)
After defining my application to use the CSP rule pxDefaultSecured, most responses contain the following headers:
Content-Security-Policy:
base-uri 'self';
child-src 'self';
form-action 'self';
frame-ancestors 'self';
connect-src 'self';
font-src 'self';
frame-src 'self';
img-src 'self' http://www.google-analytics.com https://ssl.google-analytics.com data:;
media-src 'self';
object-src 'self';
script-src 'unsafe-inline' 'unsafe-eval' 'self' http://www.google-analytics.com https://ssl.google-analytics.com;
style-src 'unsafe-inline' 'unsafe-eval' 'self';
default-src *;
report-uri https://myserver:443/prweb/OZn3UKsN2-QtyQsUitxeYFJ5l4ioNxm7*/!STANDARD
X-Content-Security-Policy: base-uri 'self'; child-src 'se…sUitxeYFJ5l4ioNxm7*/!STANDARD
X-WebKit-CSP: base-uri 'self'; child-src 'se…sUitxeYFJ5l4ioNxm7*/!STANDARD
(all three headers contain the same value)
The responses always contain either all or none of the headers, regardless of the browser the request was made in (tested with Chrome, Firefox and IE).
Thank you for your response.
I’ve set the CSP headers by using the Content Security Policy rule type. (I’m using Pega 7.2.2, so the rule supports Content Security Policy level 2.)
After defining my application to use the CSP rule pxDefaultSecured, most responses contain the following headers:
Content-Security-Policy:
base-uri 'self';
child-src 'self';
form-action 'self';
frame-ancestors 'self';
connect-src 'self';
font-src 'self';
frame-src 'self';
img-src 'self' http://www.google-analytics.com https://ssl.google-analytics.com data:;
media-src 'self';
object-src 'self';
script-src 'unsafe-inline' 'unsafe-eval' 'self' http://www.google-analytics.com https://ssl.google-analytics.com;
style-src 'unsafe-inline' 'unsafe-eval' 'self';
default-src *;
report-uri https://myserver:443/prweb/OZn3UKsN2-QtyQsUitxeYFJ5l4ioNxm7*/!STANDARD
X-Content-Security-Policy: base-uri 'self'; child-src 'se…sUitxeYFJ5l4ioNxm7*/!STANDARD
X-WebKit-CSP: base-uri 'self'; child-src 'se…sUitxeYFJ5l4ioNxm7*/!STANDARD
(all three headers contain the same value)
The responses always contain either all or none of the headers, regardless of the browser the request was made in (tested with Chrome, Firefox and IE).
For an example of the behavior I mentioned in my original post I've attached two screenshots (made using Firefox Developer Tools). One image shows the details of a GET document request where the response did contain the headers, and one image shows a GET document request where the response did not contain the headers. Both requests were made by normal interactions with Developer Studio (opening and closing a property rule). All responses to xhr requests that were made contained the CSP headers, but the responses to both the first and second document request did not. However, the third document request did receive the CSP headers in its response.
Why is this? Why are the headers sent when a rule instance is closed but not when it is opened?
Pegasystems Inc.
US
Hi Kyra,
Does this explanation help? When the response comes back for the page, it will contain the whitelisted resource source files it needs to render the page. The CSP definition that comes back in the header for the page will define where those resources can come from. The browser will then use the CSP definition to determine which resources to load. Thus, the resource files (.js, .htm, .css, .ico, etc) response do not need the header as they are requested from the page being rendered which is control by the CSP definition.
Atos
NL
Hi Brad,
Thanks for your explanation.
You say that "The CSP definition that comes back in the header for the page will define where those resources can come from."
I've noticed that the header of the page does not always contain the CSP definition. For example when opening a property rule in Designer Studio. (For screenshot of network activity, see Open property responses.png)
The first 4 requests that are done are XHR requests, followed by two document requests and numerous script and stylesheet requests. If I understand you correctly the response to the document requests should contain the CSP headers, so that the information contained in those CSP headers can be used to determine which resources to load. However, when I open the details of the first document request (see Open property - Document response.png), I see no CSP headers in the Response headers box. But the CSP headers are part of the responses to the XHR requests (see Open property - XHR response.png), so I know they are sent at least some of the time.
So my question is: why are the CSP headers not part of the response to the document request?
Pegasystems Inc.
US
Hi Kyra,
Can you open up an SR for this so it can be looked into further? Please reference this post in the SR and then come back and leave a reply with the SR ID so that we may track for you as well.
Thanks!
Accepted Solution
PEG
GB
In order to make sure these header are set, please add the following setting:
Use Pega-Engine as the owning ruleset
prconfig/initialization/httpstreamduringassembly/default with a value of false
In order to make sure these header are set, please add the following setting:
Use Pega-Engine as the owning ruleset
prconfig/initialization/httpstreamduringassembly/default with a value of false
CSP header can potentially get skipped if there is direct streaming enabled.
In order to get CSP header on all request, you can disable direct streaming (via setting above). Performance will degrade slightly because of this.