What Is SSRF? Server-Side Request Forgery Explained

Server-side request forgery (SSRF) is a vulnerability in which an attacker makes a server send requests to a destination the attacker chooses. Because the request comes from inside your environment, it can reach internal services, admin panels and cloud metadata endpoints that the attacker could never reach directly. This guide explains how an SSRF attack works, why AWS IMDSv1 made SSRF a credential-theft problem and how IMDSv2 changes that. It also covers what the public record says about the 2019 Capital One breach, blind SSRF, safe testing and the controls that prevent it.

What Is SSRF?

SSRF definition: Server-side request forgery is a flaw where an application fetches a URL or address that a user can influence, without restricting where that request may go. The attacker cannot reach the target directly, so they borrow the server's network position, identity and trust to reach internal or protected systems for them.

MITRE catalogs the weakness as CWE-918: Server-Side Request Forgery. The core problem is not "a bad URL." It is a server that makes outbound requests on a user's behalf without a firm rule about which destinations are allowed.

SSRF usually hides in ordinary features that fetch something from a URL:

• Webhooks and callbacks, where a customer enters an endpoint your platform will call.
• Link previews and unfurling, where the server fetches a page to build a title card.
• "Import from URL" for images, avatars, CSV files, RSS feeds or documents.
• PDF and screenshot generators that render HTML and load every resource the HTML references.
• Image proxies and resizers that fetch a remote file before transforming it.
• Integrations and SSO flows that fetch metadata, keys or configuration from a supplied location.
• Document parsers that follow external references inside XML, SVG or office files.

Any of these features is safe when it can only reach the destinations it was built for. It becomes SSRF when the destination is open-ended.

SSRF vs CSRF

The names are similar, and people often confuse them. The difference is whose request is forged and who gets fooled.

How an SSRF Attack Works

An SSRF attack follows the same shape no matter which feature is vulnerable:

1. The attacker finds a feature that fetches a URL. A webhook field, an import box or an API parameter such as url, callback or imageUrl is a common starting point.
2. The attacker supplies a destination the developer did not expect. Instead of a public website, the value points at something only the server can reach: a loopback address, an internal hostname, a private IP range or a cloud metadata address.
3. The server makes the request with its own network position and identity. Firewalls that block the internet from internal systems usually allow traffic from the application server, because that server is trusted.
4. The response, or a side effect, comes back to the attacker. In basic SSRF the fetched content is returned in the page or API response. In blind SSRF the attacker sees only timing, errors or a side effect.

The reason SSRF matters so much is the trust boundary. Most networks are built so that the internet cannot reach internal admin tools, databases or metadata services, while application servers can. SSRF turns the application server into a relay across that boundary.

What can SSRF expose?

Impact depends on what the vulnerable server can reach and what those systems trust. An SSRF in an isolated fetcher with no internal routes is a low-severity finding. The same bug on a server with broad network access and an IAM role attached can be critical.

Types of SSRF

Testers and defenders usually group SSRF by how much feedback the attacker gets:

• Basic (in-band) SSRF: The application returns the fetched response to the user. An attacker can read internal pages directly, which makes this form the most damaging and the easiest to confirm.
• Blind SSRF: The server makes the request, but nothing from the response is returned. The attacker learns only that a request happened, usually through an out-of-band interaction.
• Partial (semi-blind) SSRF: Some signal comes back without the full body. Examples include different error messages, status codes, response sizes or response times for different destinations. That is often enough to map which internal hosts and ports exist.

The vulnerable parameter does not have to be a full URL. Applications that accept a hostname, a path that gets appended to an internal base URL, or a URL embedded inside JSON, XML or a document can all produce SSRF.

Blind SSRF Explained

Blind SSRF happens when an application can be made to send a back-end request to an attacker-chosen destination, but the response never reaches the attacker. A webhook that fires and reports only "saved" is a typical example.

Because nothing comes back, blind SSRF is confirmed out of band. The tester supplies the address of a server they control and watches it for incoming connections. PortSwigger's Web Security Academy notes that seeing only a DNS lookup, without the follow-up HTTP request, often means the application tried to connect but outbound HTTP was filtered while DNS was allowed. The two signals mean different things, and a good report says which one was observed.

Blind SSRF is usually lower impact than basic SSRF because the attacker cannot read internal responses. It is still worth fixing:

• It proves the server will connect to arbitrary destinations, which is the precondition for every other SSRF impact.
• It can be used to probe internal ranges by timing or error differences.
• It can trigger state-changing requests on internal services that act on a simple GET.
• It can deliver attacker-controlled responses to the server's HTTP client, which matters if that client or the code that processes the response has its own weaknesses.

