How do I do IP allowlisting and denylisting at the API edge?

To do IP allowlisting and denylisting at the API edge, you typically enforce it before requests reach your application, using an API gateway, reverse proxy, load balancer, WAF, or CDN edge.

Core idea

• Allowlist: permit only traffic from approved IPs/ranges.
• Denylist: block traffic from known bad IPs/ranges.
• Best practice is usually default deny + allowlist for sensitive APIs.

Common places to enforce it

1. API Gateway

Examples: Kong, Apigee, AWS API Gateway, Azure API Management, GCP API Gateway
You configure policies/rules such as:

• allow only 203.0.113.0/24
• block 198.51.100.7

Good when you want centralized control per API route or consumer.

2. Reverse proxy / ingress controller

Examples: NGINX, Envoy, HAProxy, Kubernetes Ingress
Use access control directives or filters.

Example with NGINX:

location /api/ {
    allow 203.0.113.0/24;
    allow 198.51.100.7;
    deny all;
}

Denylist example:

location /api/ {
    deny 198.51.100.7;
    deny 198.51.100.0/24;
    allow all;
}

3. CDN / WAF / edge network

Examples: Cloudflare, Akamai, Fastly
Create firewall rules like:

• allow only office/VPN IPs
• block abusive source IPs or ASNs

This is often the fastest place to stop traffic globally.

4. Cloud security groups / firewall rules

Examples: AWS Security Groups, GCP firewall rules, Azure NSGs
Useful for network-level filtering, but usually less flexible for per-API policy than a gateway/WAF.

---

Important implementation details

Trust the real client IP correctly

If you’re behind a proxy/CDN/load balancer, the source IP your app sees may be the proxy’s IP.
You must ensure you’re using a trusted forwarding header setup, such as:

• X-Forwarded-For
• True-Client-IP
• CF-Connecting-IP

Only trust these headers if they come from a trusted upstream you control or a known edge provider.

Prefer CIDR-based rules

Use ranges, not just single IPs:

• 203.0.113.0/24
• 2001:db8::/32

Remember to support IPv6 as well as IPv4.

Decide precedence

A common rule order:

1. Explicit denylist
2. Allowlist
3. Default deny or default allow, depending on your model

For sensitive APIs, use:

• deny overrides allow or
• a strict allow-only model

---

Operational best practices

• Store rules in a centralized config or policy system.
• Log blocked requests with:
  • source IP
  • path
  • rule matched
  • timestamp
• Add rate limiting too; IP control alone is not enough.
• Keep emergency rollback in case you block legitimate users.
• Automate updates for dynamic corporate/VPN IPs.
• Test from allowed and blocked networks before rollout.

---

Security caveats

• IP allowlisting is not strong authentication by itself.
• IPs can be:
  • shared (NAT, CGNAT)
  • dynamic
  • proxied
  • spoofed in some network contexts
• Use it as an additional control, alongside:
  • mTLS
  • API keys
  • OAuth/JWT
  • client certificates
  • device posture checks

---

Recommended pattern

For a protected internal API:

1. Put the API behind a gateway or WAF.
2. Allow only trusted IP ranges/VPN egress IPs.
3. Deny everything else.
4. Add authentication and authorization on top.
5. Monitor and alert on blocked attempts.

If you want, I can show you how to implement this on a specific platform like AWS API Gateway, NGINX, Cloudflare, Kong, or Kubernetes Ingress.