Server-Side Request Forgery: Can Your Application Be Tricked Into Attacking Its Own Network?

Imagine that your web application allows a user to enter a URL so it can download an image, generate a preview or import a document.

The application receives the address, connects to it from the server and returns the result to the user.

That sounds like ordinary functionality. But what happens if the user enters the address of an internal system instead of a public website?

The application may make the connection from inside your organisation’s network, potentially bypassing the external security controls that would normally prevent an internet user from reaching that system.

This type of vulnerability is known as Server-Side Request Forgery, usually shortened to SSRF.

The central question is:

Can an attacker control where your application connects, and what could it reach if they can?

What is Server-Side Request Forgery?

SSRF occurs when an attacker can influence a request made by the application’s server.

A basic attack might follow this process:

1. The attacker supplies a URL or influences a destination.
2. The web application processes the input.
3. The application server connects to the specified location.
4. The response, timing or connection result reveals information to the attacker.

The vulnerable application effectively becomes a proxy for the attacker.

This does not necessarily mean that the server is immediately compromised. The initial weakness is that an external user can influence a request originating from a trusted system.

The severity depends on several factors:

• Which network locations the server can reach
• Whether the response is returned to the attacker
• Which protocols and HTTP methods are supported
• Whether the application follows redirects
• Whether credentials are included automatically
• Whether internal systems trust the application server
• Whether the application is hosted in a cloud environment
• What permissions are attached to the server’s cloud identity

An application that can retrieve only approved images from a specific service may present relatively little SSRF risk. An application that can make arbitrary requests from inside a sensitive cloud network could present a much more serious problem.

Which application features can introduce SSRF?

SSRF is most commonly associated with application features that retrieve content from remote locations.

Examples include:

• Image import by URL
• Avatar and profile-image retrieval
• Link and social-media previews
• Webhook configuration and testing
• Website screenshot generation
• PDF generation from webpages
• Document conversion
• RSS and data-feed imports
• Calendar and contact imports
• URL validation services
• Remote file attachments
• API integrations
• Proxy functionality
• Single sign-on and identity integrations
• XML processing
• Server-side rendering
• Health checks and connection-testing tools

A straightforward example would be a profile feature that asks for the URL of an image. The application retrieves the image from the supplied address and stores it against the user’s account.

A tester would want to understand whether the application verifies that the destination is genuinely a public image server. If it does not, the feature might also be capable of requesting an internal management interface, a local service or a cloud metadata endpoint.

The vulnerable parameter will not necessarily be called url.

It could be named:

• image
• feed
• callback
• webhook
• endpoint
• host
• redirect
• destination
• resource
• file

The destination might also be hidden inside a JSON object, an uploaded document or a multi-step workflow.

This is one reason manual application mapping is important. A tester needs to understand what the application does with each piece of input, not simply search for parameters with obvious names.

What could an attacker reach?

An application server may be able to reach systems that are unavailable to an ordinary internet user.

Potential targets include:

• Internal web applications
• Administration interfaces
• Databases with web-based management services
• Monitoring platforms
• Development and staging systems
• Container management services
• Internal APIs
• Network devices
• Local services running on the application server
• Cloud metadata services
• Other applications on the same hosting network

An external firewall may correctly prevent direct access to these systems. SSRF creates a different route because the connection originates from the vulnerable application server inside the trusted environment.

Depending on the application and network architecture, an attacker might use SSRF to:

• Discover internal systems
• Identify accessible services
• Read sensitive information
• Access internal APIs
• Retrieve credentials or access tokens
• Perform actions against trusted services
• Bypass network access restrictions
• Create a route towards wider infrastructure compromise

Not every SSRF vulnerability provides full access to internal content. Some allow only limited requests, particular file types or a restricted set of protocols. Others do not return the destination’s response at all.

Even limited behaviour may still be valuable to an attacker if it reveals which systems exist or whether particular services are accessible.

Why might internal services trust the request?

Some internal systems are protected primarily by their location.

They are not directly accessible from the internet, so the organisation may assume that any system capable of reaching them is already trusted.

As a result, internal services may use:

