# Ingredients for SSRF

When targeting an API for SSRF vulnerabilities, **you will want to look for requests** that have any of the following:

* **Include full URLs in the POST body** or parameters.
* **Include URL paths** (or partial URLs) **in the POST** body or parameters.
* **Headers that include URLs** like **Referer**.
* **Allows for user input** that may result in a server retrieving resources.

Let's search the crAPI collection for potential targets. When reviewing the collection we can see three potential requests that involve URLs.

* **POST /community/api/v2/community/posts**
* **POST /workshop/api/shop/orders/return\_order?order\_id=4000**
* **POST workshop/api/merchant/contact\_mechanic**

These three requests each **allow for user input** that might be processed and **some include Referer headers**. The community forum post allows for any authorized user to submit a title and post to the community board. It might be a stretch, but perhaps there is some content filter involved that would submit a request to any provided URL. The *return\_order* and *contact\_mechanic* requests both involve URLs in some way. The **return\_order request** doesn't seem like an obvious choice, however, **the response includes a URL**. Testing this request will include trying to manipulate the URL that is sent in the response. Finally, the **contact\_mechanic** request seems like the most obvious request, because the captured r**equest contains a URL for the "Mechanic API"**.