A list of IPs you trust. A list of IPs you don’t. Allow the first, block the second, done. That’s the basic idea of IP allowlists and blocklists, and at small scale it works fine. At any scale beyond that, the simple version gets you in trouble.

This post covers the practical patterns: when allowlists work, when blocklists work, why ASN-based rules often beat raw IP lists, and the operational pitfalls that bite teams trying to maintain large lists.

Definitions

Allowlist (formerly “whitelist”): A list of IPs explicitly permitted. Everything else is blocked.
Blocklist (formerly “blacklist”): A list of IPs explicitly blocked. Everything else is allowed.

The two are opposites of the same primitive. The choice between them depends on whether you know in advance who should access your service or whether you can only react to who shouldn’t.

When Allowlists Make Sense

Allowlists work when the legitimate users are a known, finite set:

Internal admin panels

You have ten employees who should access admin.example.com. Allowlist your office IPs and VPN IPs. Block everything else.

B2B API integrations

Your customer’s backend calls your API from a known IP range. Allowlist that range. Reject all other source IPs.

Database / service-to-service connectivity

Database accepts connections only from your application servers’ IPs. Same pattern, applied to private networking.

Compliance-driven environments

Some regulations (PCI-DSS, certain government environments) require allowlist-based access to specific resources.

When allowlists work, they’re the strongest possible defense — you’ve collapsed the attack surface to “do you have an IP on the list.” Spoofing source IPs over TCP isn’t trivial; for L7 traffic over established TCP sessions, it’s effectively impossible from the open internet.

The maintenance problem

Allowlists need to stay current. Employees travel, ISPs assign new IPs, customers change their infrastructure. The day you make a major release while an admin is at a hotel that’s not on the allowlist is the day you discover your allowlist is brittle.

Better patterns:

VPN-gated access — Employees connect to a corporate VPN; the allowlist is just the VPN’s IP. Travel doesn’t matter.
Identity-aware proxy — Replace IP-based allowlist with Google Cloud IAP, Cloudflare Access, or similar. Authentication-based instead of IP-based.
Bastion hosts — All access goes through a known bastion, which is the only IP on your service’s allowlist.

For modern production, “VPN + identity-aware proxy” is the pattern. Raw IP allowlists are a fallback for legacy systems.

When Blocklists Make Sense

Blocklists work when you’ve identified specific abusers and want to deny them specifically:

Known abusers

A specific IP or range has been confirmed sending fraudulent signups, scraping, or attacks. Block that IP. This is straightforward and effective for the specific case.

Threat intel feeds

Commercial and free threat-intel providers publish lists of known-bad IPs: malware C&C, spam sources, DDoS contributors. You subscribe and block.

Bot networks

Known scraping botnets, residential proxy networks used for fraud, datacenter ranges associated with abuse.

Geo blocklists

Block traffic from countries where you don’t operate. See geofencing 101 for the geographic angle.

The problem: scale

A blocklist of 10 IPs is trivial to manage. A blocklist of 10 million IPs (typical for a meaningful threat-intel feed) is non-trivial:

Lookup cost. A single check needs to scan a large data structure. Use trees / radix tries (ip-set libraries do this) rather than naive lists.
Update cadence. Feeds change daily; you need a refresh pipeline.
Memory footprint. Storing tens of millions of IPs in your process eats RAM.
False positives. Threat-intel feeds have noise. Blocking a /24 because one IP in it spammed once locks out 254 innocent users.

For production, you usually push this off the application path entirely — into your CDN’s WAF (Cloudflare’s IP Access Rules, AWS WAF’s IP sets) — so your application code never sees the request.

Why ASN-Based Rules Often Beat Raw IP Lists

A common pattern: instead of maintaining a list of 50,000 bad IPs, maintain a list of 100 bad ASNs.

ASNs are the network operator level — see what is an ASN. Examples:

Hosting ASNs like AWS (16509), DigitalOcean (14061), OVH (16276) — real users aren’t browsing from these.
Residential proxy networks like Luminati / Bright Data — known to be used for scraping.
Specific bulletproof hosters — known to be used for malware infrastructure.

A rule like:

IF asn.type == 'hosting' AND endpoint == '/signup'
    THEN block OR challenge

is much more compact and resilient than maintaining a list of every IP belonging to every hosting provider. The IPs change; the ASN doesn’t.

This is one of the main reasons IP intelligence APIs include ASN data inline. The Ip2Geo API returns ASN and classification with every lookup; using ASN-based rules is one cheap API call per request.

Lookup Performance

For any non-trivial list size, the data structure matters.

Naive list

if (badIps.includes(ip)) block()

O(n) per check. Acceptable for 10 IPs. Catastrophic for 10 million.

Hash set

const badSet = new Set(badIps)
if (badSet.has(ip)) block()

O(1) per check. Fine for single-IP entries. Doesn’t handle ranges.

Radix trie (for CIDR ranges)

