Testing API7:2023 Server-Side Request Forgery means forcing an API endpoint to issue outbound requests to destinations it should never reach — cloud metadata services, internal-only hosts, or an attacker-controlled listener — then confirming whether the response leaks data, an action executes, or a blind out-of-band callback fires. The caveat most teams miss: a scanner that reports SSRF as "informational" has usually never confirmed impact, and unconfirmed SSRF findings routinely chain into full cloud account takeover once a response from an AWS or GCP metadata endpoint exposes IAM credentials.
TL;DR
- API7:2023 SSRF testing requires forcing outbound requests to internal hosts, cloud metadata endpoints, or attacker listeners to confirm real impact.
- Automated scanners flag SSRF as informational far more often than they confirm exploitability — manual verification is what proves the finding.
- Cloud metadata endpoints (169.254.169.254) remain the highest-severity SSRF target because responses often include temporary IAM credentials.
- Testing must cover webhooks, file-import URLs, PDF generators, and any parameter that accepts a URL, not just obvious 'url=' fields.
- Egress filtering, DNS pinning, and response validation are the controls that actually stop SSRF — WAF rules alone do not.
Why SSRF Testing Matters for API Security Programs
SSRF earned its own category in the 2023 OWASP API Security Top 10 because APIs process user-supplied URLs constantly — webhook registration, file imports, avatar uploads from a link, PDF rendering, third-party integrations. Each of these is a candidate for SSRF if the backend fetches the URL without validating the destination.
AppSecure's manual API testing methodology treats SSRF as a chaining vector, not an isolated bug — the fastest way to confirm real exploitability is verifying what a metadata endpoint or internal service actually returns, not trusting scanner output. A finding that reads "potential SSRF" in an automated report and a finding that reads "retrieved AWS IAM role credentials via metadata endpoint" carry entirely different risk ratings, remediation timelines, and audit consequences.
Regulated teams feel this directly. PCI DSS DE.1.1 requires validated evidence of exploitability for cardholat-adjacent findings, SOC 2 auditors expect a description of what was actually tested against outbound-request functionality, and ISO 27001 risk registers need a documented impact rating, not a CVSS guess. Unverified SSRF findings sitting in a backlog without confirmed impact are one of the more common reasons penetration test reports get pushed back by assessors. AppSecure runs SSRF validation as a required step in every API engagement rather than an optional add-on, precisely because the gap between "flagged" and "confirmed" is where real breaches happen.
How to Test API7:2023 Server-Side Request Forgery
A disciplined SSRF test follows a fixed sequence. Skipping steps is how testers produce false negatives on blind SSRF, which is the variant that causes the most damage in production incidents.
- Map every parameter that triggers a server-side fetch. Webhook URLs, avatar-from-URL fields, PDF/image conversion endpoints, SSO metadata URLs, import-from-URL features, and any field labeled
url,callback,endpoint, orlink. - Test with a controlled out-of-band listener first. Point the parameter at a domain you control (Burp Collaborator or an equivalent) to detect blind SSRF before touching internal infrastructure.
- Attempt cloud metadata access. Submit
http://169.254.169.254/latest/meta-data/(AWS), the GCP metadata equivalent with the required header, or the Azure IMDS endpoint, and check whether the response is reflected or stored. - Probe internal network ranges. Try RFC1918 ranges (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16),localhost,127.0.0.1, and0.0.0.0variants to find internal admin panels or unauthenticated services. - Test protocol handlers beyond HTTP.
file://,gopher://,dict://, andftp://schemes bypass allowlists that only inspect forhttp/https. - Attempt DNS rebinding and redirect chains. Register a domain that resolves to an external IP on first lookup and an internal IP on a second, or use an open redirect to pivot past a naive allowlist check.
- Confirm impact, not just reachability. A 200 response alone is not proof — extract actual data (metadata credentials, internal service banners, admin endpoints) to establish severity.
Blind SSRF detection
- What It Confirms: Whether any outbound request fires at all
- Manual Testing Focus: Out-of-band interaction validation
- Typical Tooling: Burp Collaborator, interactsh
Cloud metadata access
- What It Confirms: Credential or config exposure
- Manual Testing Focus: Header requirements per cloud provider
- Typical Tooling: Manual curl equivalents, custom scripts
Internal network pivot
- What It Confirms: Reachable internal services
- Manual Testing Focus: Port and path enumeration behind the API
- Typical Tooling: Manual, scanner-assisted enumeration
Protocol smuggling
- What It Confirms: Allowlist bypass via non-HTTP schemes
- Manual Testing Focus: Manual payload crafting
- Typical Tooling: Manual only — scanners rarely test this
DNS rebinding
- What It Confirms: TOCTOU bypass of IP validation
- Manual Testing Focus: Timed DNS resolution swap
- Typical Tooling: Custom DNS server, manual timing
Testing SSRF Against Cloud Metadata Endpoints
Metadata-endpoint SSRF is the highest-severity variant because a single successful request can return temporary IAM credentials, instance identity documents, or user-data scripts containing secrets. AWS EC2 instances without IMDSv2 enforced are still common in production, and IMDSv2's token requirement is frequently misconfigured or bypassed through a chained redirect.
Test each cloud target with its specific quirks: AWS requires no special header on IMDSv1 but does on IMDSv2; GCP requires the Metadata-Flavor: Google header, which means naive SSRF payloads that only manipulate the URL will fail silently and produce a false negative; Azure's IMDS endpoint requires the Metadata: true header on port 80. Testers who don't account for these header requirements will under-report SSRF severity on GCP and Azure workloads specifically.
AppSecure's engagements pair this endpoint-specific testing with a broader cloud configuration review so that a confirmed metadata leak is immediately mapped to the IAM roles and permissions attached to the compromised instance, rather than reported as an isolated finding disconnected from blast radius.
Testing SSRF via Webhooks, Callbacks, and File-Import Features
Webhook registration is one of the most under-tested SSRF surfaces because teams assume outbound webhook delivery is a trusted, internal function rather than attacker-controllable input. Any field that lets a user register a URL for the API to call later — payment callbacks, integration webhooks, notification endpoints — is a direct SSRF vector if the destination isn't validated at request time.
File-import and "fetch from URL" features carry the same risk in a different shape. Avatar-from-URL uploads, PDF generation services that render a remote page, and document converters that accept a source URL are all backend fetch operations. Test each one with the same metadata and internal-range payloads used against direct API parameters — the fetch logic is usually shared code, and if one endpoint is vulnerable the others frequently are too.
Re-validation matters here specifically because allowlist checks on webhook URLs are commonly implemented once at registration time and never re-checked at delivery time, which opens a window for a benign URL to be swapped or redirected after the check passes.
Testing SSRF Through Internal Network Pivoting
Once an SSRF vector is confirmed, the next question is what it reaches. Internal network pivoting testing enumerates what an API server can access that a public user cannot — internal admin dashboards, unauthenticated microservice APIs, Redis or Elasticsearch instances left open on internal ports, and CI/CD tooling exposed only on private subnets.
This is where SSRF chains into far more damaging findings. An SSRF that reaches an internal Jenkins instance without authentication, or an internal service that exposes another API's credentials, converts a "medium" finding into a critical one. Manual testers map the internal network incrementally — confirm reachability first with a low-risk port, then expand scope only within the authorized rules of engagement.
Common SSRF Bypass Techniques Attackers Use
Production SSRF defenses usually rely on IP or domain allowlisting, and attackers have a consistent playbook for defeating them. Decimal and octal IP encoding (2130706433 instead of 127.0.0.1), IPv6 shorthand (::1), and URL-encoded characters inside the hostname all bypass naive string-matching filters that only check for the literal string localhost or 127.0.0.1.
Attackers also vary their source infrastructure to defeat destination-side detection and rate limiting during exploitation attempts, which mirrors a pattern any team validating egress controls should replicate during testing — the same discipline a scraping operation applies when rotating proxies for outbound requests to avoid IP-based blocking applies directly to SSRF exploitation, since both depend on varying origin infrastructure against a blocklist. Testers who only send payloads from a single source IP will miss whether a target's defenses are actually IP-agnostic or just untested against IP rotation.
Redirect chains are the other consistent bypass. An allowlist check that validates the initial URL but doesn't re-validate after a 302 redirect lets an attacker register an allowed domain that redirects to 169.254.169.254, sailing past the first check entirely.
Why SSRF Risk Varies Across APIs
Not every API carries the same SSRF exposure. Severity depends on a small set of factors:
- Cloud provider and IMDS version — unenforced IMDSv1 on AWS carries materially higher risk than IMDSv2-enforced instances.
- Number of URL-accepting features — APIs with webhooks, file-import, and third-party integrations have a larger attack surface than simple CRUD APIs.
- Egress filtering maturity — APIs with no outbound firewall rules can reach any internal host; properly segmented environments limit blast radius even when SSRF is confirmed.
- Response handling — APIs that return the fetched content directly to the user (SSRF with response) are more severe than blind SSRF, since data exfiltration is immediate rather than inferred.
- Authentication on internal services — internal services with no authentication turn any SSRF into a critical finding; authenticated internal services limit what an SSRF pivot can actually extract.
- Redirect and DNS handling — services that re-validate the destination after every redirect and re-resolve DNS at request time close off the two most common bypass paths.
Compliance Mapping for API7:2023 SSRF Testing
PCI DSS 4.0
- What It Requires: Penetration testing of the cardholder data environment, including APIs
- What Assessors Check: Confirmed exploitability, not scanner output
- Testing Implication: Manual SSRF validation against payment-adjacent APIs required
SOC 2
- What It Requires: Evidence that outbound-request functionality was assessed
- What Assessors Check: Description of testing methodology and findings
- Testing Implication: SSRF must appear explicitly in scope documentation
ISO 27001
- What It Requires: Risk-based testing of significant attack surfaces
- What Assessors Check: Documented impact rating tied to asset criticality
- Testing Implication: Metadata-endpoint SSRF mapped to IAM blast radius
NIST SP 800-115
- What It Requires: Technical security testing methodology
- What Assessors Check: Consistent, repeatable test procedures
- Testing Implication: Structured SSRF test cases, not ad hoc probing
Is SSRF Only a Cloud Infrastructure Problem?
SSRF is not only a cloud problem — it is a broader threat wherever an API fetches a URL on the server side, including on-premises environments with internal services, legacy systems, or self-hosted integrations. Cloud metadata endpoints simply raise the severity ceiling because a single successful request can return credentials rather than just internal reachability.
How Does API7:2023 Differ from the OWASP Top 10 Web SSRF Category?
API7:2023 focuses specifically on SSRF introduced through API-specific patterns — webhook registration, third-party API integrations, and machine-to-machine callbacks — while the general OWASP Top 10 SSRF category covers the same vulnerability class across any web application. The testing techniques overlap heavily, but API7:2023 emphasizes surfaces unique to API architectures like async callbacks and integration webhooks.
FAQ
What is API7:2023 Server-Side Request Forgery?
API7:2023 SSRF is an OWASP API Security Top 10 category covering vulnerabilities where an API fetches a remote resource without validating the user-supplied URL, letting an attacker force the server to reach internal hosts, cloud metadata endpoints, or attacker-controlled listeners.
How do you test for SSRF in REST APIs?
Test every parameter that triggers a server-side fetch — webhooks, file-import URLs, callback fields — using out-of-band listeners first to catch blind SSRF, then attempt cloud metadata endpoints, internal IP ranges, and non-HTTP protocol handlers to confirm impact.
Does a WAF stop SSRF attacks?
A WAF alone does not stop SSRF because the malicious request originates from the trusted API server, not the attacker's IP, so signature-based WAF rules rarely inspect server-side outbound requests. Egress filtering and destination validation stop SSRF; a WAF does not.
What's the difference between API7:2023 SSRF and OWASP Top 10 A10 SSRF?
API7:2023 focuses on SSRF introduced through API-specific patterns like webhooks and integration callbacks, while OWASP Top 10 A10 covers SSRF across any web application. The exploitation techniques are largely the same.
Can SSRF be exploited without a visible response?
Yes — blind SSRF confirms exploitation through out-of-band interaction, such as a DNS lookup or HTTP callback to a tester-controlled listener, even when the API never returns the fetched content to the user.
Which cloud providers are most affected by metadata SSRF?
AWS, GCP, and Azure all expose instance metadata over a link-local address, and each requires different headers or token handling, which means SSRF testing must be adapted per provider rather than using one generic payload set.
How does DNS rebinding bypass SSRF allowlists?
DNS rebinding registers a domain that resolves to an allowed external IP during the validation check and then to an internal IP at request time, defeating allowlists that validate the domain once but don't re-resolve DNS immediately before the fetch.
Should SSRF testing be manual or automated?
SSRF testing should be manual-led because automated scanners frequently miss provider-specific header requirements, blind SSRF confirmation, and business-logic-dependent fetch parameters that don't match generic payload signatures.
How often should APIs be tested for SSRF?
APIs with webhook, file-import, or third-party integration features should be retested for SSRF after any change to outbound-request handling and as part of every annual or continuous penetration testing cycle, not just at initial launch.
What compliance frameworks require SSRF testing?
PCI DSS 4.0, SOC 2, and ISO 27001 all require evidence of tested outbound-request functionality where APIs process user-supplied URLs, with assessors expecting confirmed exploitability rather than automated scanner flags.
One Last Thing
The SSRF finding that gets under-reported most often isn't the obvious url= parameter — it's the PDF generator or document converter nobody thinks of as an outbound-fetch feature. Those services render remote pages server-side by design, which makes them a built-in SSRF primitive that most teams never add to their API inventory in the first place.
Get SSRF Validated by Manual Testers
Confirm exploitability, not just scanner flags, across your API attack surface.
A good API7:2023 SSRF testing program combines manual verification of every URL-accepting parameter, provider-specific cloud metadata testing, and confirmed impact rather than scanner-reported possibilities. Whoever runs the assessment should treat SSRF as a chaining vector against IAM roles and internal services, not an isolated finding to close and forget. To get a testing program built around confirmed exploitability rather than automated noise, talk to AppSecure about scoping an API-focused penetration test.
Related Guides
Tejas K. Dhokane is a marketing associate at AppSecure Security, driving initiatives across strategy, communication, and brand positioning. He works closely with security and engineering teams to translate technical depth into clear value propositions, build campaigns that resonate with CISOs and risk leaders, and strengthen AppSecure’s presence across digital channels. His work spans content, GTM, messaging architecture, and narrative development supporting AppSecure’s mission to bring disciplined, expert-led security testing to global enterprises.
.webp)
