Evaluating Your Web Application’s SSRF Exposure
Server-side request forgery (SSRF) occurs when an application fetches a URL or network resource influenced by a user, allowing an attacker to make requests from the server’s trusted position. This can expose internal services, cloud metadata, administrative interfaces, or sensitive data that is unreachable from the public internet.
For Australian organisations, the risk can extend across cloud workloads in Sydney or Melbourne regions, hybrid data centres, corporate networks, and third-party platforms. A vulnerable customer portal, payment workflow, image importer, or webhook handler may provide an unexpected path into systems supporting banking, healthcare, government, or e-commerce operations.
A practical review should examine how URLs are accepted, parsed, resolved, and requested. It should also assess what the application can reach, which credentials it carries, and whether network controls limit outbound connections. This makes SSRF testing broader than checking a single parameter for a known payload.
The assessment must be authorised and carefully controlled. Sending requests to internal systems without permission can disrupt services or create privacy concerns under Australian regulatory obligations. A structured vulnerability assessment and penetration test can identify exposure while preserving operational safety.
Understand Where Server-Side Requests Occur
Begin by listing every feature that retrieves or validates remote content. Common examples include PDF generators, URL previews, avatar imports, document converters, webhook testers, feed readers, cloud storage integrations, and systems that fetch images for product listings.
Review both obvious and indirect inputs. A request destination may be supplied through a query parameter, JSON field, HTTP header, uploaded file, redirect, or third-party integration. Applications sometimes conceal SSRF risk behind functions labelled “connect,” “sync,” “validate,” or “import.”
Trace each request from input to outbound network call. Record whether the application follows redirects, resolves DNS once or repeatedly, supports IPv4 and IPv6, and uses different HTTP clients for different features. A secure review should include background workers and serverless functions, not just the primary web server.
Map The Application’s Reachable Network
An SSRF issue becomes more serious when the affected service can access internal administration panels, databases, container control planes, or cloud APIs. Document network zones, private subnets, service discovery names, proxy settings, and firewall rules associated with the application.
In an Australian enterprise, this may include a production workload in AWS Sydney linked to an on-premises office in Melbourne, or a healthcare platform connected to systems governed by strict access requirements. Government and financial services environments may also have segmented networks aligned with the Australian Government Information Security Manual or APRA CPS 234 expectations.
Create a permitted test map before sending any requests. Identify harmless internal endpoints, approved test hosts, and monitoring contacts. The objective is to prove reachability and control effectiveness without retrieving confidential records or altering systems.
Test URL Validation And Parser Behaviour
Test how the application handles alternate representations of local and private destinations. The review should examine loopback addresses, RFC 1918 ranges, link-local addresses, IPv6 forms, decimal or hexadecimal IP notation, embedded credentials, unusual ports, and DNS names that resolve to restricted networks.
Redirect handling deserves specific attention. An application may validate a public URL first, then follow a redirect to an internal address. DNS rebinding and time-of-check/time-of-use behaviour can create a similar gap when a hostname resolves to a permitted address during validation and a private address during the actual request.
Useful test cases include:
- Redirects from an approved domain to a private host
- Hostnames resolving to loopback or link-local addresses
- IPv6-mapped IPv4 addresses and alternate numeric formats
- URLs containing encoded characters, fragments, or user information
- Requests sent through configured HTTP or SOCKS proxies
Use an authorised out-of-band interaction service where appropriate to confirm that the server made a request. Keep payloads non-destructive, rate-limited, and restricted to assets covered by the engagement.
Check Cloud Metadata And Workload Identity
Cloud metadata services are a major SSRF concern because they may expose temporary credentials, instance details, startup data, or identity tokens. AWS commonly uses the link-local metadata address and supports IMDSv2, while Azure and Google Cloud provide their own metadata request requirements and headers.
A safe assessment should determine whether metadata endpoints are reachable and whether the workload requires a special token or header. Do not retrieve secrets when a controlled status response or blocked connection is enough to demonstrate exposure. If credentials are accidentally exposed, follow the incident process immediately and rotate them.
Review the permissions attached to the application’s instance role, managed identity, service account, or container workload. Least privilege matters because SSRF impact depends heavily on what the compromised server is authorised to access.
Evaluate Preventive And Detective Controls
Strong URL validation should use a well-maintained parser, enforce an explicit scheme and port policy, resolve and validate the final destination, and re-check addresses after redirects. Domain allowlists are generally safer than denylisting private ranges, but they must account for DNS changes and subdomain takeover risk.
Network controls should provide another barrier. Restrict outbound traffic from application tiers, use egress proxies, block link-local and private ranges where unnecessary, and segment sensitive management interfaces. In Kubernetes, review network policies and access to the control plane or cloud metadata endpoint.
Look for evidence that controls work consistently across application components:
- Outbound requests denied by default where feasible
- Metadata access blocked at the host or network layer
- Security logs recording destination, user, feature, and response status
- Alerts for unusual internal address probes or repeated redirects
- Cloud roles and service accounts limited to required actions
Logging should avoid recording full URLs when they may contain tokens or personal information. Alerting teams need enough context to investigate without creating a second data exposure.
Turn Findings Into A Risk-Based Remediation Plan
Rate findings according to reachability, exposed data, authentication requirements, network position, and available privileges. A public unauthenticated SSRF path into a cloud metadata service generally warrants urgent treatment. A restricted feature that can only contact a narrow, isolated allowlist may represent lower risk, but still requires documented controls.
Retest fixes against parser edge cases, redirects, DNS changes, IPv6, proxy behaviour, and alternate application routes. Confirm that a patch has been applied consistently to production, staging, worker services, and mobile or partner-facing APIs. Australian organisations should also map material findings to internal risk registers, incident procedures, privacy obligations, and relevant sector requirements.
Infoziant Security can support this process through vulnerability assessment and penetration testing, cloud and infrastructure reviews, SIEM monitoring, and threat intelligence. A targeted engagement can establish the application’s real network exposure, validate protective controls, and provide practical remediation priorities for security and engineering teams.
Arrange an authorised SSRF-focused assessment before an attacker discovers the same request path. Contact Infoziant Security to discuss a tailored review, request a free VAPT report, or explore a trial engagement for your Australian environment.
