Restricting API Access by IP and Network Rules

Not every API needs to be reachable from the whole internet. When a trusted set of callers is stable, IP-based access control is one of the cheapest and most effective security layers you can add. This post walks through allow-lists, deny-lists, matching logic, and where IP controls fit relative to other defenses.

What IP rules actually protect

IP filtering protects against **unauthenticated** requesters — scanners, cred-stuffing bots, and random internet noise. It does not protect against a legitimate IP whose credentials leaked. Treat IP rules as a coarse gate in front of, never instead of, authentication. Correctly ordered, they cut your attack surface by dropping everything outside the trust boundary before your app code even runs.

Think of it as defense in depth: the network layer rejects unknown sources, the TLS layer protects in transit, and the app layer verifies identity.

Allow-list beats deny-list

A deny-list (block known-bad IPs) is a losing game — the internet has far more unknown-bad actors than known ones, and a single modern scan rotates through many address blocks. An **allow-list** is the inverse: you enumerate who is permitted and reject everyone else with a default-deny. It is far stronger and simpler to reason about, at the cost of being unusable when your caller set is genuinely open and unbounded.

For public APIs where an allow-list is impractical, keep the deny-list for obvious offenders and lean on rate limits and authentication to do the heavy lifting. For internal admin endpoints or trusted partner integrations, allow-lists are the recommended default.

Two practical realities temper every IP rule. First, always account for IPv6 alongside IPv4, or you will allow a caller through simply because you only checked one address family; block metadata and private ranges in both. Second, remember that IP is an attribute, not an identity — behind a large NAT or a cloud egress pool, many legitimate callers share one source address, so an allow-list built for a single machine can accidentally block an entire office, and a revoke decision aimed at one abuser can take out innocent neighbors sharing that address. Treat IP rules as a blunt geographical-and-operator filter used in conjunction with authentication, not as a substitute for it.

Implementing it at the reverse proxy

The cleanest place is your reverse proxy or edge firewall, before requests reach app code. Here is an nginx-style location guard that allow-lists only internal and partner ranges for an admin path.

location /api/admin/ {
    allow 10.0.0.0/8;
    allow 203.0.113.0/24;
    deny all;
    proxy_pass http://127.0.0.1:8080;
}

Filtering at the application layer

For callers behind unpredictable NAT or when you need per-call decisions, filter in code. This Python example checks both an exact source IP and a CIDR for a known office range, tightening the boundary for a sensitive operation.

import ipaddress

TRUSTED = ["192.168.7.0/24", "203.0.113.0/24"]

def source_allowed(client_ip):
    try:
        addr = ipaddress.ip_address(client_ip)
    except ValueError:
        return False
    for block in TRUSTED:
        if addr in ipaddress.ip_network(block):
            return True
    return False

def admin_required(request):
    if not source_allowed(request.remote_addr):
        raise PermissionError("source not trusted")

Watch out for proxies

If your API sits behind a load balancer, the client IP is not 'request.remote_addr'. Read the real client address from a trusted 'X-Forwarded-For' header value set only by your proxy — never trust a client-supplied header directly, or anyone can spoof their way into the allow-list. Prefer private networking when your callers live inside your own infrastructure.

Takeaway

Default-deny with an allow-list is dramatically stronger than chasing bad IPs. Apply it at the proxy for simple groups and at the app layer when you need finer control, and always read the real client address through your trusted proxy. Netbay VPS instances give you both public and private-side options to build this boundary — netbayhosts.in.