ESA Unlocked: Origin Protection - Stop Attackers from Bypassing Your CDN

Attackers can bypass ESA and hit your origin directly. Origin Protection whitelists ESA POP IPs at your load balancer or firewall, so only vetted traffic gets through.

Stop Attacks at the Door, Not at the Edge

Most ESA users invest heavily in edge security: WAF rules, DDoS mitigation, bot management. These work well - as long as traffic actually passes through ESA.

The problem is that attackers do not always enter through the front door. If your origin's IP address is discoverable, an attacker can send traffic directly to it, bypassing every security control configured at the edge. Your WAF, DDoS protection, and bot rules become irrelevant because the malicious traffic never touches them.

This is not a theoretical risk. Origin IPs leak through DNS history archives, SSL certificate transparency logs, forgotten subdomains, and misconfigured email headers. Once exposed, the address is out there forever.

Most mature teams already protect their origin with an entry layer - an Alibaba Cloud Server Load Balancer (SLB), a WAF appliance, or both. The load balancer handles traffic distribution and health checks; the WAF filters malicious requests; the origin pool sits behind a controlled boundary. But if that entry layer still accepts traffic from anywhere on the internet, you have moved the front door, not locked it. The attacker simply targets the load balancer or WAF IP instead of a backend server IP.

Origin Protection closes this gap. It ensures that your origin entry layer - whether that is an ALB, CLB, NLB, WAF endpoint, or host firewall - only accepts traffic from ESA's Points of Presence (POPs). Everything else is dropped before it reaches your application.

esa_origin_exposure_risk

How Origin IPs Get Exposed

You might assume your origin IP is private. In practice, it has probably been public at least once. Here are the most common leak paths:

Leak Source	How It Happens	Why It Persists
DNS history services	SecurityTrails, ViewDNS.info, and similar tools archive DNS records indefinitely.	If your domain ever pointed directly to your origin - even for a day during setup - the record is stored forever.
SSL certificate transparency logs	Certificate Authorities log every issued certificate publicly.	Attackers scrape these logs, extract domain names, and resolve them to find origin IPs.
Forgotten subdomains	`dev.example.com`, `staging.example.com`, or old microsites bypass ESA.	These subdomains often point directly to the origin and are never cleaned up.
Email headers	Application servers send mail directly from the origin.	SMTP headers can expose the origin IP if not routed through a third-party mail service.

Once an attacker has the origin or load-balancer IP, they can send DDoS traffic directly, probe for vulnerabilities without triggering WAF rules, exploit origin weaknesses that ESA would have blocked, or cause outages while ESA dashboards report that everything is fine. The result is the same: your edge security investment is undermined by a single exposed address.

How Origin Protection Works

Origin Protection is conceptually simple: allow inbound traffic only from ESA's POP IP addresses. Drop everything else.

When you enable Origin Protection, ESA provides a consolidated list of POP IP addresses (IPv4 and IPv6).
You add those addresses to the IP allowlist on your origin entry layer - load balancer ACL, Cloud Firewall, security group, or host firewall.
All non-ESA traffic is rejected before it reaches your application.

Even if an attacker discovers your origin or load-balancer IP, their traffic cannot get through. The only path to your origin is through ESA, where WAF, DDoS, bot management, and custom rules all apply.

Before You Begin: Tiered Cache

Prerequisite: Origin Protection requires a caching architecture with at least two tiers. If your Tiered Cache policy is set to Edge Tiered Cache (single tier), you cannot enable Origin Protection - ESA's back-to-origin traffic would come from too many POP IPs to whitelist effectively.

To fix this, hover over the Configure button and click Modify in the tooltip to jump to the Tiered Cache page:

esa_op_tieredcache_prereq

On the Tiered Cache page, click Configure, select a multi-tier caching architecture (Regional, Smart, or Cache Reserve), and then you can enable Origin Protection:

esa_op_tieredcache_select

Step 1: Enable Origin Protection in the ESA Console

The core of Origin Protection happens in the ESA console - you turn the feature on and copy the POP IP list, then apply that list wherever your origin lives.

In the ESA console, select Websites. In the Website column, click the target website.
In the left-side navigation pane, choose Security > Origin Protection.
On the Origin Protection page, click Configure.
Turn on the Status switch. In the dialog box, select I understand the risks and click OK.
After it is enabled, ESA displays the consolidated origin-fetch IP list. Click the copy icon to grab all IPv4 and IPv6 CIDR blocks.
Add the IP ranges to your origin's allowlist. The exact place depends on your architecture - pick one of the four options below.

