In cloud environments, a successful SSRF attack can sometimes expose temporary credentials or sensitive instance information. If those credentials have excessive permissions, the incident may extend beyond the vulnerable application into other cloud resources.

• Primary risk: Unauthorised access to internal services and server-side resources.

• Common targets: Internal APIs, management interfaces, cloud metadata services and network-restricted endpoints.

• Key investigation evidence: Web application logs, outbound network connections, DNS records, cloud audit logs and identity activity.

• Primary defences: Strict destination allowlisting, network egress controls, secure URL handling and cloud identity least privilege.

1. The Request That Came From the Server

Imagine a web application that allows users to enter a URL to retrieve a preview of a webpage. A user submits a public website, and the application fetches its title and thumbnail before displaying the result.

The feature appears harmless. The application needs to retrieve content from external websites, so it makes the request on the user's behalf.

Now imagine a malicious user submits a URL pointing to an internal administrative service instead of a public website.

The user's browser cannot reach that service directly. However, the web server may be able to reach it because it operates inside the organisation's trusted network.

If the application accepts the destination without sufficient validation, the server may become an unintended bridge between an external attacker and internal resources.

This is the fundamental idea behind Server-Side Request Forgery (SSRF): the attacker manipulates the destination of a request made by a server.

2. How SSRF Works

SSRF commonly appears in application features that retrieve or process user-supplied URLs.

Examples include:

• Website preview and thumbnail generation.

• URL import and document conversion features.

• Webhook configuration and callback testing.

• Image processing and remote file retrieval.

• PDF generators that load external resources.

• Integrations that fetch data from third-party APIs.

A typical attack follows this sequence:

1. Identify a URL-fetching feature. The attacker finds an application endpoint that retrieves content from a supplied URL.

2. Manipulate the destination. Instead of a public website, the attacker provides a destination that may resolve to an internal or otherwise restricted service.

3. Trigger a server-side request. The application attempts to contact that destination using its own network access.

4. Reach a restricted resource. If controls are insufficient, the request may reach an internal service or metadata endpoint.

5. Obtain or influence a response. Depending on the application, the attacker may receive returned content, infer success from response differences, or trigger an action on the destination.

6. Attempt further access. Any exposed information or credentials may create additional risk, depending on the privileges and controls involved.

Not every SSRF vulnerability exposes internal data. Some only allow requests to be triggered, while others return response content or enable access to highly sensitive resources.

3. Why Internal Services Are at Risk

Internal systems often rely partly on network location as a security boundary. They may be reachable only from application servers, internal networks or specific subnets.

An SSRF vulnerability can undermine that assumption because the server making the request already has a position inside that boundary.

Potential targets include:

TargetPotential impactInternal REST APIsUnauthorised data access or API actionsAdministrative interfacesExposure of management functionsInternal service discovery endpointsDisclosure of service names and network structureMonitoring systemsAccess to operational informationDatabases exposed through HTTP-based management toolsPossible disclosure or unauthorised operationsCloud metadata endpointsExposure of instance information or credentials, depending on configuration

The actual impact depends on network reachability, application behaviour, authentication requirements and the protections implemented by the target service.

A successful request does not automatically mean the attacker can execute commands, access a database or control the infrastructure. Those outcomes require additional weaknesses or permissions.

4. Cloud Metadata: Why SSRF Can Become a Cloud Security Incident

Cloud platforms provide metadata services that allow workloads to retrieve information about their running instances. Depending on the platform and configuration, metadata may include instance details, network information and information related to workload identity.

These services are useful for legitimate system operations, but they can become high-value targets when a vulnerable application can access them.

Understanding the risk

In some cloud configurations, an application can make requests to a metadata endpoint from inside its hosting environment. If an SSRF vulnerability allows an attacker to influence those requests, the attacker may be able to retrieve metadata that the application was never intended to expose.

The potential consequences include:

• Disclosure of internal instance information.

• Exposure of temporary credentials, where the environment and metadata configuration permit it.

• Unauthorised access to cloud APIs if exposed credentials are valid and sufficiently privileged.

• Attempts to access additional resources within the permissions granted to the compromised identity.

This creates a possible chain from a web application vulnerability to a cloud identity security incident.

AWS instance metadata and IMDSv2

Amazon Web Services provides the Instance Metadata Service (IMDS). IMDSv2 introduces a session-oriented process that requires a token for metadata requests.

Requiring IMDSv2 can make exploitation more difficult because an attacker may need the vulnerable application to perform additional request steps and handle the token correctly. Whether this blocks a particular SSRF path depends on the application's request capabilities and configuration.

Organisations should require IMDSv2 where appropriate, review metadata access from workloads and ensure that instance roles grant only the permissions necessary for their functions.

Important: IMDSv2 is a valuable defensive control, but it should not replace fixing the underlying SSRF vulnerability or restricting outbound network access.

Other cloud environments have their own metadata services and workload identity mechanisms. Defences must be designed for the platform actually in use.

5. Common SSRF Variants

Basic or in-band SSRF

The application makes a server-side request and returns some of the response to the user. This can reveal information from a destination that the user could not access directly.