• No authentication
• Weaker authentication
• IP-based access restrictions
• Administrative functions restricted to internal addresses
• Greater trust for particular application servers
• Access to sensitive operational information

SSRF breaks this assumption.

The attacker does not connect directly to the internal service. They persuade the vulnerable application to make the connection on their behalf, making the request appear to originate from a trusted server.

For example, an internal management interface might accept requests only from the application network. That restriction would block an ordinary external attacker, but it might not block the application server itself.

This means that an internet-facing application and the internal network should not be treated as entirely separate simply because a firewall sits between them. If the application can initiate outbound connections, the security of those connections matters.

Internal services should still require appropriate authentication and authorisation, even when they are not exposed publicly.

Cloud metadata services and credential theft

Cloud-hosted systems can introduce a particularly important SSRF risk.

Cloud platforms may provide a metadata service that the running instance can use to obtain information about itself and its environment.

Depending on the platform and configuration, this information could include:

• Instance details
• Network configuration
• Temporary access credentials
• Identity tokens
• Service account information
• Deployment information
• Region and environment details

The metadata service is normally available only from the cloud instance itself. An external user should not be able to connect to it directly.

However, if an application running on that instance is vulnerable to SSRF, the attacker may be able to make the application request the metadata service on their behalf.

If the response is then returned to the attacker, it could expose credentials associated with the server.

Those credentials might provide access to:

• Cloud storage
• Databases
• Secrets-management services
• Message queues
• Other cloud APIs
• Deployment services
• Additional infrastructure

The impact will depend on the permissions assigned to the cloud identity. An identity following least-privilege principles may provide access to only the specific resources required by the application. An excessively privileged identity could allow a much wider compromise.

Modern cloud platforms provide protections intended to reduce metadata-related attacks. These protections are valuable, but they must be correctly enabled and supported by the application’s architecture.

Application-level validation, cloud configuration and network controls should work together rather than relying on a single protection.

SSRF does not always return the response

SSRF is often divided into two broad categories: standard SSRF and blind SSRF.

Standard SSRF

With standard SSRF, the application returns the fetched content, or part of it, to the attacker.

An image-import feature might display whatever content the server retrieves. A PDF-generation service might include content from an internal webpage in the resulting document.

This behaviour can allow an attacker to read internal resources directly.

The response may also reveal headers, server details, error messages or other information that helps the attacker understand the internal environment.

Blind SSRF

With blind SSRF, the server makes the request but does not display the destination’s response to the user.

The attacker may observe only:

• A different application response
• A delay
• An error message
• A DNS lookup
• An external HTTP connection
• An entry in a controlled callback service

Blind SSRF can still be dangerous.

The application might be capable of sending requests to internal services even if their responses are hidden. Differences in timing and errors can reveal whether systems or ports are accessible. In some cases, making the request itself may trigger an action.

Blind SSRF is also easier to miss during routine testing because nothing obvious appears in the application interface.

How out-of-band detection works

Penetration testers can use controlled external infrastructure to detect server-side requests that are not visible in the application’s response.

A unique test address is supplied to the application. The tester then monitors the controlled system to see whether the application server performs:

• A DNS lookup
• An HTTP request
• An HTTPS request
• Another supported network interaction

If a callback is received, it confirms that the application attempted to interact with the supplied destination.

The callback may also reveal:

• The application server’s source IP address
• DNS resolver behaviour
• Request headers
• Software or library identifiers
• Whether redirects are followed
• Whether requests are repeated
• The delay between submission and processing
• Whether asynchronous background workers perform the request

This is particularly useful when the application processes information later through a job queue. The request might occur seconds or minutes after the user submits the input.

Out-of-band testing must use infrastructure controlled by the tester and operate within the agreed rules of engagement. The objective is to demonstrate the behaviour safely, without interacting unnecessarily with unrelated third-party systems.

Why blocking private IP addresses may not be enough

A developer may attempt to prevent SSRF by blocking obvious internal destinations such as:

• Loopback addresses
• Private IPv4 ranges
• Link-local addresses
• Known cloud metadata addresses

