Server-side request forgery (SSRF) is a vulnerability that can catch even the most well-secured systems off guard. It happens when attackers trick your servers into making requests they weren’t meant to, exposing sensitive internal data or giving access to systems that shouldn’t have it.

This kind of risk is especially serious for identity infrastructure. When you're handling personal data and authentication, even a small vulnerability can snowball into leaking user credentials, exposing internal services, or compromising key pieces of your system.

Properly guarding against SSRF isn’t easy, either. It takes multiple layers of validation, careful request handling, and a lot of attention to detail. Maintaining those protections over time is even harder.

At Stytch, we handle this complexity for you by embedding SSRF defenses directly into our infrastructure. It’s just one more reason why many engineering teams eventually move away from building identity in-house and choose a managed solution like Stytch.

Understanding SSRF vulnerabilities and impact

First, we need to understand what SSRF is, why it’s dangerous, and the impacts it can have on production applications:

What is SSRF?

SSRF is a web vulnerability that allows an attacker to trick a server into making HTTP requests on their behalf. This typically happens when an application fetches user-provided URLs without proper validation. Attackers can then make your server send requests to restricted systems it was never meant to access, all while appearing as a trusted internal source.

This vulnerability is particularly dangerous because back-end servers often have privileged access to internal resources that are otherwise unreachable from outside your network.

Why SSRF matters

Unlike more obvious vulnerabilities, SSRF often hides quietly in seemingly harmless features. Once exploited, attackers gain a lot of power: They can probe your internal systems, extract sensitive credentials, or pivot deeper into your infrastructure. In severe cases, SSRF becomes a gateway into your entire network.

Common targets of SSRF attacks include:

• Internal admin services: These are endpoints like http://127.0.0.1 that are often mistakenly trusted due to their internal-only nature. SSRF allows attackers to abuse this internal trust.
• Cloud metadata endpoints: One example is AWS’s metadata service at http://169.254.169.254, which provides sensitive credentials and configuration data. These endpoints typically assume internal-only access.
• Private databases and caches: These are usually protected behind firewalls or network segments, but SSRF requests from inside your network can bypass these protections.

The real-world impact of SSRF

To understand the impact, here's a common scenario: an app that lets users specify URLs for avatars or webhooks, which the backend blindly fetches.

