Egress Filtering Added for Adobe Commerce Starter Merchants

October 2021 saw a significant security enhancement for Adobe Commerce Starter merchants: the introduction of egress filtering, a network-level control mechanism that restricts outbound traffic from the hosting environment. While this feature had long been standard on higher-tier deployments, Starter merchants had been left without equivalent controls, making them vulnerable to malicious extensions or compromised code that might exfiltrate data or make unauthorized external calls.

What Is Egress Filtering?

Egress filtering is a firewall rule set at the network boundary that inspects all outbound connections from a hosting environment and blocks those that don't match an approved allowlist. When a piece of code attempts to make an HTTP request, FTP upload, DNS lookup or other outbound call, the firewall intercepts it and checks:

• Does the destination IP or hostname match an approved endpoint?
• Is the port number allowed?
• Is the protocol permitted?

If the answer is no to any question, the connection is blocked. This happens transparently, at the network layer, before the request ever reaches the intended recipient.

Why This Matters for Security

Preventing data exfiltration: A compromised extension or backdoored third-party library might attempt to send customer data (email addresses, cart contents, payment tokens) to an attacker's server. Egress filtering stops such connections cold, even if the code executes successfully. The attacker may have shell access, but the firewall prevents data leaving the building.

Stopping C&C communications: Malware often tries to 'phone home' to command-and-control servers to receive instructions or report status. Egress filtering prevents this, containing a breach even if malicious code has gained a foothold.

Blocking unauthorized API calls: A buggy or malicious integration might spam external APIs, consuming bandwidth or causing cascading failures. Egress filtering can rate-limit or block entire destination IPs, preventing DDoS-like behavior from inside your infrastructure.

Compliance requirements: Many regulated industries (healthcare, finance, e-commerce processing PCI) have explicit requirements to limit data movement to approved destinations. Egress filtering provides audit-proof evidence that data cannot leave the environment without explicit approval.

How Adobe Implements It

On Adobe Commerce Cloud, egress filtering works as a managed service:

• Default allowlist: Adobe pre-configures an allowlist of critical external services (Adobe's own APIs, major payment processors, shipping carriers, popular CDNs, etc.). Merchants inherit these defaults.
• Custom allowlist: Merchants can request addition of custom endpoints for proprietary integrations or third-party services. Requests are reviewed and whitelisted on approval.
• Real-time logging: All egress attempts (successful and blocked) are logged in the environment's activity monitor, giving merchants visibility into what code is trying to reach externally.
• Alerting: When an egress rule is blocked, merchants can configure alerts to investigate unusual activity immediately.

For Starter merchants, Adobe manages the allowlist and handles adjustments. This is different from on-premise deployments where teams would configure firewall rules directly.

Impact on Merchants and Developers

For merchants: Egress filtering is largely transparent. Legitimate integrations (payment gateways, shipping APIs, marketing tools) continue to work because Adobe's allowlist includes the major players. However, if a merchant installs a custom extension that talks to an unapproved endpoint, the extension will fail silently (or with clear error messages in logs). Troubleshooting requires examining the activity logs and approving the new endpoint.

For developers: Developers who build custom extensions must be aware that their code cannot make arbitrary external calls. When integrating third-party services, they need to:

• Document which external endpoints the extension requires.
• Work with the merchant to request allowlisting of those endpoints.
• Test in staging to ensure all required endpoints are approved.
• Plan for the possibility that some third-party services cannot be whitelisted (e.g., due to security policy or compliance constraints), requiring alternative approaches.

This discipline is good security practice—it forces explicit thinking about what external dependencies code has, rather than allowing arbitrary outbound connections.

Practical Considerations

Dynamic DNS and allowlisting: If a service uses dynamic DNS (IP addresses change frequently), allowlisting by hostname is more robust than allowlisting by IP. Adobe's system supports hostname-based rules, though DNS lookup itself must be to approved nameservers.

Third-party library calls: Developers sometimes use libraries or SDKs that make external calls (e.g., sending telemetry or checking for updates). If that library reaches an unapproved endpoint, the call fails. Developers must audit dependencies and, where necessary, disable external calls in library configuration or choose alternative libraries.

Fallback behavior: When an egress call is blocked, the application should handle the failure gracefully. A missing telemetry call should not break checkout; a failed CDN image request should not crash the storefront. Defensive coding is critical.

Why Starter Merchants Benefit Most

Starter merchants often run tight operations with limited security staffing. They may not have resources to audit every custom extension or third-party integration for security posture. Egress filtering provides a safety net: even if a bad actor compromises one service, the infrastructure prevents it from exfiltrating data or spreading laterally.

For growing merchants who plan to scale to higher tiers (Pro, Business), this feature is a stepping stone toward enterprise-grade security controls. It builds organizational muscle around security discipline early.

Looking Forward

Egress filtering is part of a broader Adobe Cloud security evolution. Other enhancements in this space include:

• Ingress (inbound) filtering and Web Application Firewalls (WAF).
• Distributed denial-of-service (DDoS) protection at the network edge.
• Encrypted inter-service communication within Adobe Cloud infrastructure.
• Regular security patching and vulnerability scanning of base images.

For merchants, the takeaway is clear: modern e-commerce platforms enforce security at multiple layers, not just application code. By adopting egress filtering, Adobe extends control from the application layer to the network layer, closing entire classes of attack even when code is compromised.

Recommendation

If you are a Starter merchant on Adobe Commerce Cloud, take time to review which external services your store requires (payment processors, shipping providers, marketing tools, etc.). Work with Adobe to allowlist those endpoints explicitly. Then test thoroughly in staging to ensure nothing breaks. The upfront effort is minimal, and the security gain is substantial.