Egress filtering comes to Adobe Commerce Starter

Adobe Commerce Starter merchants now get egress filtering, blocking outbound traffic to anything not on the allowlist.

Egress filtering comes to Adobe Commerce Starter

In October 2021 Adobe brought egress filtering to Adobe Commerce Starter merchants: a network-level control that restricts outbound traffic from the hosting environment. Higher tiers had it already. Starter merchants had no equivalent, which left a compromised extension free to send data wherever it liked.

What egress filtering does

It is a firewall rule set at the network boundary. Every outbound connection, whether an HTTP request, an FTP upload or a DNS lookup, is inspected before it leaves:

  • Does the destination IP or hostname match an approved endpoint?

  • Is the port allowed?

  • Is the protocol permitted?

Any no, and the connection is blocked. It happens at the network layer, transparently, before the request reaches anyone.

Why it matters

Data exfiltration. A compromised extension or a backdoored library may try to post customer data — email addresses, cart contents, payment tokens — to an attacker's server. Egress filtering stops the connection even though the code ran. The attacker may be inside; the data still does not leave.

Command and control. Malware phones home for instructions or to report status. Blocking that outbound call contains the breach rather than letting it develop.

Runaway API calls. A buggy or malicious integration hammering an external API burns bandwidth and cascades failures. Egress rules can rate-limit or block the destination outright.

Compliance. Regulated environments — healthcare, finance, anything in PCI scope — often require data movement to be limited to approved destinations. Egress filtering is the audit evidence that it is.

How Adobe implements it

On Adobe Commerce Cloud it runs as a managed service:

  • A default allowlist. Adobe pre-approves the critical external services: its own APIs, major payment processors, shipping carriers, popular CDNs. You inherit those.

  • Custom entries. Endpoints for your own integrations and third-party services can be requested, reviewed and added on approval.

  • Logging. Every egress attempt, allowed or blocked, is logged in the environment's activity monitor. That log is the first honest inventory of what your code actually talks to.

  • Alerting. Blocked rules can raise an alert, so unusual activity gets looked at that day rather than that quarter.

For Starter merchants Adobe manages the allowlist and makes the adjustments, which is different from on-premise deployments where the team writes the firewall rules itself.

What changes for merchants and developers

For merchants, it is mostly invisible. Payment gateways, shipping APIs and marketing tools keep working, because the major players are on the default allowlist. What changes is the failure mode. Install an extension that calls an unapproved endpoint and it will fail, sometimes silently. The activity log tells you which endpoint, and it gets approved.

For developers, arbitrary outbound calls are over. That means documenting which endpoints an extension needs, working with the merchant to get them allowlisted, testing in staging with the approvals in place, and having a plan for services that cannot be allowlisted at all.

That discipline is not a tax. Knowing exactly what your code reaches out to is a question most codebases cannot answer, and this forces the answer.

Practical considerations

Dynamic DNS. Where a service changes IP addresses frequently, allowlist by hostname rather than by IP. Adobe supports hostname-based rules, though the DNS lookup itself has to go to approved nameservers.

Library calls. SDKs and libraries send telemetry and check for updates without telling you. Audit your dependencies, disable those calls in configuration where you can, and choose a different library where you cannot.

Failure behaviour. When an egress call is blocked, the application has to cope with it. A missing telemetry call must not break checkout. A failed CDN image request must not take the storefront down. Code defensively.

Why Starter merchants gain the most

Starter merchants run lean, usually without the staff to security-review every custom extension and third-party integration. Egress filtering is the safety net: compromise one service and the infrastructure still stops the data leaving or the attack spreading sideways.

It is also good practice ahead of Pro or Business, where the same class of controls is waiting for you.

What this means for you

If you are a Starter merchant on Adobe Commerce Cloud, take the time to list the external services your store genuinely needs — payment processors, shipping providers, marketing tools — get them allowlisted explicitly, and test the lot in staging. It is a small piece of work set against a whole class of attack you no longer have to think about.