Blind SSRF

The application makes the request but does not return the destination's response. An attacker may instead infer activity from observable differences, timing or an external system that records the request.

Blind SSRF can be harder to investigate because the application response may reveal little about what happened behind the scenes.

SSRF involving redirects

An application may validate an initially supplied URL but then follow a redirect to a different destination. If the destination is not checked again, the redirect can bypass the original validation.

SSRF through alternative URL representations

Weak validation may mishandle hostnames, IP address formats, IPv6 representations, encoded characters or DNS resolution. A filter that checks only the appearance of a URL may fail to establish where the connection will actually go.

These variants demonstrate why validation must account for the destination ultimately contacted—not merely the initial string supplied by the user.

6. How a SOC Analyst Investigates a Suspected SSRF Attack

Consider a hypothetical alert: a web application server makes an unusual outbound request to a destination associated with an internal service. Around the same time, the application receives a request containing an unexpected URL.

The SOC analyst must establish whether this is legitimate application behaviour, a scanning attempt or exploitation.

Step 1: Examine the original web request

Review reverse proxy, web server, application and API gateway logs.

Look for:

• Parameters or request bodies containing URLs.

• Requests to URL-preview, import, webhook or fetch functionality.

• Unusual URL schemes, hostnames or address representations.

• Requests to paths that normally do not require external retrieval.

• Repeated requests using different destinations.

Preserve the original request and relevant timestamps. Redact secrets and sensitive user data when sharing evidence.

Step 2: Identify the server-side destination

Correlate the inbound request with outbound connection records.

Useful telemetry may include:

• DNS query logs.

• Firewall and network flow logs.

• Proxy logs.

• EDR network connection telemetry.

• Application traces showing URL-fetching operations.

Determine the actual destination IP, port, protocol and hostname where available. Do not rely exclusively on the hostname supplied by the user because redirects and DNS resolution can affect the final destination.

Step 3: Determine what the server could reach

Establish the application's network position and permissions.

Questions to investigate include:

• Was the destination internal, external or link-local?

• Could the application server normally reach that service?

• Was the destination expected for this application?

• Did a firewall permit the connection?

• Did the target require authentication?

• Was the request blocked, refused or completed?

A suspicious URL alone does not prove that SSRF succeeded. Network and application evidence should support the conclusion.

Step 4: Check the response and application behaviour

Where response logging is available, determine whether the application returned content, an error, a redirect or a generic response.

For blind SSRF, check destination-side logs or controlled monitoring systems for evidence that a request arrived.

Be careful when interpreting HTTP status codes. A 200 OK response does not necessarily indicate sensitive data was exposed, and an error response does not always mean the destination was never contacted.

Step 5: Investigate potential credential exposure

If the destination was a cloud metadata service or another identity-related endpoint, investigate whether sensitive data could have been returned to the application or requester.

Review cloud audit logs and identity activity for suspicious use of the workload's credentials or role.

For AWS, CloudTrail may help identify unexpected API calls made by an affected identity. Correlate the activity with the relevant workload, assumed role, session information and time window where available.

Do not assume that a credential theft occurred simply because a metadata endpoint was contacted. Establish whether sensitive material was accessible and whether subsequent use is evidenced.

Step 6: Build a timeline and assess impact

Correlate the following events:

1. Initial inbound request.

2. Application URL-processing activity.

3. Outbound connection or DNS lookup.

4. Response returned to the application.

5. Any subsequent credential or cloud API activity.

6. Containment and remediation actions.

The timeline should distinguish confirmed events from hypotheses and identify gaps in available telemetry.

7. Evidence and Indicators to Review

SSRF does not have a universal indicator of compromise. The most useful evidence is usually behavioural and contextual.

Evidence sourceWhat to investigateWeb and API logsUser-supplied URLs, unusual parameters and repeated destination changesReverse proxy logsRequest paths, response codes, redirects and source informationDNS telemetryUnexpected hostname lookups by the application serverFirewall or network flow logsConnections to internal, link-local or unusual external destinationsEDR telemetryNetwork activity associated with the web application processApplication tracesURL parsing, redirect handling and outbound fetch operationsCloud audit logsUnexpected API calls or use of workload identitiesIdentity logsUnusual role sessions, access patterns or credential usageTarget service logsWhether the suspected internal endpoint received the request

Patterns that may warrant investigation

• A public-facing application suddenly connects to internal address ranges.

• A URL-fetching feature receives numerous unusual destinations in a short period.

• Requests are followed by connections to destinations not normally used by the application.

• A web application process initiates unexpected outbound traffic.

• Cloud API activity follows suspicious access to a metadata endpoint.

These are investigation leads, not definitive proof of exploitation. Legitimate health checks, integrations, monitoring and application workflows can produce similar activity.

8. Detection Engineering: Building Useful Alerts

Effective detection combines application-level context with network and identity telemetry.

Example detection logic

Create a correlation rule that identifies a user-supplied URL in an application request followed shortly by a server-side connection to a restricted destination.

A conceptual detection workflow is:

1. Identify applications that accept user-controlled URLs.