This is a useful starting point, but a simple blocklist can easily be incomplete.

URL parsing and network resolution are more complicated than checking whether a string begins with a particular address.

Testing may need to consider:

• Alternative IP-address representations
• IPv6 addresses
• Hostnames that resolve to internal addresses
• URL parsing inconsistencies
• Embedded credentials
• Unusual URL schemes
• Redirect chains
• Mixed or encoded address formats
• Differences between validation and connection libraries

An application may validate a URL using one library but make the connection using another. If those components interpret the address differently, a destination rejected by one parser may be accepted or transformed by the other.

The correct defence is not to build an ever-growing list of suspicious strings. The application should establish which destinations are genuinely required and enforce that policy consistently.

Where possible, an allowlist of approved services is considerably easier to reason about than attempting to identify every possible unsafe destination.

Redirects can undermine destination validation

Redirect handling is a common source of SSRF weaknesses.

Consider this sequence:

1. The application validates the URL supplied by the user.
2. The URL appears to point to an approved public destination.
3. That destination returns a redirect.
4. The application follows the redirect without validating the new location.

The final destination could be:

• An internal IP address
• A local service
• A cloud metadata endpoint
• A hostname that would not have passed the original validation
• A different port or protocol

The application validated the first address, but it connected to the final one.

Every destination in a redirect chain should therefore be subject to the same security checks. If the application does not need to follow redirects, disabling that behaviour can simplify the control.

Where redirects are required, the application should limit their number and revalidate each new destination before connecting.

DNS rebinding and changing destinations

DNS can create another gap between validation and connection.

A hostname can resolve to one IP address when the application checks it and a different address when the server later makes the connection.

For example:

1. The security check resolves a hostname to an allowed public address.
2. The application accepts the destination.
3. A later DNS lookup returns a private or internal address.
4. The application connects to the internal destination.

This is a time-of-check versus time-of-use problem. The destination was considered safe when checked, but it changed before use.

A penetration test can investigate whether the application:

• Resolves a hostname more than once
• Validates the resolved address
• Revalidates after redirects
• Permits destinations that change during processing
• Handles private, reserved and link-local addresses correctly
• Applies the same controls to IPv4 and IPv6

The application should validate the address actually used for the connection, rather than relying solely on an earlier lookup.

Network-level controls can provide another valuable layer by preventing the URL-fetching component from connecting to internal or sensitive address ranges, regardless of how the destination was represented.

How a penetration tester investigates SSRF

A meaningful SSRF assessment requires more than inserting unusual URLs into obvious fields.

The tester needs to understand how the application processes remote resources and where server-side connections originate.

Identify server-side request functionality

The first step is to map features that retrieve URLs, files, images, feeds or callback destinations.

This includes visible functionality and background processes. The tester should consider API requests, imported files, integrations and workflows that may cause the server to fetch content later.

Confirm whether the server makes the request

A controlled endpoint can be used to determine whether the application server actually connects to the supplied destination.

This helps distinguish a genuine server-side request from client-side browser behaviour.

If the tester’s browser makes the request, the issue is not SSRF. The important behaviour is a connection originating from the application’s server or background infrastructure.

Understand the request

Once the connection has been confirmed, the tester can examine:

• The HTTP method
• Request headers
• Cookies or credentials
• Source address
• Redirect behaviour
• Supported protocols
• Timeout behaviour
• Whether the request is repeated
• Which application component makes the request

This information helps determine the potential impact and whether internal services might treat the request as trusted.

Test destination restrictions

The tester can then determine whether the application properly restricts access to:

• Local addresses
• Private network ranges
• Link-local services
• Alternative ports
• Internal hostnames
• Redirected destinations
• Reserved and special-purpose addresses

These checks should be performed carefully and within the agreed scope.

Investigate blind behaviour

Out-of-band DNS and HTTP callbacks can detect connections that do not produce a visible application response.

Timing and error differences may also help establish whether particular destinations behave differently, although these results need to be interpreted cautiously.

Assess the impact safely

The final objective is to establish what the server could potentially access and why that matters.

