How do I add IP allowlists and denylists at the API edge?

To add IP allowlists and denylists at the API edge, you typically enforce them before the request reaches your application—for example at an API gateway, reverse proxy, load balancer, or edge firewall.

Common approaches

1) API Gateway / Reverse Proxy rules

Use the edge layer to inspect the client IP and:

• Allowlist: permit only known IPs/ranges
• Denylist: block known bad IPs/ranges
• Return 403 Forbidden for blocked requests

Examples of edge products that support this:

• Kong
• NGINX / NGINX Plus
• Envoy
• AWS API Gateway + WAF
• Cloudflare
• Apigee
• Azure API Management
• GCP API Gateway / Cloud Armor

2) Web Application Firewall (WAF)

A WAF is often the cleanest place for this if you already use one.

• Set IP reputation or custom IP rules
• Maintain allow/deny lists centrally
• Optionally combine with rate limiting and geo rules

3) Network controls

At the infrastructure layer:

• Security groups / firewall rules
• Load balancer source IP filtering
• Private API endpoints/VPN-only access

This is more rigid, but strong for internal APIs.

---

Important implementation details

Identify the real client IP

If you’re behind proxies/CDNs/load balancers, don’t trust X-Forwarded-For unless it’s set by your trusted edge.

Use:

• the edge’s trusted client IP extraction mechanism
• proxy trust configuration
• CDN-specific headers if applicable

Otherwise attackers can spoof IP-related headers.

Normalize CIDR ranges

Store entries as:

• single IPs: 203.0.113.10
• CIDRs: 203.0.113.0/24

Then check:

• exact IP match
• range containment

Decide precedence

If an IP appears in both lists, choose a clear rule, typically:

• denylist wins for security-sensitive systems or
• allowlist overrides denylist, if you want explicit exceptions

Be consistent and document it.

Manage via config or dynamic policy

Good operational options:

• config file + reload
• database-backed policy
• environment-driven config for smaller setups
• centralized policy service for larger systems

---

Example logic

A simple edge policy is:

1. Extract client IP
2. If IP is in denylist → block
3. Else if allowlist is enabled and IP is not in allowlist → block
4. Else allow

Pseudocode:

if ip in denylist:
    return 403

if allowlist_enabled and ip not in allowlist:
    return 403

return request_to_upstream

---

Example with NGINX

You can use allow / deny directives:

server {
    location /api/ {
        allow 203.0.113.10;
        allow 198.51.100.0/24;
        deny all;

        proxy_pass http://backend;
    }
}

This is effectively an allowlist.
For a denylist, you can combine rules, though allowlist-first designs are often cleaner.

---

Example with Cloudflare

Use:

• IP Access Rules
• WAF custom rules
• Firewall rules

Example rule concept:

• If ip.src in {203.0.113.10, 198.51.100.0/24} then allow
• Otherwise block

---

Best practices

• Prefer allowlists for sensitive/private APIs
• Use denylist as a secondary control, not your only defense
• Log blocked requests for auditing
• Support CIDR ranges and automation
• Store policies centrally and version them
• Recheck policies periodically
• Combine with authn/authz, rate limiting, and mTLS for stronger protection

If you want, I can give you:

1. a vendor-specific example (NGINX, Kong, AWS, Cloudflare, etc.), or
2. a language-level implementation for an API gateway/service.