Python ipaddress turns textual IP addresses and network prefixes into objects that can be validated and compared. It is useful in configuration readers, inventory tools, and access-policy tests. Its most important limitation is equally useful: parsing an address tells you what the address means, not whether a connection is authorized or safe.
A regular expression often accepts malformed addresses or overlooks alternate IPv6 spellings. String prefixes confuse adjacent subnets. The standard library offers better primitives, but a sound implementation still needs a deliberate input contract, explicit ranges, and tests against the Python version actually deployed.
Choose an address, network, or interface deliberately
An address represents one host identifier. A network represents a prefix and its address range. An interface combines a host address with a prefix. These are related concepts, not interchangeable configuration formats.
Use ip_address() when a field should contain only a literal address. Use ip_network() for a subnet rule. Use ip_interface() when preserving a configured host and its subnet matters. Reject URLs, ports, and hostnames at this layer instead of trying to remove punctuation until the input parses.
For external JSON input, require a string before calling the parser. The library also accepts integers in some constructors, but that convenience can silently broaden an API whose documentation promises address strings. Strip surrounding whitespace only if the interface explicitly permits it. Preserve the original value separately when a diagnostic needs to explain a rejection.
Python ipaddress and strict network validation
By default, network parsing rejects an address with host bits set. That catches configuration such as 192.0.2.7/24 when the intended field is a network. Setting strict=False masks those bits and produces 192.0.2.0/24 instead.
from ipaddress import ip_address, ip_network
allowed = ip_network("192.0.2.0/24")
address = ip_address("192.0.2.17")
assert address in allowed
normalized = ip_network("192.0.2.7/24", strict=False)
assert str(normalized) == "192.0.2.0/24"These documentation-range addresses are examples, not production allowlist recommendations. For a policy editor, strict validation is usually easier to review than silently expanding a host-looking value into a complete subnet. For an inventory import, normalization may be intentional. Show the normalized prefix before an operator approves a change.
Remember that membership includes the whole represented address range. It is not the same operation as iterating usable hosts. Rules for host iteration, including small prefixes, should not determine authorization accidentally.
Do not reduce policy to is_private
Classification properties describe registry-based categories. They are not a complete enterprise security policy. In current documentation, is_private broadly tracks addresses considered not globally reachable, with documented exceptions. It does not simply mean the three familiar RFC 1918 IPv4 ranges.
Shared address space is a particularly useful regression case: addresses in 100.64.0.0/10 are neither private nor global under the documented classification. Therefore, not address.is_private is not interchangeable with address.is_global. Neither expression proves that an address is a permitted destination for your application.
If a business rule means company VPN ranges, encode those ranges explicitly. If it means public internet destinations, document exclusions and verify classification behavior across interpreter upgrades. Separate loopback, link-local, multicast, and unspecified-address cases where they have different operational consequences.
Normalize IPv6 without hiding identity decisions
IPv6 supports compressed representations, so equivalent addresses can have different text spellings. Comparing parsed objects avoids inventing your own compression rules. Use a consistent serialization for storage and logs, while retaining enough context to explain how an input was interpreted.
IPv4-mapped IPv6 addresses need a documented policy. The ipv4_mapped property exposes the embedded IPv4 address when applicable. A service that accepts both families must decide whether mapped and native IPv4 forms share the same policy identity. Test that decision instead of letting one representation bypass checks written only for the other.
Scoped IPv6 addresses introduce interface context. A link-local address without a meaningful interface is not a universal destination. Avoid dropping scope information merely to make comparisons convenient. Confirm what your networking library accepts and how that context reaches the operating system.
Parsing does not solve destination trust
For an outbound URL fetcher, a hostname may resolve to several addresses, and the selected address may differ from a preliminary lookup. Redirects can introduce another hostname. Proxies and connection libraries can move name resolution to another component.
Use address parsing within a complete destination-control design, not as a standalone SSRF fix. Validate the actual connection path, restrict allowed protocols and ports, recheck redirects, and use network-level controls where possible. A trusted textual address also says nothing about the identity of the server listening there; TLS and application authorization remain separate responsibilities.
For inbound requests, do not trust a forwarded address header from an arbitrary client. Establish which reverse proxies may provide that header and how the application chooses the authoritative hop before applying a network rule.
Build a boundary-focused test table
Include valid IPv4 and IPv6 inputs, malformed octets, extra characters, missing prefixes, and a network with nonzero host bits. Add the first and last addresses in each allowed range and their immediate neighbors. Test mismatched families and mapped IPv4 forms explicitly.
Keep fixtures for shared address space, loopback, unspecified addresses, and link-local destinations. Run the same suite when changing Python versions because classification corrections can affect policy outcomes. Compare decisions, not just whether parsing succeeded.
Avoid expanding a large network into a list during validation. Membership testing does not require enumerating every address. Untrusted IPv6 prefixes can represent enormous ranges, so inventory workflows need explicit limits on iteration and output size.
Frequently asked questions
Should I store the original string or the parsed value?
Store a canonical value for comparison and, when justified, the original input for audit explanations. Apply privacy and retention rules to address records; normalization does not make network identifiers anonymous.
Is strict=False unsafe?
Not inherently. It is useful when normalization is the stated task. It becomes risky when callers expect a mistyped subnet to be rejected, or when the widened range is accepted without review.
Can ipaddress enforce firewall rules?
No. It can help validate and test policy data, but enforcement belongs to the application or network component handling traffic. Verify the effective rules and actual connectivity after deployment.
Practical takeaway
Use typed address objects to eliminate ambiguous parsing and fragile string comparisons. Then keep authorization explicit: define supported forms, preserve relevant IPv6 context, encode deliberate ranges, and regression-test the decisions. Correct syntax is the beginning of network policy, not its conclusion.
Documentation and related reading
Consult the official documentation for exact behavior in the version you deploy. Continue with the SSRF prevention guide for the complementary implementation checks.
