Notifications
Clear all
Topic starter
30/07/2026 10:48 pm
TL;DR: Identity APIs are especially exposed to server-side request forgery because they fetch URLs, metadata, and provider data from both internal and external sources, and a single unvalidated request can expose credentials or internal services, according to Stytch. The control problem is not awareness but layered enforcement: validation, egress restrictions, redirect handling, and network segmentation all have to hold at once.
NHIMG editorial — based on content published by Stytch: Securing identity APIs against server-side request forgery (SSRF)
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams prevent SSRF in identity APIs?
A: Use layered controls. Validate and allowlist outbound destinations, block internal and link-local address ranges, disable unsafe redirect handling, and enforce strict egress rules from identity workloads. The key is to assume user-controlled input will eventually find a bypass, so the network and the HTTP client must both refuse dangerous destinations.
Q: Why is SSRF especially dangerous for IAM systems?
A: IAM systems often sit near credentials, provider metadata, and internal admin services, so a successful SSRF flaw can turn a normal backend request into trusted access to sensitive resources.
Q: What do teams get wrong about SSRF defenses?
A: They often stop at URL parsing and blocklists.
Practitioner guidance
- Inventory every identity-service outbound fetch path Map avatar imports, webhooks, OIDC metadata retrieval, SAML configuration lookups, and any URL-based enrichment flows.
- Enforce destination allowlists and block internal ranges Allow only known hosts and protocols, then deny RFC1918, loopback, and link-local destinations at the application and network layers.
- Disable unsafe redirects in identity HTTP clients Treat automatic redirect following as a control decision, not a convenience setting.
What's in the full article
Stytch's full blog post covers the implementation detail this analysis intentionally leaves for the source:
- Concrete examples of URL allowlists, redirect handling, and destination validation in identity services
- HTTP client hardening patterns for blocking private, loopback, and link-local destinations
- Network segmentation and egress policy patterns for backend services that fetch external content
- Examples of metadata, webhook, and OIDC fetch flows that need tighter control
👉 Read Stytch's analysis of SSRF defenses for identity APIs →
Identity APIs and SSRF: are your controls really enough?
Explore further
30/07/2026 10:54 pm
SSRF in identity infrastructure is a trust-boundary failure, not just an application flaw. Identity services are built to handle sensitive requests and often sit close to provider integrations, internal databases, and authentication tokens. When those services can be induced to fetch attacker-chosen URLs, the backend becomes a trusted intermediary for hostile traffic. The implication is that IAM architecture must account for outbound authority, not only inbound authentication.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot confidently trace which non-human identities are exposed to SSRF-adjacent reachability.
A question worth separating out:
Q: Who is accountable when an identity API leaks credentials through SSRF?
A: Accountability usually spans application owners, platform engineering, and identity governance. The app team owns the vulnerable fetch path, platform teams own egress and segmentation, and identity teams own the sensitive credentials and trust boundaries that make the blast radius so high.
👉 Read our full editorial: SSRF in identity APIs exposes internal trust assumptions
