SSRF testing: cloud metadata and egress controls

Server-side request forgery (SSRF) occurs when a user can influence a network connection made by a server and direct it to a destination the designer did not intend. The server-side context is what makes the weakness significant: the request originates inside a trusted application environment and may reach internal services, administration interfaces, a control plane or instance metadata that is not directly exposed to the Internet.

The short answer: a sound SSRF pentest maps every feature that retrieves a URL, observes parsing, DNS, redirects and the final connection, and proves impact only against a controlled receiver. In cloud environments, blocking 169.254.169.254 is not enough. Defences need safe parsing, post-DNS validation, policy enforcement on every redirect, restrictive egress and least-privilege workload identities. IMDSv2 and the headers required by Azure or Google Cloud reduce some attack paths, but they do not repair SSRF.

SSRF is not limited to an “import image from URL” field. A sink can hide in webhooks, document imports, link previews, PDF generation, antivirus scanning, image proxies, SSO integrations, monitoring, OAuth callbacks, page renderers, XML libraries or redirect-following services. Callback and redirect locations should also follow the controls in the OAuth 2.0 security and RFC 9700 guide. SSRF testing starts with data flow rather than a list of familiar IP addresses.

A technical model of SSRF

A useful assessment separates seven stages that applications often treat as one operation:

1. source — a parameter, file, header, database record or queued message;
2. URI parser — extraction of scheme, authority, userinfo, host, port and path;
3. normalisation — decoding, IDNA processing, IPv4/IPv6 representation, path segments and default ports;
4. name resolution — A/AAAA responses, search domains, local resolver and DNS cache;
5. policy decision — allowlist, address classification and permitted port;
6. transport — HTTP library, egress proxy, TLS, SNI and connection reuse;
7. response handling — redirects, content parsing, caching and data returned to the user.

When the validator and network client do not use the same canonical representation, an interpretation gap appears. RFC 3986 defines an authority that can contain userinfo, host and port, while the host can be a registered name, IPv4 address or IPv6 literal. A string-prefix check does not understand that grammar. A regular expression intended to “block localhost” commonly misses alternate address forms, locally resolving names, IPv4-mapped IPv6 and a target change after a redirect.

The key defensive model is: parse once, resolve, classify every address, and connect to the validated destination. Repeat that policy for every redirect.

Finding SSRF sinks

Inventory should combine functional review, source analysis and egress telemetry. Common entry points include:

Feature	Why it opens a connection	Frequent mistake
webhook tester	validates a receiver	arbitrary host and automatic redirects
image or document import	retrieves a user resource	validates only a file extension
link preview	fetches HTML and metadata	feature-rich client supporting many schemes
PDF or screenshot generator	renders a page	headless browser has internal network access
API integration	calls an administrator-configured address	lower role can change privileged configuration
XML or SVG parser	loads an entity or dependency	indirect SSRF outside the normal HTTP client
repository or package fetcher	clones a URL and dependencies	extra protocols and ambient credentials

Search for calls to HTTP, DNS and socket clients, but also inspect conversion tools, headless browsers, media processors and queue workers. A URL can be stored now and fetched asynchronously by a different microservice later. This second-order SSRF is easily missed when testing only the immediate HTTP response.

Endpoint inventory is part of an effective REST, GraphQL and OAuth API penetration test. SSRF is API7 in the OWASP API Security Top 10, but practical impact depends on the process’s network position and identity.

Why cloud metadata matters

An instance metadata service gives software on a machine information about its environment and often provides a mechanism for obtaining short-lived workload credentials. Reaching an endpoint does not invariably mean stealing a key. Impact depends on provider, configuration, supported methods and headers, and especially the permissions attached to the workload identity.

AWS EC2 and IMDSv2

AWS provides IMDS on a link-local endpoint. The EC2 metadata options documentation describes IMDSv2 token enforcement and a configurable response hop limit. Creating an IMDSv2 session requires a separate PUT, and subsequent requests must carry its token. That blocks many simple SSRF sinks capable only of a GET without attacker-controlled headers.

It is not a general SSRF fix. If a vulnerable feature permits method and header control, or code is already executing in the workload, metadata may remain reachable. Strong configuration requires HttpTokens=required, a carefully selected hop limit, disabling IMDS where unnecessary, local access restrictions and a minimal IAM role.

Azure Instance Metadata Service

Azure IMDS requires Metadata: true and rejects requests containing X-Forwarded-For. Microsoft also notes that IMDS is available to processes on the VM and should not be treated as a secure secret store. Current architecture reviews should consider Metadata Security Protocol where applicable, host firewall controls and the privileges granted to the VM’s managed identity.

Google Compute Engine

Google Cloud metadata requests require Metadata-Flavor: Google; the official metadata query documentation also states that requests containing X-Forwarded-For are rejected. As on other platforms, the service account and its roles determine the impact boundary. An overprivileged identity turns a single application defect into a route to project resources.

Provider differences cannot be reduced to one universal payload. A professional AWS, Azure and GCP cloud penetration test combines application testing with IAM, network, metadata and control-plane log review.

Rules for safe, authorised SSRF testing

Agree on permitted receivers, protocols, ports, volume and data before testing. Do not scan an internal network through a vulnerable server without explicit authorisation. Do not retrieve metadata secrets merely to make the proof look more serious. A controlled callback, DNS/HTTP evidence and a harmless instance identifier are sufficient in most engagements.

Safe test infrastructure should include:

• a canary domain with controlled A and AAAA records;
• a receiver logging DNS, TCP, TLS and HTTP while minimising retained data;
• a fake metadata service in staging that returns synthetic values only;
• a dedicated account and tenant without production information;
• a unique correlation ID for every attempt;
• a stop rule for access to any unexpected segment or secret.

