Working with clients and partners on Constellation projects, we encounter many questions regarding the security of Constellation applications. One of the most common security concerns raised by clients transitioning to Pega Constellation revolves around the PCore and PConnect APIs. What is the concern? "Anyone can see our sensitive data through browser developer tools, it is all there!”. This concern might stem from a misunderstanding of how security works in modern web applications. Let’s try to clear this up.
Visibility is not security
Constellation uses a client-side orchestration model where the application state is managed in Redux on the browser. This is different from the traditional server-rendered UI model, and it’s causing some confusion. Here’s what is important: visibility is not a security. When a user opens browser developer tools and inspects network traffic or JavaScript console they can monitor DX APIs being invoked. They can indeed see data. But here’s the critical point: they can only see data that the server has determined they are authorized to access.
Constellation is using Redux as a state management tool and indeed the application state is kept within the browser. Redux is not inherently less secure than any other client-side state management approach. The security model doesn’t depend on obscuring client-side data structures; it depends on server-side enforcement of what data reaches the client in the first place.
Server side security
Security in Constellation—and in any properly architected web application—must be enforced server-side. We should not trust client side, whatever is sent to client needs to be checked before exposing any critical data. Any input from client needs to be validated against malicious attempts.
Here’s how Pega implements this (not exhaustive list):
1. RBAC and ABAC Enforcement
When PCore.getDataPageUtils() or any other PCore API accesses data, the Pega Infinity server enforces:
-
Role-Based Access Control (RBAC): Access is granted based on the user’s assigned role
-
Attribute-Based Access Control (ABAC): Fine-grained security based on attributes like department, security clearance, or case sensitivity
The orchestration layer (PCore/PConnect) connects to the Pega Infinity server via the Constellation DX APIs, which validates every data request against these policies. A user can only retrieve data they’re authorized to see. This data might be later visible to the user on screen or stays in Redux. It doesn’t matter as it was earlier determined by the server that this user is authorized to access this data.
3. DX API Input Validation
Here’s a critical security feature that often gets overlooked: you cannot submit data to the DX API with malicious intent because the DX API rejects anything it doesn’t know about.
This means the server validates all incoming data against the defined schema (View definition). Any attempt to inject unknown properties, manipulate data structures, or submit fields that aren’t part of the expected contract gets rejected at the server level. The client can try to send whatever it wants, but the server acts as the gatekeeper—only accepting data that conforms to the defined API contract.
This is fundamental to understanding that client-side visibility doesn’t create vulnerability. Even if someone modifies JavaScript in the browser to attempt malicious data submission, the server won’t process it. It is similar to client and server-side validations we are familiar with from Traditional UI. It is good for UX to validate data on client side to give users early feedback (and improve UX), but it cannot be trusted (as various tooling might be used to construct or modify such transactions). The ultimate gate keeper must be on the server, and DX API does this.
4. Case Type Allowed Fields
Another powerful server-side control is the Allowed Fields configuration on case type. This feature explicitly defines which fields can be modified through the DX API for a given case type. Read more: Pegasystems Documentation
5. Data Page Privileges
As of Pega '25, data page exposure in Constellation is controlled by:
-
API Status: Explicitly marking a data page with API status
-
Data page location within the application architecture – Data Pages from inherited apps by default are not accessible
-
Access limitation by privileges - Pegasystems Documentation
6. DX API Masking
Constellation uses DX API masking to protect sensitive information that might be visible in the client-side state. Combined with server-side ABAC/RBAC, this ensures that even data present in Redux state has already been filtered and masked according to security policies. Read more: Pegasystems Documentation
Trust the server, not the client
Think of it this way: Whatever data is sent to the client means that the user is authorized to see it. If they can access it through PCore APIs, they could also access it through:
-
Network traffic inspection (even in traditional UI)
-
Browser debugging tools
The solution isn’t to hide data at the UI layer—it’s to prevent unauthorized data from reaching the client in the first place. And when data flows back to the server, validate and reject anything that doesn’t conform to the expected contract.
This Article addresses the most common questions about the difference in security model between Traditional and Constellation architecture. It doesn’t provide description of all security measures implemented in platform, among the other:
-
authentication schemes
-
SSL / HTTPS being the on-wire protection
-
CSP – worth checking new out-of-the-box rule provided in Pega 25
-
Use of HttpOnly cookies (so no client code can access / tamper the cookies)
-
XSS protection mechanisms that are built into data handling
-
CSRF token inclusion makes client-side data secure from malicious access by code from third parties.
Conclusion
The key takeaway: visibility in the browser is not a security concern—it’s a feature of how web applications work. What matters is that the Pega server enforces proper access control before any data reaches the client and validates all data coming back from the client.
Constellation 101 Series
Enjoyed this article? See more similar articles in Constellation 101 series.