SSRF and Cloud Metadata: AWS IMDSv1 vs IMDSv2

Cloud metadata services are the reason SSRF moved from "medium" to "critical" in many cloud environments.

Every Amazon EC2 instance can query the Instance Metadata Service (IMDS) at the link-local address 169.254.169.254 (and, when enabled on Nitro instances in IPv6 subnets, [fd00:ec2::254]), according to AWS's IMDS documentation. IMDS returns instance details. If an IAM role is attached to the instance, it also delivers the temporary credentials for that role, which AWS calls EC2 Role credentials. Software on the instance uses those credentials to call AWS APIs.

That design assumes only code running on the instance can reach the endpoint. SSRF breaks the assumption, because the vulnerable application is code running on the instance.

IMDSv1: one simple request

IMDSv1 is a request/response method: a plain HTTP GET to the metadata path returns the data. There is no session, token or required header. An SSRF that lets an attacker make the server send a basic GET, which is the most common SSRF capability, is enough to read metadata. On an instance with a role attached, that includes the role's temporary credentials. Whatever that role is allowed to do in AWS, the attacker can now attempt from outside.

IMDSv2: a session token first

IMDSv2 is session-oriented. AWS documents these requirements:

• A client must first send an HTTP PUT request to /latest/api/token with a header, X-aws-ec2-metadata-token-ttl-seconds, that sets the token lifetime. The minimum is one second and the maximum is six hours (21,600 seconds).
• Every metadata GET must then carry the token in an X-aws-ec2-metadata-token header. When tokens are set to required, a request without a valid token receives 401 - Unauthorized.
• The token is valid only on the instance that created it.
• PUT requests that contain an X-Forwarded-For header are rejected, which stops most proxies from obtaining a token on a caller's behalf.
• By default the PUT response has an IP hop limit of 1, so the token cannot travel off the instance through a misconfigured router, NAT or container network hop.

When AWS announced the IMDSv2 enhancements on November 19, 2019, it framed them as defense in depth against open web application firewalls, open reverse proxies and SSRF. AWS explained that most open WAFs rarely support PUT requests, and that combining PUT with a session token protects against "the vast majority of SSRF vulnerabilities." It did not claim all of them.

"Allowed" is not "required"

The most important operational detail is that IMDSv2 only helps when IMDSv1 is turned off. The AWS user guide states that by default an instance can use either IMDSv1 or IMDSv2, or both. The effective setting comes from a precedence chain: launch parameters override account-level defaults, which override the AMI setting. AMIs registered with ImdsSupport set to v2.0 launch instances that require IMDSv2, and AWS notes that Amazon Linux 2023 disables IMDSv1 by default. But a launch template that explicitly sets tokens to optional still produces an instance that accepts IMDSv1.

In other words, an organization can believe it "uses IMDSv2" while many instances still answer IMDSv1 requests. That is why cloud penetration tests check the actual HttpTokens value across the fleet, not the policy document.

What IMDSv2 does not fix

IMDSv2 is a strong control, but it is not an SSRF fix:

• It protects the metadata service only. Internal APIs, admin panels and databases are still reachable through the same SSRF.
• An SSRF that lets the attacker choose the HTTP method and set arbitrary headers can, in principle, perform the token handshake. AWS's own wording, "the vast majority," reflects that.
• A hop limit raised to 2 or more, often for containers, widens where a token can be used. AWS's options page notes that a hop limit of 1 can cause issues in container environments. Raise it only where you need to.
• Credentials taken through some other path, such as a server-side code execution bug, are unaffected by which IMDS version is enabled.

Google Cloud and Azure metadata services

Other clouds use a different guard: a required static header plus proxy detection. Google Cloud's metadata server denies requests that lack the Metadata-Flavor: Google header and automatically rejects requests that contain X-Forwarded-For. Azure Instance Metadata Service requires the Metadata: true header and rejects requests that contain X-Forwarded-For.

These checks stop SSRF bugs that can only control the URL. They do not stop SSRF bugs that can also set headers. AWS argued in its 2019 post that a PUT-plus-token design is always strictly more effective than requiring only a static header.

Real-World SSRF Examples

The 2019 Capital One breach: what the primary record says

The Capital One case is the incident most people associate with SSRF and cloud metadata. It is worth separating what the official record states from what has been reconstructed since.

What the U.S. Department of Justice and the OCC documented:

• On July 29, 2019, the U.S. Attorney's Office for the Western District of Washington announced the arrest of a former Seattle software engineer on a criminal complaint for an intrusion into data stored by Capital One. DOJ summarized the complaint this way: "The intrusion occurred through a misconfigured web application firewall that enabled access to the data." DOJ also stated that a GitHub user alerted Capital One on July 17, 2019, and that Capital One confirmed the intrusion on July 19 and contacted the FBI.
• A federal jury convicted the defendant in June 2022 of wire fraud, five counts of unauthorized access to a protected computer and damaging a protected computer. In its October 4, 2022 sentencing announcement, DOJ said she had built a tool to scan Amazon Web Services accounts for misconfigured accounts. She used those accounts to download data from more than 30 entities, including Capital One, and planted cryptocurrency mining software on some servers. The U.S. Attorney said the theft affected 100 million people and caused more than $250 million in damage. The sentence was time served and five years of probation.
• On August 6, 2020, the Office of the Comptroller of the Currency assessed an $80 million civil money penalty against Capital One. In the consent order, the OCC found, and the bank neither admitted nor denied, that in or around 2015 the bank failed to establish effective risk assessment processes before migrating its IT operations to the cloud. The OCC also found that it failed to establish appropriate risk management for the cloud environment, including the design and implementation of certain network security controls, data loss prevention controls and the handling of alerts.

What the primary record does not say: The DOJ announcements and the OCC order do not use the term "server-side request forgery," and they do not describe the request chain step by step. The widely repeated explanation is that a request through the misconfigured firewall reached the instance metadata service and obtained role credentials, which were then used to read storage. That explanation comes from later technical analysis of the charging documents, not from a court finding. Treat it as a well-supported industry reconstruction.

Why the case still belongs in an SSRF guide: The documented facts match the conditions SSRF defenses exist to break. A server-side component on the network edge could be made to reach resources it should not. Cloud credentials sat behind it, with broad access to stored data. Detection came from an outside tip, not internal alerting. Four months after the arrest, AWS published its IMDSv2 enhancements and explicitly named open firewalls, reverse proxies and SSRF as the threats they address.

CVE-2021-26855: Microsoft Exchange Server (ProxyLogon)

CVE-2021-26855, published in the National Vulnerability Database on March 3, 2021, affects on-premises Microsoft Exchange Server. NVD maps it to CWE-918. CISA added it to its Known Exploited Vulnerabilities catalog, and NVD records the KEV addition date as November 3, 2021. It shows that SSRF is not only a cloud problem: in an appliance or server product, an SSRF that reaches back-end components can be the first link in a remote code execution chain.

CVE-2024-21893: Ivanti Connect Secure and Policy Secure

CVE-2024-21893 is an SSRF in the SAML component of Ivanti Connect Secure (9.x, 22.x), Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA. It allows an attacker to access certain restricted resources without authentication. NVD lists it as published on January 31, 2024, the same day CISA added it to the KEV catalog. It is a reminder that SSRF often sits in authentication and federation code that parses externally supplied data.

CVE-2024-34351: Next.js Server Actions

CVE-2024-34351 is an SSRF in Next.js Server Actions. If an attacker modifies the Host header, and the app is self-hosted, uses Server Actions and performs a redirect to a relative path starting with /, the attacker may be able to make requests that appear to come from the Next.js server itself. It was fixed in Next.js 14.1.1. Our Next.js security testing guide covers this class of framework-level issue in more depth.

Where SSRF Sits in the OWASP Top 10 (2021 and 2025)

In the 2021 edition, SSRF had its own category, A10:2021 Server-Side Request Forgery.

The OWASP Top 10:2025 no longer lists SSRF separately. The introduction states that SSRF "has been rolled into" A01:2025 Broken Access Control. The A01:2025 category page names CWE-918 Server-Side Request Forgery (SSRF) among its notable CWEs and lists 40 mapped CWEs in total. The 2025 tenth slot went to a new category, A10:2025 Mishandling of Exceptional Conditions.

The move does not mean SSRF matters less. It reflects how OWASP now frames the problem: an application lets a user reach a resource they should not reach, which is an access control failure. For testing and reporting, SSRF remains its own weakness, CWE-918, with its own test cases and fixes. Our overview of the most common web vulnerabilities shows where SSRF fits among the other classes testers find most often.

Our OWASP Top 10 2025 guide explains every category in the current list, including A01 Broken Access Control.

How Penetration Testers Check for SSRF (Lab-Safe)