On production, prove the smallest possible effect. If the backend reaches a controlled receiver even though policy requires restricted egress, that is strong evidence. Pivoting to an internal administration panel is unnecessary.

Step-by-step SSRF penetration testing methodology

1. Build a catalogue of outbound features

Combine OpenAPI documentation, observed application traffic, source searches, queue configuration and egress-proxy logs. For every sink, record the URL source, process performing the request, schemes, methods and headers, redirect behaviour, resolver, proxy, timeout, response-size limit and output handling.

Test roles and tenant boundaries. The fetcher may enforce a good destination policy while an unauthorised user can edit the URL of an administrator-owned integration. This is SSRF combined with an object-level authorisation failure.

2. Profile the client on a controlled receiver

Use your own domain to determine whether the application resolves DNS, which address it selects, which headers it sends, whether it uses an egress proxy, whether it follows redirects and how long it waits. Unique paths distinguish attempts. This controlled endpoint answers most technical questions without touching an internal network.

Compare validation when the URL is accepted with behaviour when it is eventually fetched. A queue worker may use a different URL library from the API that stores the value.

3. Test canonicalisation and name resolution

In an isolated environment, create a matrix of accepted and rejected cases covering schemes, userinfo, ports, IDNs, trailing dots, IPv6, IPv4-mapped IPv6 and multiple DNS responses. The objective is not a collection of bypass tricks; it is proof that one library parses and normalises the destination before policy runs.

Classify every A and AAAA address. Reject loopback, link-local, private, multicast, unspecified and other special-purpose ranges according to the business model. Protect against the DNS answer changing between validation and connection. Ideally, connect to the address that passed policy while preserving correct SNI and certificate verification.

4. Treat a redirect as a new request

Automatic redirects commonly bypass good first-URL validation. Disabling them is the safest default. Where the feature requires redirects, cap the hop count and repeat parsing, DNS resolution, IP classification, port policy and TLS verification for each one. Never forward Authorization, cookies or custom credentials to a different origin.

5. Evaluate blind and second-order SSRF

No response body does not mean no vulnerability. Monitor asynchronous DNS and HTTP callbacks for at least the worker’s retry period. Distinguish a backend callback from a security scanner, anti-spam engine or administrator’s browser using source network, headers, timing and the unique token.

In source code, follow data from storage to the eventual consumer. An import API may return 202 Accepted, while a privileged worker performs the actual retrieval an hour later.

6. Validate impact without collecting secrets

First prove that the application can reach a controlled domain. With authorisation, move to a fake internal service or non-sensitive diagnostic route. In the cloud, prefer configuration evidence: reachability, required methods and headers, and the workload’s effective IAM policy. If metadata access must be shown, retrieve a non-secret property and stop.

Do not use acquired credentials against other services unless the rules of engagement explicitly define that scenario. Reviewing the IAM policy often establishes potential impact safely.

SSRF detection and telemetry

Effective detection correlates application, DNS, network and control-plane signals. Capture:

• the user and feature that initiated the fetch;
• a secret-scrubbed raw URL and its canonical components;
• every A/AAAA result and the final connected address;
• the complete redirect chain without credentials;
• method, status, size, duration and the egress policy decision;
• queries to link-local ranges and metadata services;
• workload identity use immediately after unusual egress;
• egress-proxy denials and TLS/SNI anomalies.

An alert on any private-IP connection will be noisy in a microservice estate. A higher-confidence rule combines user-controlled input, a new DNS destination and a component that normally contacts a narrow host set. Canary credentials can support detection, but honeypots should never contain real keys.

Hardening the application, network and cloud identity

The OWASP SSRF Prevention Cheat Sheet recommends layered controls. The most important are:

1. do not accept a full URL when the business function needs only an identifier or host;
2. allowlist specific origins when the receiver set is known;
3. use one mature URI library and compare canonical components;
4. restrict schemes, normally to https, and explicitly allow required ports;
5. resolve DNS and validate every IPv4 and IPv6 result before connecting;
6. disable redirects or re-run the full policy on each hop;
7. set short timeouts, download limits and decompression bounds;
8. remove ambient credentials, cookies and headers from third-party requests;
9. route traffic through an authenticated default-deny egress proxy;
10. restrict NetworkPolicy, security groups and host-level process access;
11. require IMDSv2 on AWS and apply provider and local metadata controls;
12. give workload identities minimal roles, short lifetimes and usage monitoring.

Define these controls during architecture and verify them against OWASP ASVS 5. An application filter without egress policy is a single point of failure; a network rule without a safe parser cannot distinguish a trusted partner from an attacker-controlled destination.

SSRF checklist for engineers and pentesters

• We know every synchronous and asynchronous resource-fetching feature.
• Every sink has an owner, business purpose and permitted receiver set.
• The URL is parsed once and policy evaluates canonical components.
• Every A and AAAA result is classified, including after redirects.
• The client supports no unnecessary scheme or arbitrary port.
• Credentials never cross origin boundaries.
• Egress is default-deny and observable.
• The metadata service uses provider and local protections.
• The workload role has least privilege.
• Testing uses a controlled callback, fake IMDS and synthetic data.
• Blind SSRF monitoring exceeds the worker retry cycle.
• Retesting covers parsing, DNS, redirects, network policy and IAM.

Primary technical sources

• OWASP Server-Side Request Forgery Prevention Cheat Sheet
• RFC 3986 — Uniform Resource Identifier: Generic Syntax
• AWS EC2 — Configure instance metadata options
• Microsoft Azure — Instance Metadata Service
• Google Cloud — View and query VM metadata

Need to assess SSRF without risking production? The strongest engagement combines source and data-flow review, a controlled callback receiver, observable egress and cloud-role analysis. The resulting report demonstrates exact root cause and reach without scanning someone else’s network or collecting credentials.