CIDR Allowlist Risk Checker

Every IP allowlist is a small permission boundary written as network text. It tells a firewall, gateway, application, web server, or SaaS control that traffic from named source addresses may reach a protected resource. That exception can be reasonable for partner API egress, a VPN pool, a monitoring platform, or a short break-glass window, but it also creates a path that must stay narrow, owned, and reviewed.

CIDR notation makes allowlists compact enough to paste into tickets and spreadsheets. The number after the slash is the prefix length, which says how many leading bits are fixed as the network portion. A longer prefix is narrower: an IPv4 /32 is one address, while a /24 is 256 addresses. A shorter prefix is broader: 0.0.0.0/0 covers the entire IPv4 address space, and broad IPv6 prefixes can describe more possible sources than a human reviewer can reason about from the address alone.

Source allowlist

A list of source IP addresses or CIDR ranges that may reach a destination, listener, route, or application control.

Prefix length

The slash value in CIDR notation. Smaller slash values usually mean larger address ranges.

Special-use range

Address space reserved for private networks, documentation, loopback, link-local use, multicast, benchmarking, or other non-public purposes.

Review date

The date by which a temporary or sensitive exception should be removed, renewed, or reapproved.

Range size is only one part of the review. The same /24 may be a reasonable partner NAT block for HTTPS, a poor fit for direct database access, or meaningless on an internet-facing rule if the address space is reserved for documentation. Ports, destination sensitivity, ownership, temporary access dates, provider-list freshness, and overlapping rules all change how risky a source exception looks.

A common mistake is treating an allowlisted source as a trusted identity. Source IP controls can reduce random exposure, but they do not replace authentication, authorization, patching, service hardening, logging, or provider range maintenance. When traffic comes through a proxy, load balancer, VPN concentrator, or cloud edge, the effective source address may also be the intermediary rather than the person or system that initiated the request.

Good allowlist hygiene keeps the smallest practical source range, a clear owner, a current justification, and a date for review or removal. That evidence matters most for administrative ports, database ports, all-port rules, broad provider ranges, and copied emergency exceptions that were never meant to become permanent.

How to Use This Tool:

Start with the allowlist exactly as it appears in the review material, then add the policy context that explains what the ranges are allowed to reach.

1. Paste CIDR rows into Allowlist CIDRs, or use Browse for a text or CSV file under 512 KiB. One CIDR per line works, and CSV rows can include label,cidr,ports,owner,expires,note. Bare host addresses are treated as /32 or /128 entries.
2. Fill Reviewed ports with the default service ports for rows that do not include their own port list. Row-specific ports in the pasted CSV take priority over this field, so mixed inventories can keep their original service notes.
3. Choose Exposure context to match the rule surface. Administrative access raises sensitive-service findings more aggressively, while Internal-only policy avoids treating private ranges as an internet-facing mismatch.
4. Use Host-bit handling to choose between cleanup and rejection. Normalize mode rewrites non-canonical CIDRs to their network boundary and records the change; strict mode reports the row as invalid so the source inventory can be fixed first.
5. Open Advanced only when your review policy needs different defaults. The default broad-range thresholds are IPv4 /16, IPv6 /48, and a 21-day expiry warning window.
6. Resolve warnings before relying on the results. Invalid addresses, out-of-range prefixes, strict-mode host bits, unreadable files, oversized files, and more than 700 non-blank rows all produce visible recovery cues.
7. Read Latest risk readout and Risk Triage Queue first. Use CIDR Exposure Ledger, Overlap & Coverage Review, Exposure Pressure Map, and JSON when you need supporting evidence for cleanup, approval, or an exported review packet.

Interpreting Results:

The finding, evidence, and action in Risk Triage Queue should drive the review. A large score deserves attention, but the evidence text explains the reason: internet-wide source, broad public range, sensitive service, expired access, missing ownership, scope mismatch, provider-list freshness concern, host-bit cleanup, or overlap.

Allowlist shape OK is not approval. It only means the current CIDR shape, ports, owner, review date, scope, and overlap checks did not trigger a finding under the selected settings. Confirm the business need, destination control, provider range source, authentication, and deployed rule before accepting the exception.

Technical Details:

Classless Inter-Domain Routing represents an IP network as an address plus a prefix length. The prefix fixes the leading bits of the address; the remaining bits are host space inside that network. In an allowlist review, host space is the first exposure measure because it estimates how many possible source addresses could match the exception before any identity, ticket, or destination control is considered.

