CORS Issue with App Static Server running as separate EC2 Instance

General
1

Hello Experts,

Greetings.

Need help around security issue security raised during pen testing.

  1. We are using Pega Constellation application running on AWS cloud in EC2 instance.
  2. We are having App Static Service running as container on separate EC2 instance.
  3. We have customer components publish to App static service.

Security team raised the concern during pen testing that components can be accessed using any domain which is security risk. They are saying this app static service is allowing request from all origin, with all methods and client credential = true.

Additionally, App static service is running behind AWS Application Load Balance which mean from Pega Application we are accessing this service via ALB.

Is any one faced similar issue, please guide - how we can stop access to app static service from any origin?

Regards,

Shivam Garg

3

Hi Shivam,

We have encountered this same behaviour in Constellation and the key point is that it is not caused by the Pega application or the AppStatic service itself.

In Constellation architecture, all static UI assets under

/c11n-appstatic/*

are not served by the Pega engine. They are delivered directly by whatever load balancer or reverse proxy sits in front of the environment (for example AWS Application Load Balancer).

Because of that

1. Pega CORS rules do not apply to AppStatic

Pega’s CORS configuration is only evaluated for

  • REST endpoints

  • DX API calls

  • /api/* paths served by the Pega runtime

AppStatic requests do not reach the Pega engine, so Pega cannot control the CORS headers for them.

2. The CORS behaviour you are seeing is coming from the load balancer

If the load balancer is configured with:

  • Origin reflection

  • Wildcards (*)

  • Access-Control-Allow-Credentials: true for all Origins

  • Or broad header/method mappings

…then it will appear as if AppStatic “allows all origins”, even though Pega has no involvement.

This matches exactly what we saw, the LB was dynamically reflecting the Origin header.

3. The fix must be applied at the load balancer / reverse proxy

To lock this down, configure CORS at the LB (or reverse proxy) using non‑reflective, allow‑listed rules, for example:

  • Set Access-Control-Allow-Origin to explicit trusted origins only

  • Do not reflect $http_origin or ${origin}

  • Restrict methods to GET and OPTIONS (static assets don’t need POST)

  • Keep allowed headers minimal

  • Return 403 or omit ACAO for untrusted Origins

  • Scope rules only to /c11n-appstatic/* so API traffic is unaffected

Once the LB is configured with a strict allow‑list, the issue is resolved.

4. Important reassurance

AppStatic contains only static Constellation UI resources (JS bundles, CSS, component metadata, images, localisation files).
It does not contain case data, user data, or API responses, so the concern is around CORS misconfiguration, not sensitive data exposure.

Pega SR Reference : INC-D12705

4

Thank you so much @Sakthivel for great clarification. It clears my understanding. Hopefully this will help other members in this forum as well.