Choose your stack

Node.js · Express

Fix SSRF in Node.js and Express

Attach the policy to the connection, not the hostname string.

Open the fix card Python · Flask

Fix SSRF in Python and Flask

Attach the policy to the connection, not the hostname string.

Open the fix card Java · Spring Boot

Fix SSRF in Java and Spring Boot

Attach the policy to the connection, not the hostname string.

Open the fix card C# · ASP.NET Core

Fix SSRF in C# and ASP.NET Core

Attach the policy to the connection, not the hostname string.

Open the fix card TypeScript · Next.js

Fix SSRF in TypeScript and Next.js

Attach the policy to the connection, not the hostname string.

Open the fix card Python · FastAPI

Fix SSRF in Python and FastAPI

Attach the policy to the connection, not the URL string or its Pydantic type.

Open the fix card Python · Django

Fix SSRF in Python and Django

Attach the policy to the connection, not the URL string. Allow only http/https and ports 80/443 and reject credentials; resolve the host (or read an IP literal in any notation) and reject loopback, private, link-local and IPv4-mapped addresses with ipaddress; connect to the vetted IP; re-validate every redirect; cap time and bytes.

Open the fix card Go · net/http

Fix SSRF in Go and net/http

Attach the policy to the connection, not the URL string. Give http.Transport a DialContext that resolves the host, rejects loopback, private, link-local and other non-public addresses with net/netip, and dials the vetted IP.

Open the fix card Ruby · Rails

Fix server-side request forgery in Ruby on Rails

Attach the policy to the connection, not the host name string.

Open the fix card PHP · Laravel

Fix server-side request forgery in PHP and Laravel

Attach the policy to the connection, not the host string. Parse with Uri\WhatWg\Url, which reads any IPv4 notation as the address it names; allow only http and https on ports 80 and 443 without credentials; resolve names and refuse any address that fails FILTER_FLAG_GLOBAL_RANGE, plus multicast and NAT64; connect to the vetted address; vet every redirect; cap time and bytes.

Open the fix card

How it happens

  • A feature such as a webhook tester, link preview or image importer takes a URL and fetches it server-side. A public user who cannot reach an internal service directly can reach it through the fetcher.
  • Validation is done on the hostname string rather than the address it resolves to. 127.0.0.1 is written as the decimal 2130706433, octal 0177.0.0.1, hex 0x7f.0.0.1, IPv6 [::1] or the IPv4-mapped [::ffff:127.0.0.1]; an innocent-looking name is pointed at an internal IP by its own DNS.
  • Resolving once to validate and letting the HTTP client resolve again to connect leaves a DNS-rebinding window (TOCTOU): the second answer can be the internal address the first was not.
  • Redirects are treated as the client's business. An allowed public host answers 302 Location: http://169.254.169.254/ and the fetcher follows it straight into the metadata service.
  • No limits: the response has no size or time bound, and the outbound request inherits the caller's headers or the app's cloud credentials.

Fix principles

  • Allow only the schemes and ports the feature needs (http/https, 80/443); reject credentials in the URL.
  • Resolve the host, or recognise it as an IP literal in any notation, and reject loopback, private, link-local (169.254.0.0/16, fe80::/10), unique-local (fc00::/7), carrier-grade NAT, IPv4-mapped and NAT64 IPv6, and anything else not globally routable. Reject the whole address set if any answer is internal.
  • Connect to the vetted address and keep the original host only for TLS and the Host header, so a later DNS answer cannot move the connection (no rebinding).
  • Treat every redirect as a new destination: disable redirects, or re-run the full policy on each hop and do not forward credentials across origins.
  • Bound the connection and total time and cap the response bytes; a permitted host can still hang or stream forever.
  • Prefer an egress proxy or network policy as a second enforcement point, and keep internal credentials out of the fetcher's environment.

How the cards prove it

  • Run each card's tests in three modes: the fixed implementation passes, and the vulnerable and plausible-but-wrong implementations fail. run-all.mjs does this for every card.
  • Exploit tests assert the secure outcome for 127.0.0.1, decimal/octal/hex IPv4, [::1], [::ffff:127.0.0.1], a name that resolves to an internal IP, and a redirect from an allowed host to an internal one: the request is refused and the internal service receives zero connection attempts. Functional tests keep an allowed public host, path and query, and an allowed-to-allowed redirect working.
  • Static analysis is weak here: file-local taint rules target specific HTTP client libraries and miss a fetcher in its own module, and allowlist logic is invisible to them; each card's scannerRules records exactly what ran and what it found.

References

  1. OWASP Server-Side Request Forgery Prevention Cheat Sheet
  2. OWASP Top 10:2025 A01 Broken Access Control (SSRF folded in)
  3. CWE-918: Server-Side Request Forgery (SSRF)
  4. CAPEC-664: Server Side Request Forgery
  5. PortSwigger Web Security Academy: SSRF
  6. RFC 1918: Address Allocation for Private Internets
  7. RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses (169.254.0.0/16)
  8. RFC 4193: Unique Local IPv6 Unicast Addresses (fc00::/7)
  9. IANA IPv4 Special-Purpose Address Registry

Attack patterns:

Practice in the browser

Guides on this weakness

Guide

Constrain server-side fetches to their intended destinations

Prevent untrusted URLs from turning a preview, import, or webhook feature into access to internal services.

Guide

Convert untrusted office documents and PDFs in an isolated parser

DOCX, XLSX and ODF files are ZIP archives of XML, and PDFs can carry scripts; the converters that read them are large C and C++ programs with a long CVE history. Check the package before any parser reads it, convert each document in a container with no network, no writable root and hard limits, kill it at a deadline, and re-render to pixels when people will open the result.

Guide

JWT validation: algorithms, keys, claims and key rollover

Validate a JWT against a fixed algorithm, trusted keys and the expected issuer, audience and type, reject the known header attacks, and rotate signing keys without accepting arbitrary keys or breaking valid tokens.

Guide

Constrain MCP and multi-agent trust boundaries

Validate each connection and delegated action without treating a token for another service, a tool description, another agent or a state handle as authority.

Guide

Apply a security baseline across AWS, Azure and Google Cloud

Give workloads platform identities instead of keys, guard the instance metadata endpoint, block public storage, keep audit logs past the default retention, close inbound admin ports and use the native secret store, with tested Terraform for AWS, Azure and Google Cloud.

Guide

Defend JWTs against forgery, confusion and replay

Verify a JWT as an issuer-, type- and audience-bound assertion with an algorithm allowlist and trusted keys, closing the alg "none", key-confusion, header-injection, weak-secret and replay attacks.

Reference

Abuse case library: tests and controls by feature

Recurring abuse cases for sign-up and login, password reset, MFA enrolment, invites, file upload, payments and coupons, webhooks, search, export, admin and AI chat or agents: the attacker goal, preconditions, a concrete test and the control, each linked to CWE and CAPEC.

Reference

Threat pattern library for threat modeling

Thirty-two recurring threat patterns grouped by identity, authorization, parsers, concurrency, integrations, data exposure, supply chain, availability and AI agents, each with where it shows up on a data-flow diagram, mitigations, a verification step and STRIDE, CWE and CAPEC links, plus a YAML catalog and a script that lists patterns per diagram element.

Guide

Worked threat model: an LLM agent with tools

A complete worked threat model for an LLM agent with tools: the data-flow diagram, the threats from prompt injection, excessive agency, data exfiltration, confused-deputy and memory poisoning, and the mitigations, mapped to the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications 2026.