# SSRF URL classifier > Paste a URL and see where it actually points: loopback, a private or link-local range, a cloud metadata endpoint, CGNAT, reserved space, or the public internet. Decimal, octal, and hex IP obfuscation is decoded, dangerous schemes and embedded credentials are flagged, and an SSRF risk level is shown. It never resolves DNS and never sends the request. - Tool: https://ronutz.com/en/tools/ssrf-url-classifier - Family: Security & WAF --- ## What it does Paste a URL and the tool tells you where it actually points: loopback, a private or link-local range, a cloud metadata endpoint, CGNAT shared space, other reserved space, or the public internet. It decodes the IP-obfuscation tricks used to disguise an internal address, flags dangerous URL schemes and embedded credentials, and shows an SSRF risk level. It never resolves DNS and never sends the request; it is a classifier, not a probe. ## What SSRF is, and why classification matters Server-Side Request Forgery is an attack where a server is tricked into making a request to a URL the attacker chose, typically to reach something the attacker cannot reach directly: a service on `localhost`, a machine in an internal range, or a cloud provider's metadata endpoint. Defending against it comes down to deciding whether a URL is safe to fetch, and that decision is harder than it looks, because an internal address can be written in many disguised forms. This tool is built for that decision: it exists to help you understand a URL and design an allow-list, firmly on the defensive side of the line. ## The obfuscations it decodes A naive filter that blocks `127.0.0.1` misses the many other ways to write the same address, and attackers exploit exactly that. The tool decodes them so the real destination is visible: - **Decimal** integer form, where `2130706433` is `127.0.0.1`; - **Octal** and **hex** octet forms; - **Short-form** IPv4, where `127.1` expands to `127.0.0.1`; and - **IPv4-mapped IPv6**, where an IPv4 address hides inside an IPv6 one. It then classifies the resolved literal against the reserved ranges (RFC 1918 private, RFC 3927 link-local, RFC 6598 CGNAT, and the rest) and calls out the cloud metadata address, which is a prime SSRF target. ## Schemes, credentials, and the honest unknown Beyond the address, the tool flags dangerous URL schemes (the ones beyond `http` and `https` that SSRF payloads often abuse) and embedded credentials in the `user:pass@host` form. One thing it is careful to be honest about: a bare hostname that is not a known special name is reported as resolving at runtime, not guessed at, because the tool never performs DNS resolution. That is the truthful answer, and it is also why the tool is safe: it classifies what the URL says rather than reaching out. ## Using it Paste a URL and read its classification, the decoded destination, any flagged schemes or credentials, and the SSRF risk level. Everything is computed locally; no request is ever made. ## Standards and references - [RFC 1918 - Address Allocation for Private Internets](https://www.rfc-editor.org/rfc/rfc1918) - [RFC 3927 - Dynamic Configuration of IPv4 Link-Local Addresses](https://www.rfc-editor.org/rfc/rfc3927) - [RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space (CGNAT)](https://www.rfc-editor.org/rfc/rfc6598) - [RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax](https://www.rfc-editor.org/rfc/rfc3986) - [OWASP - Server Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) ## Related reading - [Cloud Metadata Endpoints and SSRF](https://ronutz.com/en/learn/cloud-metadata-endpoints-and-ssrf.md): Every major cloud gives an instance a metadata service at a fixed link-local address, and it can return temporary credentials for the instance's role. That makes it the single highest-value SSRF target. Knowing the endpoints, and the IMDSv2-style defenses, is essential for both attack understanding and defense. - [Dangerous URL Schemes in SSRF](https://ronutz.com/en/learn/dangerous-url-schemes.md): SSRF is not limited to http. Schemes like file, gopher, dict, and ftp let an attacker read local files or craft raw bytes to internal services such as Redis and SMTP. A URL fetcher that does not restrict the scheme hands an attacker a far more powerful primitive than a plain web request. - [Defending Against SSRF with Allow-Lists](https://ronutz.com/en/learn/ssrf-defenses-allowlists.md): The durable SSRF defense is an allow-list of intended destinations, combined with resolving the address before you trust it and re-checking after redirects. Block-lists of internal ranges help, but they lose to obfuscation and DNS rebinding. This is the layered approach that holds up. - [IP Address Obfuscation Tricks](https://ronutz.com/en/learn/ip-address-obfuscation-tricks.md): One IP address can be written in many forms: plain decimal, octal, hexadecimal, short-hand, and IPv4-mapped IPv6. Each form parses back to the same address, which is how attackers slip an internal target past a filter that only blocks the dotted-decimal spelling. This is why SSRF checks must decode, not string-match. - [Private, Reserved, and Public IP Ranges](https://ronutz.com/en/learn/private-vs-public-ip-ranges.md): An SSRF filter has to know which addresses are internal. This is the map: RFC 1918 private space, loopback, link-local, carrier-grade NAT, the documentation ranges, and everything else that is public and routable. Knowing the ranges is what turns a raw address into a safe-or-not decision. - [What Is Server-Side Request Forgery (SSRF)](https://ronutz.com/en/learn/what-is-ssrf.md): SSRF is a vulnerability where an attacker makes a server issue an HTTP request to a destination of the attacker's choosing. Because the request originates inside the server's network, it can reach internal services, cloud metadata, and loopback addresses that the attacker could never reach directly. The fix is to validate the destination, not the URL string.