Server-side request forgery is a flaw where an application can be tricked into making unintended requests to other systems on behalf of the attacker.
Server-side request forgery, usually called SSRF, is a flaw where an application can be tricked into making unintended requests to other systems on behalf of the attacker. In plain language, the vulnerable app becomes an unwilling messenger that reaches internal or trusted destinations it should not be querying for arbitrary input.
SSRF matters because the application server often has network reach and trust that an outside user does not. If the application will fetch or connect based on unsafe input, it may expose internal services, cloud metadata endpoints, or sensitive management interfaces.
It also matters because the problem is easy to underestimate when teams think only about validating what comes back to the user instead of what the application is allowed to request internally.
SSRF appears in file-fetch features, URL preview services, webhook handling, cloud workloads, and loosely controlled API integrations. Teams connect it to Input Validation, API Security, Virtual Private Cloud, Secrets Manager, and Web Application Firewall.
Security teams usually address SSRF by restricting outbound destinations, validating allowed patterns, and reducing what the application can reach.
A web application offers a feature that fetches information from a user-supplied URL. If the application accepts arbitrary destinations, an attacker may be able to make the server contact internal endpoints that were never meant to be reachable from outside.
SSRF is not the same as Cross-Site Request Forgery. CSRF abuses a user’s browser session, while SSRF abuses the application’s own server-side network reach.
It is also not solved by frontend validation alone because the risky network request happens on the server side.