Important: If you stop using ESA, you must manually remove these rules from your origin firewall to prevent access disruptions.

Step 2: Where to Enforce the Whitelist

There is no single "correct" place to apply the list. Enforce it at the outermost layer that only ESA talks to - everything behind it then inherits the protection.

Enforcement Point	Best For	Maintenance	IP-List Updates
Load Balancer ACL (ALB / CLB / NLB)	Origins behind an Alibaba Cloud SLB	Low - configured in the LB console	Manual
Cloud Firewall	Multi-origin, hybrid, or regulated environments	Low - fully managed address book	Automatic
ECS Security Group	Origins running directly on ECS, no LB in front	Medium	Manual (update Prefix List)
Host firewall (iptables, firewalld)	On-premise or non-Alibaba Cloud origins	High	Manual (re-apply rules)

Option A: Load Balancer ACL (ALB / CLB / NLB)

If your origin already sits behind an Alibaba Cloud load balancer, the load balancer's access control list is the cleanest enforcement point - no deeper firewall changes.

In the ALB console, go to Access Control, select your region, and click Create ACL. Name it esa-origin-pops and add the ESA POP CIDR blocks as ACL entries.
Go to Instances, select your ALB, open the Listener tab, click Enable under Access Control, choose Whitelist, select the esa-origin-pops ACL, then Save.

Whitelist mode means the listener allows access only from IP addresses in the ACL and denies all other requests. The same pattern applies to CLB (access-control whitelist) and NLB (ACL association).

Option B: Cloud Firewall (Automated)

ESA is integrated with Cloud Firewall. If your origins are all on Alibaba Cloud and you use Cloud Firewall, enable Origin Protection and then turn on the Auto-apply Latest Origin Fetch IP List switch - Cloud Firewall then updates the origin-fetch IP information automatically.

esa_op_cloud_fw_auto

Then create an inbound rule in Cloud Firewall > Access Control > Internet Border Firewall:

Source: Address Book → Cloud Service IP Address Book → ESA Back-to-Origin Address
Destination: Your origin IP or CIDR
Protocol: TCP (or ANY) · Port: 443 and/or 80 · Action: Allow · Priority: Highest

Add a second rule to deny all other inbound traffic to those ports. When ESA adds or removes POPs, the address book updates on its own - no manual edits.

Option C: ECS Security Group (Detailed)

If your origin is an ECS instance, use Prefix Lists so you can whitelist both IPv4 and IPv6 ranges in one object.

Go to the ECS console > Prefix lists page.
Switch to the region where your origin instance is located.
Click Create prefix list for IPv4: name it list-esa-ipv4, Address family = IPv4, Max entries = 200, then paste the IPv4 CIDR blocks from the ESA list under Prefix list entries and click OK.
Repeat for IPv6: name it list-esa-ipv6, Address family = IPv6, Max entries = 200, paste the IPv6 blocks, click OK.
Go to ECS console > Security groups > Create security group. Select the VPC, delete the default rules, click Add Manually, and set the Authorization object to the two prefix lists you created for the service ports (e.g., 443).
Go to ECS console > Instances, click the target instance ID, open the Security groups tab, and click Change security groups.
Select only the security group you just created, then click OK.

esa_op_ecs_change_sg2

Option D: Host Firewall (iptables / firewalld)

For on-premise or non-Alibaba Cloud origins, apply the whitelist directly on the host.

iptables:

# Allow ESA POPs (example - use your actual list)
iptables -A INPUT -p tcp -s 47.245.0.0/16 --dport 443 -j ACCEPT
iptables -A INPUT -p tcp -s 8.209.0.0/16 --dport 443 -j ACCEPT
# Add all other CIDR blocks...

# Drop everything else
iptables -A INPUT -p tcp --dport 443 -j DROP

firewalld:

firewall-cmd --permanent --new-ipset=esa-pops --type=hash:net
firewall-cmd --permanent --ipset=esa-pops --add-entry=47.245.0.0/16
firewall-cmd --permanent --ipset=esa-pops --add-entry=8.209.0.0/16
# Add all entries...