Testing should use the minimum access necessary to demonstrate the risk. There is rarely a need to retrieve large amounts of sensitive information or perform disruptive actions.

A safe proof of concept might demonstrate that an internal service is reachable without extracting confidential data from it.

Why automated scanners may miss SSRF

Automated vulnerability scanners can identify some common SSRF patterns, particularly when a URL parameter is obvious and the response is returned directly.

However, automated testing may struggle when:

• The vulnerable feature requires authentication
• A multi-step workflow must be completed
• URLs are embedded in JSON or nested objects
• The application retrieves content asynchronously
• Only DNS interaction is visible
• The request occurs several minutes later
• A particular role or account type is required
• The parameter does not look like a URL
• Several application features must be chained together
• Business logic determines when the request is made

A scanner may not understand that entering a website in one screen causes a background service to generate a preview later. It may also fail to associate an out-of-band callback with the correct user action.

Manual testing allows the tester to understand how the feature works, form a hypothesis and adapt the assessment based on the observed behaviour.

This is especially important for modern applications that depend on APIs, cloud services, webhooks and background processing.

What could SSRF mean for the business?

SSRF can sound like an abstract technical issue, but the potential business consequences can be substantial.

A successful attack could lead to:

• Exposure of sensitive information
• Theft of cloud credentials
• Unauthorised access to internal applications
• Compromise of cloud storage
• Disruption of application services
• Increased access to the hosting environment
• A wider data breach
• Regulatory and contractual consequences
• Loss of customer confidence

The risk can be particularly significant for software-as-a-service applications that hold customer information or operate within complex cloud environments.

A single vulnerable URL-fetching feature could provide a route around controls that otherwise prevent external access to internal services.

The impact will depend on the trust and connectivity available to the vulnerable application. This is why the same coding weakness may be relatively minor in one environment and critical in another.

How can organisations reduce the risk?

Effective SSRF protection usually requires both application controls and network restrictions.

Practical measures include:

• Avoid accepting arbitrary URLs where possible
• Use an allowlist of approved destinations
• Resolve and validate destination addresses before connecting
• Block private, loopback, reserved and link-local ranges
• Apply controls consistently to IPv4 and IPv6
• Revalidate every redirect destination
• Restrict supported URL schemes
• Disable unnecessary redirect following
• Use a dedicated outbound proxy
• Apply network-level egress restrictions
• Isolate URL-fetching services from sensitive networks
• Require authentication on internal services
• Apply least privilege to cloud identities
• Enable the strongest available cloud metadata protections
• Set sensible connection timeouts and response-size limits
• Log and alert on unusual outbound requests

If an application only needs to retrieve images from one trusted service, it should not have unrestricted access to arbitrary internet and internal destinations.

Separating URL-fetching functionality into a restricted service can also reduce the impact of a vulnerability. That service can be placed in a network segment with no route to sensitive internal systems and given only the permissions it requires.

Cloud identities should follow least-privilege principles. If SSRF exposes temporary credentials, those credentials should not provide unrestricted access across the environment.

Internal services should not rely solely on their network location for protection. Authentication and authorisation remain important even when a service is intended only for internal use.

Logging can help identify unexpected activity, such as repeated attempts to reach private address ranges, unusual ports or cloud metadata services.

No single control should be expected to solve the entire problem.

Why application context matters

SSRF is not simply a matter of finding a parameter and inserting an unusual URL.

A meaningful assessment needs to establish:

• Where the request originates
• Which destinations are reachable
• Whether redirects are followed
• How DNS resolution is handled
• Whether responses are returned
• What trust or credentials the server possesses
• Whether the behaviour can be combined with other weaknesses

The vulnerability exists within the context of the application, its hosting environment and the services around it.

That context determines whether the issue is a limited information leak or a route to internal systems, cloud credentials and sensitive customer data.

This is why manual web application penetration testing provides greater assurance than automated vulnerability scanning alone.

Does your application retrieve URLs, process webhooks, import remote files or interact with cloud services?

Plainsight Security can assess whether these features could expose internal systems, cloud credentials or sensitive services. Contact us to discuss a web application penetration test.