SSRF testing has to be careful by design. The whole point of the bug is that the server reaches places it should not, so a careless test can touch production systems, internal services or cloud credentials. Professional testing follows a few rules:

• Written authorization and explicit scope. Internal hosts, metadata endpoints and cloud credentials are out of bounds unless the rules of engagement name them. Proving that a server can reach a destination is usually enough. Actually pulling data from that destination is a separate, explicitly approved step, or it is done only in a lab replica.
• Benign destinations first. Testers prove the behavior with destinations that cause no harm and belong to someone who consents. That means the reserved documentation domain example.com or an endpoint the tester controls.
• No credential use. If a test environment does return credentials, a professional tester records the evidence, stops and reports. They do not use the credentials.

The workflow below is a method, not a payload list.

Step 1: Map every place the server fetches something

Testers inventory features and parameters that cause outbound requests: webhook URLs, import and preview features, document renderers, integration settings, and API fields with names like url, uri, callback, redirect, feed, image or host. In white-box work, code review finds the actual sinks, meaning calls to HTTP client libraries, headless browsers, XML parsers and file fetchers that receive user-influenced input.

Step 2: Establish a baseline with example.com

The tester supplies a harmless public destination and observes what the application does. An illustrative request to a hypothetical link-preview API looks like this:

POST /api/v1/link-preview HTTP/1.1
Host: app.example.test
Content-Type: application/json

{"url": "https://example.com/"}

If the response contains the title of the example.com page, the feature fetches content server-side and returns it. That is the precondition for basic SSRF, not proof of a vulnerability. The baseline also shows normal timing, error messages and response sizes, which later comparisons need.

Step 3: Confirm server-side fetching with a controlled callback

For blind or partial cases, the tester uses an out-of-band interaction server they control. Burp Collaborator is common in commercial testing, and the open-source interactsh project is a self-hostable option. The tester generates a unique, single-use hostname for each test, such as https://<unique-id>.<tester-callback-domain>/, and submits it.

The evidence is what arrives at the callback server:

Unique identifiers per test matter. They tie each interaction to one parameter and one timestamp, which avoids false positives from link scanners and caches.

Step 4: Test reachability in a lab, not against production internals

Whether the server can reach internal destinations is the real impact question. Mature programs answer it without touching production internals:

• Replicate the stack in a lab account with the same network rules, then place a harmless canary service on a private address. If the application can fetch the canary's unique response, internal reachability is proven.
• Check cloud configuration directly. Instead of fetching metadata through the bug, testers with read access confirm whether instances have HttpTokens set to required, what hop limit is set and what the attached role can do. The finding then states the realistic impact: "SSRF on an instance that allows IMDSv1, with a role that can read these buckets."
• Review the request-building code for redirect following, URL parsing and DNS handling rather than probing those behaviors live with bypass strings.

Our AWS penetration testing guide explains how this cloud configuration review fits into a wider AWS assessment, including IAM and metadata service checks under AWS's testing policy.

Step 5: Report evidence, impact and a retest plan

A useful SSRF finding includes the vulnerable parameter, the baseline and callback evidence with timestamps, the egress IP, and what the server could reach. It also needs a realistic impact statement that accounts for IMDS configuration and role permissions, plus specific fixes. After remediation, the same callback test is repeated to confirm that the destination is now refused.

How to Prevent SSRF

No single control prevents SSRF. The reliable approach is layered: restrict destinations in code, back that up in the network, and limit what a successful request could reach in the cloud. The OWASP SSRF Prevention Cheat Sheet is the best single reference and underpins most of the advice below.

1. Do not fetch user-supplied URLs when you can avoid it

The strongest fix is design. If users choose from a known set of partners, accept an identifier and map it to a URL on the server. If users upload an avatar, accept a file upload instead of an image URL. If a feature only needs a domain name, do not accept a full URL with a scheme, port and path.

2. Allowlist destinations

When the application only needs to reach known systems, maintain an allowlist of exact hostnames, schemes and ports, and refuse everything else. OWASP's guidance is blunt: deny-lists are bypass-prone, so prefer allowlists. Blocklists of "bad" addresses fail because the same internal destination can be written in many ways.

When users genuinely need to supply arbitrary external URLs, as with customer webhooks, OWASP recommends combining a blocklist of internal and special ranges with a proof-of-ownership step. In that step, the destination must return a token your platform issued before you send it real traffic.

3. Parse once, then build the request yourself

URL parsing is where many SSRF defenses fail. Common pitfalls:

