One of the dangerous vulnerabilities in API security is Server-Side Request Forgery (SSRF). It is categorized as API7: Server Side Request Forgery in the OWASP API Security Top 10, and it can allow attackers to make the server send unintended requests to internal or external systems.

What is SSRF?

Server-Side Request Forgery occurs when an API fetches remote resources based on user-supplied input without proper validation. APIs commonly use external requests for functionalities such as:

• Fetching images or files from URLs
• Integrating with third-party services
• Webhooks or internal API communication

If input validation is weak, attackers can manipulate the request and force the server to interact with unintended destinations, including:

• Internal network services
• Cloud metadata endpoints
• Restricted internal APIs

This can lead to sensitive data exposure, internal network scanning, or further server compromise.

Learning SSRF Using crAPI

To understand how SSRF works in practice, we will use an intentionally vulnerable API environment:

• crAPI

This platform contains multiple API vulnerabilities aligned with the OWASP API Security Top 10, including SSRF, helping security testers understand how such issues can be identified and exploited in real-world scenarios.

Practical

1. SSRF Vulnerability while contacting the mechanic

• Register and login to your crAPI account as user. Then add the vehicle details.
• Now as we know that SSRF vulnerability occurs when an attacker tricks a server into making HTTP requests on their behalf to URLs that the attacker controls.
• In crAPI the SSRF occurs when we try to contact the mechanic.
• Fill the service request form and intercept the request in burp suite.

• Observe that the POST '/workshop/api/merchant/contact_mechanic' contains a JSON body that includes fields such as mechanic_api, a URL that the server will later fetch.
• The crAPI website blindly uses the mechanic_api URL provided by the user to make a request from the server side but doesn't validate or restrict this URL
• Lets test it by providing a random URL, for example google.com

• So an attacker can replace the legitimate URL with another URL directing to an external attacker-controlled server which gets a callback.
• For this purpose we will be using Burp Collaborator and as we can observe that right now there is no interactions have happened.

• Now replace the mechanic_api URL with the Collaborator's payload and resend the request and observe the response.
• The response gives a 200 status code which indicates the request was successful.

• As the request u is made the URL, the collaborator server gets a callback.
• That callback confirms that SSRF happened even if the application never shows a response directly.

• This type of SSRF is called blind SSRF because the attacker doesn't directly see the server's response.

Conclusion

Server-Side Request Forgery (SSRF) is a critical API vulnerability that allows attackers to manipulate a server into sending unauthorized requests to internal or external resources.

In this section, we explored how improper validation of user-supplied URLs can expose internal services, sensitive data, or cloud infrastructure to attackers. By practicing in environments like crAPI, we gain practical experience in identifying and mitigating SSRF vulnerabilities in real-world applications aligned with the OWASP API Security Top 10.