Address scope adds a second layer of meaning. Private, loopback, link-local, documentation, benchmark, multicast, reserved, and unique-local IPv6 ranges have different routing roles from globally reachable public address space. A private CIDR in an internal firewall rule can be expected, while the same private CIDR in an internet-facing partner allowlist usually signals NAT confusion, placeholder data, or a copied example.

Formula Core:

The address count comes from the address-family bit width and the CIDR prefix length.

IPv4 uses 32 bits and IPv6 uses 128 bits. For example, 203.0.113.64/27 covers 2^(32 - 27), or 32 IPv4 addresses. A /0 leaves every bit as host space, so it covers the full address family.

Rule Core:

Service parsing accepts numeric ports, port ranges, all-port tokens such as any and *, and common service names including ssh, rdp, mysql, postgres, redis, mongodb, winrm, and https. Administration, database, file sharing, mail, directory, cache, search, remote-control, and similar services are treated as sensitive. HTTPS is recognized as a service name, but it is not sensitive by itself.

The score uses the strongest finding as the main driver and adds a small overlap pressure adjustment, capped at 100. That keeps a single severe issue such as /0 with SSH visible without letting many minor cleanup findings outweigh one critical source-range mistake.

Overlap review compares only ranges in the same address family. Duplicate ranges should normally be merged, contained child rows may be redundant when a parent range is active, and partial overlaps need a clear owner and purpose for each exception. Unique coverage rows summarize merged IPv4 and IPv6 coverage so reviewers can see whether the total allowlisted surface is growing even when individual rows look familiar.

Limitations and Privacy Notes:

This checker reviews allowlist shape and supporting evidence. It does not scan live firewall rules, prove that a provider range is current, verify that a ticket is valid, or decide whether a destination service is hardened enough for the requested access.

• CIDR parsing, scoring, file reading, table building, and chart data are handled in the browser for pasted text and loaded files.
• Avoid sharing page URLs, copied rows, screenshots, or downloaded evidence when the allowlist contains sensitive network details.
• Provider and CDN wording in a label or note is only a freshness clue. Confirm the maintained source range with the provider before approval.
• A low score should not override normal security review for authentication, destination exposure, logging, change history, proxy handling, and compensating controls.

Worked Examples:

An emergency row such as Emergency admin,0.0.0.0/0,22;3389,infra,2026-05-20 should appear near the top of Risk Triage Queue. The source is internet-wide, the ports include SSH and RDP, and a review after 2026-05-20 adds stale-access evidence. The likely response is to replace the rule with VPN egress, a jump-host range, or a provider-maintained source list.

A partner API row such as Partner API,203.0.113.64/27,443,api-owner,2026-08-31 covers 32 IPv4 addresses and uses HTTPS. Because 203.0.113.0/24 is documentation address space, the CIDR Exposure Ledger should show a documentation scope and the row should land in Review evidence rather than being treated as a real partner source.

Strict-mode cleanup is visible with 203.0.113.70/27. In Reject CIDRs with host bits set mode, the page reports the source row as invalid because .70 is not the network boundary for that /27. In normalize mode, the same input becomes 203.0.113.64/27 and records Host bits normalized.

Overlap evidence appears when 203.0.113.64/27 and 203.0.113.70/32 both exist. Overlap & Coverage Review identifies the containment relationship and shared-address count so the reviewer can remove the redundant host entry or document why both rows remain.

FAQ:

Glossary:

CIDR

Classless Inter-Domain Routing notation, written as an IP address plus a slash prefix such as 198.51.100.32/28.

Prefix length

The number of leading bits fixed as the network portion of the address.

Host bits

The unfixed address bits inside a CIDR range. If they are set in the entered address, the CIDR is not written at its network boundary.

Public-like source

A source range that is not classified as private, documentation, loopback, link-local, multicast, benchmark, reserved, or another special-use range.

Scope mismatch

A finding where the selected exposure context does not fit the address range type, such as documentation space in an internet-facing allowlist.

Overlap

A relationship where two same-family CIDR rows share at least one address.

References:

• RFC 4632: Classless Inter-domain Routing (CIDR), Internet Engineering Task Force, August 2006.
• RFC 1918: Address Allocation for Private Internets, RFC Editor, February 1996.
• RFC 6890: Special-Purpose IP Address Registries, RFC Editor, April 2013.
• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy, National Institute of Standards and Technology, September 2009.
• How to restrict access by IP in Apache, simplified.guide.