A single misconfigured URL parameter can allow an attacker to abuse server-side requests and potentially access internal services, cloud metadata endpoints, or hidden resources that were never meant to be exposed.

What is SSRF? The Silent Attack Hiding in Plain Sight

SSRF stands for Server-Side Request Forgery.

Imagine asking a waiter to bring food from the kitchen, but instead you trick the waiter into entering the manager’s office and retrieving confidential documents. The waiter is trusted, so security does not stop him. SSRF works in a similar way.

In web applications, servers frequently make requests on behalf of users, such as:

• Fetching URLs
• Generating previews
• Calling external APIs
• Retrieving remote resources

SSRF occurs when an attacker manipulates these requests and causes the server to communicate with destinations it was never intended to access.

Instead of fetching a harmless webpage, the server may begin interacting with:

• Internal services
• Cloud metadata endpoints
• Private APIs
• Administrative interfaces

The dangerous part is that the request originates from the server itself, which is generally considered a trusted source. Firewalls and network controls may treat this traffic as legitimate.

No credentials may be required. In some cases, all it takes is a URL parameter that lacks proper validation.

What Does an SSRF Attack Actually Look Like?

To demonstrate this vulnerability, I used crAPI, a deliberately vulnerable API application designed for security practice. It provides a safe and legal environment for learning and testing web application security concepts.

I navigated to the Contact Mechanic section, submitted the form, and intercepted the request using Burp Suite.

The application sends requests to an endpoint responsible for processing service reports. The key parameter here is mechanic_api, which uses user-supplied input to make an outbound request on behalf of the user. Since this parameter controls the request destination, it becomes a potential SSRF injection point.

Step 1: Confirming the SSRF

To determine whether arbitrary URLs were accepted, I replaced the mechanic_api value with an external URL.

The server returned a successful response containing external page content.

This confirms several important observations:

• The application performs outbound HTTP requests using user-controlled input
• URL validation or allowlisting is absent
• The server can access external destinations and potentially internal resources

This confirms SSRF behavior.

The server is processing user-controlled requests without proper validation, allowing attackers to abuse it to access unintended destinations.

Step 2: Accessing Internal Admin Functionality

Since requests originate from the server itself, internal resources that are inaccessible externally may sometimes become reachable through SSRF. I attempted to access internal administrative paths. The response returned: HTTP 404:Not Found This suggests the resource does not exist at that specific location. I then tested access to the application’s own endpoint through localhost.

I then tested access to the application’s own endpoint through localhost.

This time the response returned:

HTTP 405 :Method Not Allowed

This is interesting because it suggests the endpoint exists and is reachable, but the request method used was incorrect.

This indicates that additional testing with different HTTP methods may reveal more functionality.

Potential Post-Exploitation Scenarios

Once SSRF is confirmed, attackers may attempt additional actions depending on the target environment:

• Internal service discovery through port scanning
• Accessing internal-only APIs
• Retrieving cloud metadata information
• Testing filter bypass techniques
• Identifying blind SSRF behavior using out-of-band interactions

The success of these activities depends heavily on application design and network architecture.

How to Fix It

The good news is that SSRF is entirely preventable. These controls, applied together, close the door completely:

• Validate every user-supplied URL against a strict allowlist of permitted domains and schemes before the server ever touches it

• Reject all requests targeting private IP ranges including 127.x.x.x, 10.x.x.x, 172.16.x.x, 192.168.x.x, and 169.254.x.x

• Block alternative IP representations including decimal, hexadecimal, octal, and IPv6 forms of loopback addresses

• Never pass a raw user-supplied URL directly to an internal HTTP client or fetch function

• Route all outbound server requests through a hardened egress proxy that enforces strict filtering rules

• Apply the principle of least privilege to internal services so that even if they are reached, the damage is contained

• Enable IMDSv2 on AWS instances so that metadata access requires a session token, blocking unauthenticated SSRF-based credential theft endpoints

Final Thoughts

SSRF may appear harmless because it often starts with nothing more than a URL parameter. However, when applications trust server-originated requests without proper validation, attackers can potentially use that trust to interact with systems that were never intended to be exposed.

A small oversight in input handling can become a pathway into internal infrastructure.