For lists that contain ranges (10.0.0.0/8, 192.168.0.0/16), use a library that builds a radix trie. ip-set, cidr-matcher, ip-trie in Node; pyradix, netaddr.IPSet in Python; nftables sets in the kernel.

For tens of millions of IPs the trie approach is the only one that scales to single-digit microsecond lookups.

Bloom filter (probabilistic)

For very large lists where occasional false positives are acceptable (you confirm with a real lookup after a positive hit), a Bloom filter gives constant-time membership tests at very small memory cost. Use as a pre-filter before the real list lookup.

Update Pipelines

A blocklist that doesn’t update is a blocklist that’s slowly drifting from reality. You need:

Source feed — Where the data comes from. Threat-intel provider, internal abuse signals, manually curated.
Fetch + validate — Pull the feed on a schedule, validate it parses correctly.
Diff and apply — Calculate what changed since last update, push only the diff if your data store supports it.
Rollback — If the new list is broken (e.g., suddenly contains 10x more IPs because the feed glitched), roll back automatically.
Monitoring — Alert when an update fails or is delayed.

For production, much of this can be handled by your CDN’s WAF or rate-limit service. Cloudflare can pull threat-intel feeds directly into IP Access Rules. AWS WAF has Managed Rule Sets. Building your own is for cases where the WAF can’t accommodate your needs.

False Positive Management

The hardest part of blocklists isn’t the technology; it’s deciding who to unblock.

When a legitimate user complains they can’t access your service:

Verify their IP against your blocklist.
Check why the IP was blocked. Old feed entry? Recent abuse from the IP? Shared IP / CGNAT issue?
Decide whether to remove. If the abuse was 6 months ago and seems unlikely to recur, remove. If it’s recent, escalate to your security team.
Audit the removal. Log who removed what and why. Some attackers will social-engineer support to get removed.

The natural lifecycle of a blocklist is “additions accumulate, removals don’t happen, eventually you block a meaningful fraction of legitimate traffic.” Schedule periodic reviews to expire old entries.

CGNAT and the “Block a /24” Problem

Many mobile networks use CGNAT — thousands of users share a single public IP. If you block one bad actor’s IP, you block thousands of legitimate users behind the same NAT.

Mitigation:

Don’t block by single IP for endpoints heavily used by mobile traffic. Use shorter timeouts or rate limits instead.
For known mobile carrier ASNs, prefer per-account rate limits over per-IP blocks.
Use behavioral signals, not just IP, for high-stakes decisions.

A “block the whole /24” approach amplifies this problem. Only do it when you’re sure the entire range is hostile (e.g., a confirmed-malicious hosting subnet).

Allowlist + Blocklist Combinations

For some services, the right answer is:

Allowlist specific known-good sources (CDN IPs, integration partners, internal services) — bypass all checks.
Blocklist known-bad sources — reject all checks.
Default policy for everything else (rate limited, challenged, or allowed depending on risk).

The pseudo-code:

const allowList = new Set([...])
const blockList = new Set([...])

if (allowList.has(ip)) return next()
if (blockList.has(ip)) return reject()

// Default: standard rate-limit + risk-scoring
return riskScore(ip) > THRESHOLD ? challenge() : next()

This composes naturally and lets you tune each layer independently.

Threat Intel Sources

If you need a blocklist feed, options in 2026:

Public free feeds: Spamhaus DROP, Emerging Threats, FireHOL IP lists. Quality varies.
Commercial feeds: Recorded Future, Spamhaus paid lists, IBM X-Force, CrowdStrike. Quality is generally higher; price scales with size.
CDN-included lists: Cloudflare and AWS WAF have managed rule sets that include threat intel. The cheapest path if you already use the CDN.
Hosting/cloud ASN lists: Free, easy to maintain, surprisingly effective. (Ip2Geo classifies these inline.)

For most teams, “use a major CDN’s managed rules + ASN-based filtering” gives you 90% of the value with very little work.

TL;DR

Allowlists work when legitimate users are a known set. VPN + identity-aware proxy beats raw IP allowlists.
Blocklists work for specific known abusers. They drift over time and need maintenance.
ASN-based rules are more compact and resilient than raw IP lists for many use cases.
Performance matters at scale. Use radix tries for CIDR-range lookups, Bloom filters for huge lists.
CGNAT means blocking an IP often blocks many users. Prefer rate limits or per-account blocks.
Don’t build your own threat-intel pipeline if your CDN provides equivalents.
Schedule blocklist reviews to remove stale entries.

For application developers, the practical sweet spot in 2026 is: CDN-level WAF for the heavy lifting, ASN-based decisions in application code, and well-bounded IP-specific blocks only when you have direct evidence. The Ip2Geo API returns ASN classification inline with every geo lookup so application-layer decisions are one call away. See also fraud detection and VPN/proxy blocking for related patterns.

IP Blocklists and Allowlists: Best Practices for Maintaining Them at Scale