Best practice for handling configs.json exposure in Adobe Commerce on Edge Delivery Services storefront

[olsalas711]

Hi everyone,

We are currently implementing an Adobe Commerce on Edge Delivery Services (EDS) storefront connected to AEM Sites as a Cloud Service.

In our current setup, the file https://example.com/configs.json is publicly accessible from the browser.

This file contains environment-related configurations and API endpoints required for the Drop-ins initialization.

While this approach works functionally, it raises a security concern for production environments since the file is exposed and potentially reveals sensitive configuration details.

I would like to know what Adobe recommends as the best practice for handling environment configs and secrets in EDS storefronts.

Specifically:

Should these values be managed through a secure service, such as Adobe App Builder runtime variables?

Is there a supported mechanism to inject configuration dynamically without exposing it client-side?

Would Adobe recommend using a CDN layer (Fastly/Cloudflare) or a proxy to protect this configuration?

Any official guidance, documentation, or examples from production implementations would be greatly appreciated. 

Thanks in advance!

[giuseppebaglio · Accepted solution]

hi @olsalas711,

Adobe explicitly recommends handling backend data access through middleware layers at the CDN/Edge tier:

Browser → Middleware (Edge Worker) → Backend

For sensitive API endpoints and credentials:

1. Configure Edge Workers (Cloudflare Workers, Fastly Compute@Edge, etc.) at the CDN layer

2. Store sensitive API keys and secrets in the Edge Worker environment

3. Implement authentication logic in the middleware

4. Let the middleware manage secure communication with backend systems

This approach keeps secrets server-side while allowing the client to make authenticated requests through the proxy.

Safe to expose in configs.json:

• Public API endpoint URLs (without authentication tokens)

• Commerce service URLs (base paths only)

• Feature flags and environment identifiers

• Non-sensitive configuration keys

Must protect (use middleware):

• API keys and access tokens

• Authentication credentials

• Internal service endpoints