firewall-cmd --permanent --add-rich-rule='rule source ipset=esa-pops port=443 protocol=tcp accept'
firewall-cmd --permanent --add-rich-rule='rule port=443 protocol=tcp drop'
firewall-cmd --reload

Important: Test firewall rules in a staging environment before applying them to production. A misconfigured DROP rule can take your origin offline.

esa_origin_protection_architecture

Update the Origin-Fetch IP List

When ESA POP addresses change, ESA notifies you by internal message or email. You must update your origin firewall or security group so ESA can keep reaching your origin.

In the ESA console, open the target website and go to Security > Origin Protection.
In the Origin Protection section, add all new IP address ranges to your origin allowlist, then click Review.
In the Review Latest IP List panel, click I Have Applied and Confirm to Enable the Latest IP List, then OK.

esa_op_update_confirm

Note: The new list takes effect only after you confirm it. Until then, ESA keeps using the previously confirmed list. Confirm Cloud Firewall's auto-apply is on if you want this handled without manual steps.

Disable Origin Protection

To prevent service interruptions, first remove the IP allowlist from your origin firewall, then disable Origin Protection - not the other way around.

In the ESA console, open Security > Origin Protection, click Configure, and turn off the Status switch. Select I understand the risks and click OK.
The status changes to Disabled.

Things to Watch Out For

Functions and Pages Use Pre-Convergence IPs

The IP list from Origin Protection consists of converged node IPs, but fetch() calls from ESA Functions and Pages actually use pre-convergence node IPs. If a site called by fetch() does not have Origin Protection enabled, the real origin-pull IP of that fetch() is not in the converged list.

Heads-up: If your Functions call a site that also sits behind ESA, enable Origin Protection on that target site. If it is not on ESA, add the Functions egress IP ranges to the origin allowlist.

Too Many IP Ranges? Use Back-to-Origin Convergence

If Origin Protection returns more IP ranges than your origin can configure, ask your sales representative to enable back-to-origin convergence (Enterprise plan only). This further reduces the number of back-to-origin ranges.

Note: Fewer ranges means fewer back-to-origin POPs, which can reduce access quality. Enable this feature with caution.

Always Clean Up Before Leaving ESA

If you move traffic off ESA - for example, by pointing DNS directly to your origin - update or remove the allowlist before disabling ESA. If the entry layer still only accepts ESA POPs but ESA no longer proxies traffic, legitimate requests get dropped.

Real-World Scenarios

Finance: Compliance-Driven Origin Lockdown

A regional bank uses ESA to protect its online banking platform. Its PCI DSS framework requires that all inbound traffic to cardholder data environments be logged and filtered. Before Origin Protection, auditors flagged a gap: the origin remained accessible from untrusted networks. By whitelisting only ESA POPs at the load balancer, the bank demonstrated that 100% of inbound traffic was pre-filtered by ESA's security stack, and the audit finding closed immediately.

Gaming: DDoS Last Line of Defense

A mobile gaming company runs its servers behind ESA and is a frequent DDoS target. During one attack, the attackers found the origin IP through a forgotten staging subdomain and sent a 50Gbps flood directly to the game server, bypassing ESA entirely. After implementing Origin Protection, a repeat attack hit the whitelist and was dropped instantly - the servers never saw it. ESA stops attacks at the edge; the whitelist catches anything aimed at the door.

SaaS: Multi-Tenant Isolation

A B2B SaaS platform serves hundreds of customers from shared origin infrastructure, using ESA's WAF to enforce tenant-specific policies via the Host header. If an attacker finds the origin IP, they can craft the right header and reach any tenant directly. Origin Protection forces all traffic through ESA's policy engine, so tenant isolation cannot be circumvented at the origin.

esa_business_security_value

Plan Availability

Plan	Origin Protection
Entrance (USD 0/month)	Not supported
Pro (USD 15/month)	Supported
Premium (USD 249/month)	Supported
Enterprise (custom)	Supported

The Entrance plan does not include this feature, since POP IP whitelisting requires the multi-tier cache architecture that Pro and above provide.

What's Next?

With Origin Protection configured, your origin is only accessible through ESA.

But what if your users are in mainland China and your origin is in the US or Europe? You then face a compliance puzzle (data residency) and a performance puzzle (cross-border latency). Cross-border acceleration solves both, and it is the topic of the next article in this series.

Resources:

Community