Trusted Proxies and eCDN Request Blocking

When you stack a third-party CDN or proxy in front of B2C Commerce eCDN, the eCDN security feature can mistake the proxy for an attacker and block it. Verify trusted proxy traffic so that legitimate requests aren't blocked.

Which Salesforce Commerce Product Do I Have?

Note Create the custom rule on the eCDN zone that fronts the traffic: a storefront zone, the Default Domain, or the SCAPI zone. Custom rules, including secret header checks, are available on all three. There's one SCAPI zone for Development, Staging, and Production. Configure it only from the Production instance. It doesn't appear in Business Manager or the CDN API on Development or Staging. Scope every SCAPI rule by the org ID in the URL path so that it doesn't affect other environments. See SCAPI Zone Support for B2C Commerce, Default Domain Support for B2C Commerce, and Create a Custom Firewall Rule for an eCDN Zone.

Because all traffic from a stacked third-party proxy reaches eCDN from the proxy's IP addresses, the eCDN security feature can incorrectly identify that proxy as an offending IP address or server. This misidentification can happen, for example, while mitigating a DDoS or application-layer attack. In this case, eCDN blocks the third-party server and affects more users than intended.

Salesforce recommends that you use eCDN custom rules to selectively allow traffic from your trusted proxy without disabling eCDN protections for everyone else. Implement this approach using eCDN custom rules (per zone) to selectively skip the web application firewall (WAF), other custom rules, rate limits, or security levels for specific third-party IP addresses.

Custom rules use a secret extra HTTP header to verify requests. The header is typically attached at the CDN level, and it identifies traffic from your trusted proxy. For example:

x-extra_header_name: extra_header_value

To verify incoming requests, an eCDN custom rule checks for the header and blocks malicious traffic that doesn't include it. All requests that fail the header check return a 403 response code. See eCDN Custom Rule.

You can also add the trusted proxy to the firewall allowlist, but Salesforce doesn’t recommend this method since it bypasses all DDoS and WAF components, including all custom rules, rate limiting rules, and managed rules. If you must use the allowlist approach, add the third-party proxy IP address to a Managed IP Address List, and reference that list in a Custom Firewall Rule with a skip action. For instructions, see Manage IP Address Lists for eCDN Zones.