An attacker could then provide a malicious URL pointing to the AWS metadata endpoint (http://169.254.169.254/latest/meta-data/). Your server then unwittingly fetches sensitive cloud credentials and hands them to the attacker.

This exact vulnerability led to the notorious Capital One breach. A misconfigured firewall allowed an attacker to exploit SSRF and access AWS metadata, leaking credentials that enabled the theft of over 100 million customer records.

SSRF is becoming more important

SSRF vulnerabilities are are happening more and more common as cloud-native architectures become more complex. In fact, The Open Worldwide Application Security Project (OWASP) recently added SSRF to its top 10 web application security risks. Modern applications are very likely to perform outbound HTTP requests for APIs, webhooks, and external integrations, creating countless opportunities for SSRF.

While engineering and ops teams have done a lot to strengthen their defenses against traditional vulnerabilities like SQL injection, outbound HTTP calls typically get less scrutiny, making SSRF a sleeper threat that stays hidden until exploited.

SSRF in identity and authentication APIs

Identity systems verify who users (and, more recently, AI agents) are, manage logins, and securely store sensitive information like credentials, profile data, and authentication tokens. These systems regularly communicate with both internal components, like user databases or administrative APIs, and external identity providers such as Google and Okta. This frequent communication with critical services and sensitive data makes identity systems particularly attractive targets for SSRF attacks.

When SSRF hits an identity service, attackers can impersonate trusted internal services, expose sensitive user data, or compromise authentication processes, potentially leading to significant security breaches.

Identity infrastructure faces some of the the most severe SSRF risks due to a few factors:

Internal trust issues and SSRF exploitation

Identity services often exist behind protective gateways or firewalls and typically assume that requests coming from within their internal network are safe and trustworthy. When SSRF vulnerabilities are present, this internal trust model becomes a liability.

For example, consider a common authentication scenario:

• Expected authentication flow:
  1. A user logs in through a public-facing authentication service.
  2. The public service forwards this request internally to an identity API.
  3. The identity API securely communicates with internal databases or admin services to authenticate the user.
• SSRF attack flow:
  1. An attacker submits a malicious URL to the public authentication service (disguised as a user-uploaded avatar or metadata location).
  2. Due to an SSRF vulnerability, the public authentication service fetches this malicious URL.
  3. The attacker-controlled URL directs the internal request to sensitive internal resources, such as an admin panel, configuration database, or internal API.
  4. The internal resource processes the request and provides access, unknowingly exposing sensitive data or services to the attacker.

This highlights why internal trust assumptions must be explicitly questioned and verified. Security best practices recommend isolating critical identity APIs and internal services from public-facing components, enforcing strict network segmentation, and carefully validating internal requests to prevent SSRF vulnerabilities from being exploited.

External identity integrations and SSRF risks

Identity APIs will almost always integrate with external providers, such as OAuth, OpenID Connect (OIDC), or SAML-based identity services. These integrations involve fetching external URLs like provider metadata files, logos, or cryptographic keys.

Without validation, identity services become vulnerable to SSRF attacks when fetching these external URLs. Some older OpenID Connect implementations allowed parameters like request_uri, which enabled attackers to provide malicious URLs that identity services might retrieve accidentally.

Modern implementations like Stytch’s greatly reduce this risk by strictly limiting external requests. These integrations fetch only explicitly defined and verified endpoints from a provider’s documents, including the token_endpoint, userinfo_endpoint, and jwks_uri. By rigorously validating external URLs, identity providers can effectively mitigate SSRF risks inherent in external integrations.

Common authentication features that risk SSRF

Identity services often include features that unintentionally create SSRF vulnerabilities:

• Admin-configured URLs: Custom metadata URLs used during SAML integrations or OAuth setups.
• Webhooks: URLs provided by users or admins for sending notifications or receiving data.
• User-uploaded images or avatars: URLs pointing to external sources for profile pictures or similar resources.

Without proper input validation and strict URL allowlists, these seemingly benign features can become easy targets. Attackers may exploit these entry points to trigger unauthorized internal requests, potentially exposing internal configurations, JWT signing keys, or other protected resources.

5 common SSRF attacks and developer mistakes

Let’s look at five common scenarios that lead to SSRF vulnerabilities:

1. Directly trusting user URLs

This is SSRF 101: An app directly fetches a URL provided by a user or admin without any validation — for example, allowing users to import profile data from URLs without checking them first. Always assume that user-provided URLs could be harmful and validate them carefully.

2. Assuming DNS names are safe

Blocking obvious URLs like localhost or 127.0.0.1 won’t keep you safe. Attackers use clever workarounds like numeric or hex representations of IP addresses (2130706433 instead of 127.0.0.1) and deceptive domains (localhost.attacker.com). DNS rebinding attacks initially resolve to a safe IP, then switch to a malicious internal IP. Always validate the final resolved IP address, not just the URL text itself.

3. Unchecked redirects

HTTP redirects create another SSRF risk. When your server automatically follows redirects, an attacker can provide a safe-looking public URL that redirects your server to an internal system (http://internal-service). Attackers can also chain your app’s own redirects to reach internal systems. Disable automatic redirects or strictly validate each redirect target.

4. Overlooking “blind” SSRF

Sometimes SSRF attacks don’t return data directly. Attackers might use URLs pointing to their own servers (like attacker.burpcollaborator.net) to detect if your server makes a request, confirming the vulnerability without seeing a direct response. Monitor outbound requests closely and set alerts for unusual destinations to catch these attacks.

5. Weak network segmentation

Flat network design can expose internal services to SSRF attacks. If your public-facing app shares a network with sensitive internal resources (like databases or admin endpoints), a single SSRF bug can give attackers direct internal access. Fix this with strict network policies, allowing services to connect only to necessary endpoints. Proper segmentation ensures that SSRF attacks can’t easily jump from public to private resources.

Typical strategies to prevent and mitigate SSRF

Defending against SSRF requires multiple layers of protection. Since attackers are creative, you can’t rely on just one solution.

1. Validate and sanitize user inputs early

Strict validation of user-provided URLs, parameters, and headers should be your first line of defense. Key practices include:

• Use allowlists: Allow only known, trusted domains and protocols (typically HTTPS) and standard ports (usually 80/443). Reject anything that doesn’t match your trusted patterns.
• Parse and validate URLs carefully: In Go, parse URLs with url.Parse() and confirm that parsedURL.Hostname() is trusted.
• Watch for tricky encodings: Reject URLs with unusual characters, like @, or IP formats in octal or hex (for example, 0x7f000001 for 127.0.0.1). Attackers love exploiting these edge cases.

Always validate before making network calls, as simple blocklists are easy for attackers to bypass.

If you must accept arbitrary URLs, reinforce your validation with the additional safeguards below.

2. Restrict outgoing network access (network-layer controls)

Even carefully validated inputs can slip through. Strong network-level protections significantly reduce SSRF risks:

• Network segmentation: Run URL-fetching logic in isolated containers or subnetworks, separate from sensitive services. This limits damage even if SSRF occurs.
• Strict egress rules: Default-deny policies that allow only explicitly approved external hosts. Block private network ranges (RFC1918), link-local addresses (169.254.x.x), and internal DNS at the network or firewall level.
• In Kubernetes, enforce these rules using NetworkPolicies.
• Route outbound requests through proxies or gateways for centralized control.

These rules prevent attackers from reaching internal services and can also stop data exfiltration if they gain partial access.

3. Use safe HTTP client configurations

Avoid default HTTP client settings when making requests based on user input:

• Controlled DNS resolution: Use external DNS services (like Cloudflare’s 1.1.1.1) rather than internal resolvers. This prevents accidentally resolving internal hostnames and blocks DNS rebinding attacks. In Go, you can set a custom resolver in your HTTP client.
• IP address filtering: Verify the resolved IP address isn’t private, loopback, or reserved before your client connects. Tools like Stripe’s Smokescreen or the safedialer library in Go automatically perform these checks. Cancel the request immediately if the resolved IP is unsafe.

4. Harden cloud metadata and local services

Cloud metadata endpoints (like AWS’s 169.254.169.254) are common SSRF targets:

• Enable protections like AWS IMDSv2, which require tokens and block unauthenticated queries.
• Turn off or restrict unnecessary local endpoints or services. Fewer running services mean fewer attack opportunities.

Reducing your attack surface means attackers have fewer ways to exploit SSRF vulnerabilities.

5. Additional best practices

A few more precautions can further protect your infrastructure:

• Least privilege: Run applications with minimal permissions. If your service doesn’t need internet or filesystem access, enforce those restrictions at the OS or container level (for example, using modules like AppArmor or SELinux).
• Logging and alerts: Log all outbound requests, especially to unusual destinations. Set up alerts for unexpected traffic patterns to quickly identify SSRF attempts.
• Regular security testing: Test your URL-fetching code with tricky payloads (for example, IP encodings like 2130706433 for 127.0.0.1) and ensure your protections work as expected.
• Stay updated: Monitor security advisories and promptly patch vulnerabilities in libraries and frameworks you use. SSRF techniques evolve; staying current helps you stay ahead of attackers.

How Stytch guards against SSRF (a case study)

We've spent a lot of time addressing this at Stytch, putting these defenses in practice. Authentication and authorization tend to interact with both internal and external endpoints, making identity infrastructure especially vulnerable to SSRF. We’ve implemented multiple protective layers, drawing on industry best practices and open-source security tools. Let's walk through it!

1. Hardened HTTP clients with allowlist dialers

Stytch's SSRF prevention centers on a carefully hardened HTTP client. Our identity services, written primarily in Go, use custom-built HTTP client logic designed specifically to counteract SSRF. This client performs strict, low-level checks on every outgoing request. Inspired by Stripe’s Smokescreen proxy and tools like Go’s safedialer library, our HTTP client only allows connections to approved, publicly routable IP addresses on expected ports. Connection attempts outside these rules (like to private or internal IP addresses) are automatically refused.

This acts as a built-in “circuit breaker” for SSRF attempts. Even if an attacker bypasses application-level validation, the client-level checks stop them. By embedding these safeguards directly in our HTTP client, we ensure security consistency across all our services.

2. Public DNS resolution only

Internal DNS services can be tricked into resolving sensitive, internal hostnames, which is a common SSRF vector. All Stytch microservices rely exclusively on public DNS resolvers to prevent this. Unlike internal DNS servers, public resolvers have no knowledge of internal infrastructure, ensuring they cannot resolve internal addresses.

If an attacker tries to trick our services into resolving internal-db.company.local, our DNS query goes to a public resolver, which returns NXDOMAIN (meaning the domain doesn’t exist). This public DNS-only policy defends against DNS rebinding attacks, where domain resolutions switch between public and internal IP addresses.

3. Strict internal IP blocking

Stytch's HTTP client also refuses connections to internal or reserved IP addresses, even if DNS resolution somehow returns them or if an attacker uses a direct IP address.

We block:

• All RFC1918 private network ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16)
• Link-local addresses (169.254.0.0/16), including the AWS metadata service IP (169.254.169.254)
• IPv6 unique-local and localhost address ranges (fc00::/7, ::1)

These rules match industry best practices and ensure our infrastructure never accidentally interacts with protected internal services.

4. Preventing internal credential leakage

Our hardened HTTP clients explicitly strip internal cookies, authentication headers, or sensitive tokens before initiating external requests.

This addresses scenarios where attackers attempt to leverage SSRF to call internal APIs or other sensitive endpoints. Even if an attacker triggers an outbound request to an internal service, it will never include sensitive internal credentials or authentication context.

5. Defense-in-depth with network policies

SSRF defense at Stytch isn’t limited to application-level validation. We also rely heavily on network-layer policies. Our microservices run in containers with strict outbound network rules, similar to Kubernetes NetworkPolicies or cloud infrastructure security groups.

These network policies explicitly limit outbound connectivity, ensuring containers can only reach pre-approved external destinations. Even if an attacker bypasses application-level validation and HTTP client protections, the container’s network policy refuses unauthorized connections.

This defense-in-depth approach significantly raises the difficulty level for attackers. With each layer independently capable of stopping malicious requests, attackers must simultaneously bypass multiple distinct safeguards.

6. Robust encryption of sensitive data

Security isn’t just about blocking unauthorized access; it’s also about limiting damage if attackers bypass some measures. We employ sophisticated encryption strategies to protect customer data:

• Envelope encryption: We encrypt personally identifiable information (PII). Each sensitive piece of data receives its own data encryption key (DEK). These DEKs are further encrypted by securely stored separate master keys (KEKs) with strictly controlled access. Internal services typically see only encrypted data blobs, accessible only when explicitly authorized.
• Unidirectional encryption: For particularly sensitive fields, we use one-way hashing or tokenization, ensuring data values cannot be recovered, even internally.

These encryption strategies ensure that even if an attacker exploits SSRF or other vulnerabilities, they cannot easily extract or misuse sensitive user data.

Don’t let SSRF be your authentication blind spot

SSRF might not have the notoriety of SQL injection or cross-site scripting, but it poses a serious threat, especially for identity infrastructure that’s handling sensitive user data. Just one unvalidated URL can give an attacker deep access to your systems.

The takeaway for developers building back-end services is simple: Treat outbound requests with the same suspicion as inbound user inputs. Strict input validation, secure networking libraries, and zero-trust microservice architectures dramatically reduce SSRF risk. The strategies we’ve covered (input allowlists, isolated network segments, hardened HTTP clients, and strict firewall rules) create a layered defense.

Modern authentication systems must guard against many threats, each with its own complexities.

If you've built identity infrastructure on your own (or considering building it yourself), you have to handle the heavy lifting of safeguarding against these security risks. With Stytch, all these concerns are handled out of the box, using security expertise to provide hardened solutions from day one. This approach lets your team stay focused on product development, trusting that your identity system is secure without reinventing and continuously maintaining the security wheel yourself.