A little while ago our Constellation application went through a PEN test. As a result we got an advice on how to configure our security headers. I have been investigating the possibilities to configure these security headers via the Pega platform. I haven’t found a constructive answer yet. I hope someone can help me with it.
We have configured the samesite cookie attribute to “Strict”. This takes care of some of the policy behavior but not all I think?
Should I configure a CORS?
The last security header we should implement is the Permissions-Policy. This policy states which browser features are allowed to use. If this is possible in Pega. Where can I configure this?
In traditional UI, the Dynamic System Setting (DSS) Pega-RulesEngine/http/responseHeaders works perfectly for appending custom headers to standard servlet-based HTTP traffic. However, because Constellation relies entirely on the stateless DX API layer, those classic headers are bypassed.
Since the DX API architecture is built on top of Pega’s inbound REST services, you can achieve this by using the specific Service REST DSS instead: Pega-RulesEngine/http/servicerestresponseHeaders.
Adding your custom security headers to this setting will successfully append them to your DX API responses. Just keep in mind that this applies globally—it will inject those headers into all Service REST responses across the system, not just the DX API endpoints.
You can find the implementation details in the Pega Documentation. I feel this is a solid way to enforce headers like Permissions-Policy that aren’t natively handled within standard CORS or CSP rules.
Any thoughts on the Cross-Origin-Embedder-Policy & Cross-Origin-Opener-Policy & Cross-Origin-Resource-Policy. Would this be part of the DSS of is there another rule in Pega we could use to achieve this requirement