• Parser disagreement. Your validation library and your HTTP client may read a different host from the same string. Characters such as @ (credentials in a URL), backslashes and unusual delimiters are classic sources of disagreement. OWASP's rule is to treat any parser disagreement as a rejection.
• Alternative IP notations. Some libraries accept decimal, octal or hexadecimal forms of IPv4 addresses, abbreviated forms and IPv4-mapped IPv6 addresses. A string check for "127.0.0.1" or "169.254" misses them.
• Redirects. A URL that passes validation can answer with a redirect to an internal address. Disable automatic redirect following, or re-validate every hop.
• DNS rebinding and multiple records. A hostname can resolve to a public address when you check it and a private one when you connect. Validating the name is not enough; validate the address you actually connect to.
• Non-HTTP schemes. Some clients support schemes such as file: and others. Permit only https (or http where required).

The safest pattern is to validate the input into a small set of parts (an allowlisted host, a fixed scheme and port) and construct the outgoing request from those parts. Do not pass the user's original string to the HTTP client.

4. Resolve, validate every address, then connect to that address

For features that must accept external destinations, check the resolved IP addresses, not just the hostname, and then connect to an address you validated. The Python sketch below is illustrative, not a drop-in library. It shows the logic: allowlist the host, reject credentials and unexpected ports, resolve every address and refuse anything that is not public.

import ipaddress
import socket
from urllib.parse import urlsplit

ALLOWED_HOSTS = {"api.partner.example", "images.partner.example"}

def validated_target(url: str) -> tuple[str, list[str]]:
    parts = urlsplit(url)
    if parts.scheme != "https" or parts.hostname not in ALLOWED_HOSTS:
        raise ValueError("destination not allowed")
    if parts.username or parts.password or parts.port not in (None, 443):
        raise ValueError("unexpected URL components")
    infos = socket.getaddrinfo(parts.hostname, 443, proto=socket.IPPROTO_TCP)
    addresses = sorted({host for _, _, _, _, (host, *_) in infos})
    for address in addresses:
        ip = ipaddress.ip_address(address)
        if ip.version == 6 and ip.ipv4_mapped:
            ip = ip.ipv4_mapped
        if not ip.is_global:
            raise ValueError("destination resolves to a non-public address")
    return parts.hostname, addresses

The calling code should then connect to one of the returned addresses, keep the original hostname for the Host header, TLS SNI and certificate validation, set short timeouts and disable redirects. Doing this correctly in every HTTP client is hard, which is why the network controls below matter.

5. Control egress at the network layer

Application checks fail. Network controls catch what they miss:

• Route server-side fetches through a dedicated egress proxy that enforces the allowlist and blocks private, loopback, link-local (including 169.254.169.254) and IPv6 unique-local and link-local ranges.
• Run URL-fetching features in an isolated service with no routes to internal networks and no cloud role, or a role with no meaningful permissions.
• Apply default-deny outbound rules to application subnets, so only required destinations are reachable.

6. Harden cloud metadata and identity

• Require IMDSv2 everywhere. Set HttpTokens to required on existing instances, set account-level defaults to IMDSv2 only, and use AWS's account-level IMDSv2 enforcement once nothing depends on IMDSv1. For an existing instance, AWS documents a command like this:

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

• Find stragglers before you switch. AWS provides the CloudWatch metrics ImdsV1Enabled (instances that still allow IMDSv1), MetadataNoToken (IMDSv1 calls being made) and MetadataNoTokenRejected (calls refused after you disable IMDSv1), plus the open-source IMDS Packet Analyzer, according to the AWS IMDSv2 transition guide.
• Make IMDSv1 credentials useless. The IAM condition key ec2:RoleDelivery with a value of 2.0 causes API calls made with role credentials obtained through IMDSv1 to fail. The keys ec2:MetadataHttpTokens, ec2:MetadataHttpPutResponseHopLimit and ec2:MetadataHttpEndpoint can prevent anyone from launching or reconfiguring instances to allow IMDSv1.
• Keep the hop limit at 1 unless containers on the instance need 2, and disable IMDS entirely on instances that never use it.
• Apply least privilege to instance roles, so a stolen credential reaches as little as possible.
• On Google Cloud and Azure, keep the platform's header requirements in mind, but do not rely on them alone. Egress controls and least-privilege service identities still matter.

7. Detect SSRF attempts and abuse

