Server-side request forgery (SSRF)
3 guides tagged Server-side request forgery (SSRF), grouped by topic, with the SDLC phase and role each is written for.
- SDLC phases
Application security
3 guidesConstrain server-side fetches to their intended destinations
Prevent untrusted URLs from turning a preview, import, or webhook feature into access to internal services.
Design, Development · Developers, AppSec engineers
Redirect users only to destinations you control
Check every redirect target taken from a request, so attackers cannot borrow your domain for phishing, carry OAuth tokens off-site or steer a server-side fetcher through your redirects.
Design, Development · Developers
Consume third-party APIs safely (OWASP API10:2023)
Treat every upstream and third-party API response as untrusted input: validate it against a schema, set connect and read timeouts, cap the response size, refuse to follow redirects blindly, keep TLS verification on, and scope the credentials you hold for each provider.
Design, Development · Developers, AppSec engineers
Practice
SSRF lab: Guard an outbound fetch against SSRF
A webhook sender fetches whatever URL the user gives it, and follows redirects. An attacker can point it at the cloud metadata service or an internal admin page, directly or through a redirect. Repair the guard so it resolves each host and refuses private addresses, in literals, encodings and redirects alike.
SSRF validation lab: Validate a fetch URL with ipaddress
An image importer fetches any URL a user submits, so a crafted URL reaches the cloud metadata service or an internal host, directly or through an encoded IP literal. Repair the validator so it parses the URL, resolves the host and allows only public addresses.
Open redirect lab: Return users to this site only
After sign-in, the login page redirects to whatever its next parameter says, so a link to your own domain can end on a look-alike site. Return users only to a page on this site.
Server-side request forgery (SSRF)
SSRF happens when a server fetches a URL chosen by the caller without constraining where the request can actually go, so the attacker borrows the server's network position to reach loopback, link-local (cloud metadata at 169.254.169.254), private or other internal addresses.