What is SSRF?
Server-Side Request Forgery (SSRF) is a vulnerability that lets an attacker trick your server into making unintended requests — often to internal services that aren't exposed to the internet. Think of it like this: your app becomes a puppet, and the attacker holds the strings.
If your backend fetches a URL based on user input, and that input isn’t strictly validated, you’ve got a potential SSRF problem. From probing internal APIs to stealing metadata credentials from your cloud environment, SSRF can open some dangerous doors.
Why It Matters
SSRF has become one of the most dangerous classes of vulnerabilities, especially in cloud-first and microservice-heavy systems. It enables attackers to:
- Bypass perimeter security
- Access cloud metadata services (e.g., AWS IAM tokens)
- Enumerate internal infrastructure
- Exploit trust relationships between services
Capital One’s 2019 breach? SSRF was the root cause.
How SSRF Works (and Why It’s Sneaky)
Here’s a simple Python example:
import requests
def fetch_url(url):
return requests.get(url).text
# This is dangerous if url is attacker-controlled
print(fetch_url("http://127.0.0.1:8000"))
If that url value comes from user input, attackers can send requests to:
- Internal admin panels
- Localhost-only APIs
- Cloud metadata endpoints (like AWS
169.254.169.254)
Real Entry Points
- Image fetchers or upload validators
- URL previews in social feeds or chat apps
- Webhook processors
- Anything that makes a backend HTTP request with user input
Real-World Examples
Hitting AWS Metadata
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Steals IAM credentials in AWS.
Scanning Internal Ports
GET /fetch?url=http://localhost:3306
Checks if MySQL is running. Port scanning 101.
Exploiting Redirects
GET /fetch?url=http://evil.com/redirectHTTP/1.1 302 Found
Location: http://localhost/admin
The server follows the redirect and lands on internal resources.
SSRF Variants and Why They Matter
Basic SSRF
Attacker gives a direct URL, and the server fetches it. Classic.
Blind SSRF
You don’t see the response — but the server still makes the request.
- Detect it using DNS callbacks (e.g.,
http://x.yourdomain.oob-server.com) - Monitor for traffic leaving your network to attacker-controlled domains
Redirect-based SSRF
The initial URL looks innocent. The final destination? Not so much.
- Example:
http://trusted.com/go?next=http://internal-service
DNS Rebinding
Domain starts as public (8.8.8.8), switches to internal (127.0.0.1).
- Sneaky way to bypass IP allowlists
SSRF via Third-Party Integrations
Plugins or services like PDF converters, screenshot tools, or webhook listeners may fetch attacker-controlled URLs behind the scenes.
SSRF via Non-HTTP Protocols
file://to read local filesgopher://to send raw payloadsftp://to exploit older services
SSRF in Serverless Environments
Short-lived doesn’t mean safe. A Lambda function with a fetch call can still hit internal endpoints if input isn't filtered.
Implications to APIs
APIs are especially vulnerable to SSRF — particularly when they expose endpoints that:
- Accept external URLs for processing
- Integrate with other internal APIs
- Proxy third-party resources on behalf of users
APIs designed for flexibility often include features like webhook registration, URL previews, or import-from-URL functionality. These are all potential SSRF entry points.
In modern architectures, SSRF in an API can lead to:
- Accessing internal microservices that assume trusted callers
- Tampering with service meshes or container orchestration APIs
- Extracting tokens or sensitive data from internal-only endpoints
And because APIs are increasingly used in CI/CD, automation, and infrastructure as code — a single SSRF path can have cascading effects across your stack.
SSRF Bypasses Traditional WAFs
One of the biggest challenges with SSRF is that it often evades traditional Web Application Firewalls (WAFs). Why?
- WAFs inspect requests at the edge, but SSRF abuse happens behind the firewall — it's an internal request initiated by your server.
- WAF rules are typically signature-based, and clever attackers can easily obfuscate or encode payloads.
- Redirect chains, DNS rebinding, and non-HTTP protocols often fly under the radar of most rule-based systems.
- Trusted origins — SSRF payloads may target services on internal domains that a WAF trusts or doesn't monitor.
This makes SSRF a blind spot for many security programs that rely on perimeter-based protection. The better approach? Shift security closer to the application logic and enforce validation, isolation, and least privilege.
How to Test for SSRF
Manual Checks
To identify SSRF vulnerabilities manually, start by looking for endpoints that accept URL parameters. These are often named url, uri, path, link, next, or target. If the application fetches content from these URLs, try supplying test payloads that target internal or reserved IP ranges.
Start testing with URLs like:
http://127.0.0.1– Accesses localhosthttp://169.254.169.254– AWS metadata servicehttp://internal-api– Placeholder for internal service nameshttp://your-oob-domain.com– Out-of-band interaction
Look at how the application handles these values. You’re looking for signs like:
- Server-side errors
- Time delays
- Full or partial content from the target resource
If the server returns a response from your supplied URL, SSRF is likely present.
You can also try variations like:
http://127.0.0.1:80/admin- Redirect chains that eventually point to an internal IP
- DNS rebinding tricks using attacker-controlled domains
Burp Suite Tactics
Using Burp Suite, intercept and modify parameters that take user-supplied URLs. Inject SSRF payloads and monitor the response. Key tips:
- Use Burp Repeater to observe how different payloads behave
- Inject URLs pointing to
localhost, internal IPs, or external callback domains - Use Burp Collaborator for blind SSRF — if the server makes a request to the Collaborator domain, you've got confirmation
Watch for anomalies such as:
- Error messages indicating connection attempts
- Long response times (suggesting timeout or blocked connection)
- Out-of-band DNS or HTTP callbacks
Testing should be done cautiously in production systems. If possible, replicate the vulnerable behavior in a safe test environment.
How to Prevent SSRF (for Real)
Validate URLs Strictly
- Use allowlists
- Block IP ranges like
127.0.0.0/8,169.254.0.0/16
Control Outbound Traffic
- Egress filtering is a must
- Isolate fetch services in separate network zones
Avoid Fetching URLs on Behalf of Users
- Replace with async webhooks
- Let the client fetch if possible
Sanitize URL Schemes
- Only allow
https:// - Block
file://,gopher://,ftp://, etc.
Understand Context Before You Fetch If your application is fetching a resource based on user input, validate not just the structure of the URL but also the intent. Ask:
- Is this domain known and trusted?
- Is it in the correct network zone?
- Is there any reason it should hit an internal resource?
Use SSRF-Aware Libraries or Middlewares Some cloud-native platforms and API gateways provide SSRF protections or allow you to define constraints on outbound calls.
Detecting and Preventing SSRF with Aptori SMART
Aptori's SMART (Semantic Modeling for Application & API Risk Testing) engine provides deep application insight to detect SSRF vulnerabilities before they reach production. By semantically understanding your application’s logic and data flows, SMART identifies SSRF risks even in complex, nested API calls or indirect URL fetch patterns.
Key capabilities:
- Semantic analysis of URL-based logic: Detects when user-controlled inputs influence outbound requests.
- Detection beyond simple pattern matching: Identifies SSRF even when obfuscated or buried in third-party integrations.
- Context-aware validation: Maps external request behavior across your services to flag risky flows.
- Continuous testing across the SDLC: Integrates into CI/CD to catch SSRF issues at the commit, merge, or deploy stage.
With Aptori SMART, security teams can prevent SSRF at its root — not just at the perimeter. It’s a smarter, more proactive way to keep internal services safe.
.svg){kind=small}
.svg){kind=small}