• Log every server-side fetch with the requested host, the resolved IP, the response code and the requesting user.
• Alert on application requests to metadata, loopback and private ranges. In a correctly built system these should never happen.
• Watch for instance role credentials being used from networks outside your environment, and for unusual bulk reads from storage.
• Track the MetadataNoToken metric down to zero and keep it there.

Security testing belongs in the development process too. A secure SDLC adds SSRF to threat models for any feature that fetches remote content and adds tests that prove disallowed destinations are refused.

SSRF prevention checklist

Frequently Asked Questions

What is SSRF in simple terms?

SSRF is when an attacker gets your server to make a web request for them. The attacker picks the destination, and the server sends the request from inside your network with its own trust and identity. That lets the attacker reach internal systems, such as admin pages or cloud metadata, that are blocked from the internet.

What is the difference between SSRF and CSRF?

In SSRF the forged request comes from your server, and the target is internal systems that trust that server. In CSRF the forged request comes from a victim's browser, and the target is actions the logged-in user is allowed to perform. SSRF is fixed by restricting where the server can send requests. CSRF is fixed with anti-CSRF tokens, SameSite cookies and origin checks.

What can an SSRF vulnerability expose?

Anything the vulnerable server can reach and that trusts it: localhost admin interfaces, internal APIs, databases and caches with HTTP interfaces, internal network ranges and cloud metadata services. On AWS instances that still allow IMDSv1 and have an IAM role attached, that can include the role's temporary credentials.

How do you prevent server-side request forgery?

Avoid fetching user-supplied URLs where possible. Otherwise, allowlist exact destinations, build the outgoing request from validated parts, disable redirects, validate the resolved IP address you connect to, block internal and metadata ranges at an egress proxy, require IMDSv2, and keep cloud roles least-privileged.

Is SSRF still in the OWASP Top 10?

Yes, but not as its own category. SSRF was A10:2021. In the OWASP Top 10:2025 it has been rolled into A01:2025 Broken Access Control, which lists CWE-918 among its mapped weaknesses.

Does IMDSv2 stop SSRF?

No. IMDSv2 protects the AWS metadata service from most SSRF bugs, because a typical SSRF cannot perform the PUT token handshake, and proxied requests are refused a token. It does not protect internal APIs or other services, and it only helps when IMDSv1 is disabled on the instance.

What is blind SSRF?

Blind SSRF is when the server makes the attacker-chosen request but never returns the response. It is detected out of band: the tester supplies a unique address on a server they control and watches for the incoming DNS lookup or HTTP request.

Next Step: Find SSRF Before Someone Else Does

SSRF is easy to introduce and easy to miss. Every new webhook, preview or import feature adds another place where the server fetches something on a user's behalf. The checks that matter are the ones that prove the real impact: which destinations the server can reach, whether the instance still answers IMDSv1, and what the attached role can do.

DeepStrike's web application penetration testing services combine automated discovery with manual testing aligned to the OWASP Top 10. Only vulnerabilities validated through exploitation are reported, with actionable remediation steps. For workloads in AWS, Azure or GCP, our cloud penetration testing services test IAM misconfigurations and privilege escalation paths, and map cloud-native attack techniques to MITRE ATT&CK Cloud, the context that decides whether an SSRF is a nuisance or a breach. To scope a test, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• MITRE CWE-918: Server-Side Request Forgery (SSRF)
• OWASP Top 10:2025 Introduction
• OWASP Top 10:2025 A01 Broken Access Control
• OWASP Top 10:2021 A10 Server-Side Request Forgery (SSRF)
• OWASP Server-Side Request Forgery Prevention Cheat Sheet
• AWS: Use the Instance Metadata Service to access instance metadata
• AWS: Configure the Instance Metadata Service options
• AWS: Transition to using Instance Metadata Service Version 2
• AWS Security Blog: Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service (November 19, 2019)
• Google Cloud: Query VM metadata
• Microsoft Learn: Azure Instance Metadata Service
• U.S. Department of Justice, W.D. Washington: Seattle Tech Worker Arrested for Data Theft Involving Large Financial Services Company (July 29, 2019)
• U.S. Department of Justice, W.D. Washington: Former hacker sentenced (October 4, 2022)
• OCC News Release 2020-101: OCC Assesses $80 Million Civil Money Penalty Against Capital One (August 6, 2020)
• OCC Consent Order AA-EC-20-51, Capital One, N.A. and Capital One Bank (USA), N.A. (2020)
• NVD: CVE-2021-26855
• NVD: CVE-2024-21893
• NVD: CVE-2024-34351
• PortSwigger Web Security Academy: Blind SSRF vulnerabilities