2. Record the submitted destination and the final destination after redirects and DNS resolution, where technically feasible.

3. Correlate application events with outbound connections from the application host.

4. Prioritise unexpected connections to internal networks, link-local addresses or sensitive service endpoints.

5. Enrich findings with asset criticality, cloud workload identity and expected application behaviour.

Avoid relying on a simple text match for a metadata hostname or a private IP address. Attackers may use redirects or alternative representations, while legitimate applications may routinely communicate with internal services.

Detection logic should account for IPv4, IPv6, DNS resolution, redirects and the specific networking design of the environment.

MITRE ATT&CK mapping

SSRF is a vulnerability class, not a single MITRE ATT&CK technique. Mapping should reflect the observed attacker behaviour and evidence.

• T1190 – Exploit Public-Facing Application: Relevant when an attacker exploits a vulnerability in an internet-facing application to gain access or achieve an objective.

• T1552 – Unsecured Credentials: Potentially relevant if the incident involves exposed credentials, depending on the specific circumstances and applicable sub-technique.

• T1078 – Valid Accounts: Relevant when an attacker subsequently uses valid credentials or accounts to access resources.

Do not assign all these techniques automatically to every SSRF alert. Record only mappings supported by the investigation.

9. Preventing SSRF

The strongest defence is to prevent untrusted input from controlling unrestricted server-side requests. No single filter is sufficient for every application.

Application-layer controls

Use strict destination allowlisting. Where possible, allow requests only to explicitly approved hosts and services. If a feature requires only a fixed set of integrations, avoid accepting arbitrary destinations.

Validate URLs structurally. Parse the URL using a reliable library and validate its scheme, hostname, port and destination against a defined policy. Reject unsupported schemes and malformed inputs.

Validate every redirect. Either disable redirects or validate each redirect destination before following it.

Account for DNS resolution. Check the addresses a hostname resolves to and protect against DNS rebinding and time-of-check/time-of-use issues. Enforce destination policy at connection time where feasible.

Avoid unsafe URL-fetching designs. Consider whether a server needs to fetch arbitrary URLs at all. Where possible, replace flexible fetching with fixed integrations or a controlled retrieval service.

Network and cloud controls

Restrict outbound traffic. Use egress firewalls, network policies or proxy controls to prevent application servers from reaching unnecessary internal services and sensitive metadata endpoints.

Protect cloud metadata services. Apply platform-specific metadata protections, require secure metadata access mechanisms where supported, and limit access from workloads that do not need metadata.

Apply least privilege. Give workload identities only the permissions required for their tasks. A compromised application should not automatically inherit broad cloud access.

Segment sensitive services. Ensure internal administrative interfaces and management APIs are not reachable from every application subnet.

Monitoring and response

• Log URL-fetching decisions and final destinations without recording secrets unnecessarily.

• Alert on unexpected server-side connections to sensitive destinations.

• Review cloud audit logs after suspected metadata access.

• Patch vulnerable dependencies and application components.

• Test URL validation, redirects, DNS changes and network restrictions during authorised security assessments.

10. Incident Response: What to Do After Suspected Exploitation

If evidence indicates that an SSRF vulnerability has been exploited, response should address both the vulnerable application and any resources it could reach.

1. Contain the request path: Disable the vulnerable feature or restrict it to approved destinations.

2. Restrict network access: Block unnecessary connections to sensitive internal services and metadata endpoints, taking care not to disrupt essential workloads.

3. Preserve evidence: Collect relevant application, proxy, DNS, network, endpoint and cloud audit logs.

4. Assess possible data exposure: Determine whether responses containing sensitive information could have been returned or logged.

5. Review workload identities: Investigate suspicious credential use and rotate or revoke affected credentials when warranted, following cloud-provider guidance.

6. Assess downstream activity: Look for unauthorised API calls, access to other services, persistence or data access.

7. Fix and validate: Correct URL handling, strengthen network restrictions, and retest the application before restoring normal operation.

The response should be proportionate to the evidence. Contact with a sensitive destination may justify urgent investigation, but credential rotation and broader containment should be guided by the risk and findings.

Conclusion

Server-Side Request Forgery illustrates how a seemingly ordinary web application feature can become a path into systems that were never meant to be directly accessible to an external user.

The risk is especially important in cloud environments, where a vulnerable server may have access to metadata services and workload identities. However, SSRF does not automatically result in credential theft or cloud compromise; the outcome depends on the application's behaviour, network controls, metadata configuration and identity permissions.

For defenders, the most effective approach combines secure URL processing, strict destination controls, restricted outbound connectivity, least-privileged workload identities and investigation across application, network and cloud logs.

The key lesson: Trusting a server does not mean every request made by that server should be trusted.

Further Reading

• OWASP — Server-Side Request Forgery Prevention Cheat Sheet

• PortSwigger Web Security Academy — Server-Side Request Forgery (SSRF)

• AWS — Instance Metadata Service and IMDSv2 documentation

• MITRE ATT&CK — Exploit Public-Facing Application (T1190)

• MITRE ATT&CK — Unsecured Credentials (T1552)