What Is SSRF? Security Definition
This page mentions older exam versions. See the Current Exam Context and Legacy Exam Context sections below for the updated mapping.
On This Page
Quick Definition
SSRF is a type of cyberattack where a malicious person gets a web server to send requests to places it shouldn't, like internal company networks or cloud service endpoints. The attacker uses the server's trust to bypass firewalls and access data that should be private. Think of it as using a trusted courier to deliver a letter to a secret room you are not allowed to enter yourself.
Commonly Confused With
CSRF is an attack where a malicious website tricks the user's browser into making an authenticated request to a third-party site. The request originates from the user's browser. In SSRF, the request originates from the vulnerable server itself, not the user's browser.
CSRF: A user clicks a link that posts a status on their Facebook. SSRF: A user sends a URL to an image gallery app, and the app fetches that URL, which is actually an internal database.
XSS allows an attacker to inject client-side scripts into a web page viewed by other users. The attack payload runs in the victim's browser. SSRF does not involve injecting scripts-it involves making the server issue network requests to arbitrary destinations.
XSS: An attacker adds a script tag to a blog comment that steals cookies. SSRF: An attacker tricks the blog server into fetching its own internal database endpoint.
Open redirect is a vulnerability where a web application redirects users to a URL specified in a parameter. The user's browser is redirected openly. SSRF does not redirect the user; it makes the server fetch the target internally, often without the user knowing.
Open redirect: A link on site.com/redirect?url=evil.com takes the user to evil.com. SSRF: A URL like site.com/fetch?url=http://internal-server leaks data back to the server.
Must Know for Exams
SSRF appears in several major IT certification exams, including CompTIA Security+, CompTIA CySA+, CISSP, and the AWS Certified Security – Specialty. In these exams, SSRF is often listed under web application vulnerabilities or cloud security threats. For CompTIA Security+ (SY0-601 and SY0-701), SSRF is a key concept within the "Attacks" domain, specifically under server-side attacks. Candidates may be asked to identify SSRF in a scenario or to choose the best mitigation. For CISSP, SSRF relates to the "Software Development Security" and "Security Assessment and Testing" domains, where questions might focus on secure coding practices and input validation.
In exams, SSRF questions typically test the ability to distinguish it from other vulnerabilities like CSRF or XSS. A common question pattern describes a scenario where a web application takes a URL from the user and fetches an image, and the candidate must identify the vulnerability as SSRF. Another question might ask which internal IP address range an attacker would target (e.g., 169.254.169.254 for cloud metadata). Some exams present a log showing requests to internal addresses with unusual response times, and ask the candidate to diagnose the issue.
For cloud-specific exams, SSRF is a major topic. The AWS Certified Security – Specialty exam includes objectives on "Understanding SSRF attacks on EC2 instances and how to protect against them." In these questions, candidates must know how instance metadata service (IMDS) works and why disabling IMDSv1 is a defense. The exam may also test knowledge of network ACLs and security groups that can limit SSRF impact. Overall, a solid understanding of SSRF is essential for passing security-focused IT certifications, and it often appears in scenario-based, multiple-choice, and drag-and-drop question types.
Simple Meaning
Imagine you are at a fancy office building and there is a friendly receptionist who can fetch things from different parts of the building. You are a visitor, so you are not allowed to go into the back offices or the server room yourself. But you can ask the receptionist to go get you something. If you ask for a coffee from the break room, that is normal. But if you trick the receptionist by saying, "Please go to the file cabinet in the back office and bring me the top-secret document," you have just performed an SSRF attack.
In the digital world, the receptionist is a web server or an application running on a server. It is designed to fetch data from other places, like images from other websites or data from databases. The attacker finds a way to give the server a malicious address to fetch. For example, the attacker might tell the server to fetch data from an internal IP address like 192.168.1.1, which is a private address used inside a company's network. The server, being trusted, makes the request as if it is a legitimate request from within the network. The attacker can then see the confidential data that the server returns.
SSRF is dangerous because it lets an attacker bypass security controls like firewalls that are meant to block external users from reaching internal systems. The attacker is essentially using the server's privileges to do bad things. This can lead to stealing sensitive data, scanning internal networks, or even gaining control of other servers.
Full Technical Definition
Server-Side Request Forgery (SSRF) is a web security vulnerability that occurs when an attacker abuses the functionality of a server to cause it to make HTTP requests or other network requests to an unintended destination. This typically happens when an application accepts user-supplied URLs and fetches data from them without proper validation. The attacker can supply a URL pointing to an internal resource, such as a private IP address (e.g., 10.0.0.1, 192.168.0.1, 127.0.0.1) or a domain that resolves to a local address, bypassing network access controls.
From a technical standpoint, SSRF exploits the trust that a server has in itself and its local network. When a server makes a request on behalf of a user, it does so from its own network context, which often has broader access than an external client would. Firewalls and network segmentation are typically designed to restrict external traffic, but internal traffic is often less restricted. SSRF can target various protocols, including HTTP, HTTPS, FTP, gopher, or even cloud metadata endpoints like the AWS Instance Metadata Service at 169.254.169.254. By accessing these internal endpoints, an attacker can retrieve sensitive information such as cloud service credentials, internal API keys, database configurations, or even execute remote code if the endpoint allows it.
Modern implementations of SSRF attacks often involve sophisticated bypass techniques, such as using URL obfuscation (e.g., hex encoding, redirects, or using different URL schemes). There are two main types of SSRF: basic SSRF, where the response is returned to the attacker, and blind SSRF, where the attacker cannot see the response directly but can infer information through out-of-band techniques like timing delays or DNS lookups. Defending against SSRF requires input validation, allow-listing of acceptable URL schemes and hosts, disabling unnecessary URL schemes, and implementing network-level controls such as firewall rules that restrict outbound traffic from application servers.
Real-Life Example
Think of a library with a very helpful librarian. You are a patron, and you can only look at books in the public reading area. The librarian has a special key to the restricted stacks and even to the digital archives in the basement. You give the librarian a request slip that says, "Please bring me the book from shelf A12." That is fine. The librarian goes, gets the book, and brings it back. But now, imagine you write on the slip, "Please go to the basement server, access the database, and print out the list of all library members." Because the librarian is not suspicious, they might do exactly that. The librarian trusts the request because it came from a patron, and the patront is supposed to ask for books.
In IT terms, the librarian is the web application server. It has higher privileges and can access internal resources that normal users cannot. The request slip is the URL or address you supply to the application. The restricted stacks are the internal network resources (databases, internal APIs, cloud metadata services). The attacker, like the tricky patron, crafts a request that the server thinks is legitimate. The server executes the request, fetches the data, and returns it to the attacker, just as the librarian would return the forbidden list of members.
This analogy highlights the core of SSRF: the attacker uses the server's trust and its privileged position within the network to access data or systems that are off-limits directly. The attack works because the server is inherently allowed to talk to internal services, and the attacker piggybacks on that permission.
Why This Term Matters
SSRF matters because it is a high-severity vulnerability that can lead to catastrophic data breaches and full server compromise. In modern IT environments, applications frequently communicate with other services, such as cloud APIs, databases, monitoring tools, or internal microservices. An unvalidated URL input is an open door for attackers to pivot into the internal network, which is often assumed to be safe. Once inside, attackers can extract cloud instance credentials, allowing them to access the entire cloud account, or they can scan and exploit other internal services, leading to lateral movement and escalation of privileges.
From a practical perspective, SSRF is particularly dangerous in cloud-native architectures where metadata services are widely used. Cloud providers like AWS, Azure, and Google Cloud offer metadata endpoints that provide instance-specific information, including IAM roles and temporary credentials. If an attacker can achieve SSRF against a cloud instance, they can impersonate that instance and access any resource the instance has permission to reach. This has been the root cause of several large-scale data breaches in recent years.
Understanding SSRF is critical for IT security professionals and developers. It forces teams to think about trust boundaries and network segmentation. Even if an application is well-written in other respects, one overlooked URL parameter can undo all other security measures. Because SSRF attacks often bypass standard perimeter defenses like web application firewalls (WAFs), they require specialized detection and prevention strategies. For anyone preparing for general IT certifications, especially those focused on security, grasping SSRF is not optional-it is a core competency.
How It Appears in Exam Questions
SSRF exam questions usually present a scenario or a log excerpt and ask the candidate to identify the vulnerability, its impact, or the best mitigation. One common pattern is the "image fetcher" scenario: a web application allows users to submit a URL from which to download a profile picture. The server then retrieves the image. The question might say: "An administrator notices the application is making requests to 10.0.0.5. What type of attack is this?" The answer is SSRF. Another pattern involves cloud metadata: "After deploying a web application on an EC2 instance, the security team observes requests to 169.254.169.254. What is the attacker trying to achieve?" The answer is retrieving IAM role credentials.
Troubleshooting-type questions might show a firewall log with outbound connections from the web server to internal services over HTTP. The question asks: "What is the most effective mitigation to prevent this attack?" Options might include input validation, using a whitelist of allowed domains, or adding a WAF. The correct answer is typically either input validation or using a whitelist, as WAFs can often be bypassed. Configuration-type questions may present code snippets showing URL fetch operations without validation, asking the candidate to identify the security flaw.
Another pattern is multi-step questions where the candidate must trace a chain: SSRF leads to access of internal metadata, which yields credentials, which allow further access. For example, a scenario: "A developer creates a lambda function that reads data from an external API based on user input. The function has access to a DynamoDB table. After a penetration test, the security team finds that the function's IAM keys were leaked. How did the attacker obtain them?" The logical answer is that SSRF was used to hit the AWS metadata endpoint. These questions test not just recognition but also impact analysis and defense.
Practise SSRF Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are a security analyst for a company that runs an online image gallery. Users can upload a photo or provide a URL to an image from another website. The application fetches the image from the URL and saves it to its own server. It is a popular feature. One day, you notice strange entries in the server logs: the application is making requests to private IP addresses like 192.168.1.100 and 10.0.0.200. These are internal addresses that should never be accessed from the public web server. The logs also show a request to 'http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role'.
You realize this is an SSRF attack in progress. An attacker has found that the image fetching feature does not validate the URLs users submit. The attacker submitted URLs pointing to internal services instead of public image hosts. The first requests were to 192.168.1.100, which is the internal IP of the database server. The application made a request to the database's web interface, and although the database did not return useful data, the attacker confirmed the service existed. The next request to 169.254.169.254 targeted the AWS metadata service. Because the application runs on an EC2 instance with an attached IAM role, the metadata service returned the temporary IAM credentials for that role. The attacker now has the credentials to access any AWS service the role can access, including a sensitive S3 bucket with customer data.
Your response must be immediate: take the application offline, invalidate the IAM role credentials, and begin patching the URL input validation. This scenario highlights how a seemingly minor feature-fetching a user-supplied URL-can become a gateway to a full cloud account compromise. It also shows why SSRF is so feared in cloud environments.
Common Mistakes
Confusing SSRF with CSRF (Cross-Site Request Forgery).
CSRF tricks a user's browser into making an unwanted request on a website where the user is authenticated. SSRF tricks the server itself into making requests. They are different attack vectors.
Remember: SSRF is server-side, the attacker exploits the server's ability to make requests. CSRF is client-side, the attacker exploits the user's authenticated session.
Thinking SSRF only affects web servers running on Linux.
SSRF is a vulnerability that can occur on any server that makes HTTP requests based on user input, regardless of the operating system. It is common in many programming languages and platforms.
Understand that SSRF is about insecure input handling, not the OS. It can affect Windows, Linux, or any server with an application that fetches URLs.
Believing that using HTTPS prevents SSRF.
HTTPS only encrypts the traffic; it does not validate the destination of the request. An attacker can still specify an HTTPS URL pointing to an internal server, and the request will be made over HTTPS to that internal host.
Prevention relies on input validation, not just encryption. Always validate and whitelist allowed hosts and schemes.
Assuming a Web Application Firewall (WAF) is a complete defense against SSRF.
While a WAF can block many common SSRF attempts, sophisticated attackers can bypass it using URL encoding, redirects, or an allowed domain that then redirects to an internal address. WAFs are not foolproof.
Use defense in depth: validate inputs on the server side, whitelist allowed destinations, restrict outbound network access, and disable unnecessary URL schemes.
Exam Trap — Don't Get Fooled
{"trap":"In an exam question, the scenario describes an attacker sending a malicious link to a user, who clicks it, and then the server makes a request to an internal resource. The candidate might think this is CSRF because a user action was involved. However, the key detail is that the server itself executes the request based on input in the URL, not the user's browser making the request on another site."
,"why_learners_choose_it":"Learners see the word \"request\" and \"forgery\" and associate it with CSRF. They also sometimes focus on the user clicking the link, which is a common CSRF pattern.","how_to_avoid_it":"Focus on who is making the request.
If the server makes the request (e.g., fetching data from a URL), it is SSRF. If the user's browser makes the request without the user's intent, it is CSRF. Also note that SSRF often involves a server-side function like file_get_contents() or cURL, while CSRF involves a form or script running in the user's browser."
Step-by-Step Breakdown
User Input Submission
The attacker identifies a feature in the application that takes a URL or an IP address from the user. This could be an image upload form, a file download feature, a webhook configuration, or any input that the server will use to make a network request.
Malicious URL Crafting
Instead of providing a safe external URL (like an image from a public website), the attacker crafts a URL that points to an internal resource. Common targets include private IP addresses (e.g., 10.0.0.1), cloud metadata endpoints (169.254.169.254), or internal service hostnames.
Server Execution
The server receives the submitted URL and, without proper validation, uses it to make an HTTP request (or other protocol request). The server executes this request using its own network identity and privileges, which often include access to internal networks and cloud metadata services.
Data Retrieval or Action
The internal service receives the request and responds. If the server returns the response to the attacker (basic SSRF), the attacker can read the data directly. In blind SSRF, the attacker may not see the response but can infer success through side effects like timing delays, DNS lookups, or changes in server behaviour.
Using the Information
With the data obtained, the attacker can escalate the attack. For example, cloud metadata credentials can be used to access cloud resources. Internal API keys can allow deeper network penetration. The attacker may also chain multiple SSRF requests to map out the internal network and find further vulnerabilities.
Practical Mini-Lesson
To understand SSRF in practice, you need to see how it works in real application code. Consider a PHP script that fetches an image from a URL: file_get_contents($_GET['url']). This is classic code vulnerable to SSRF. The user passes a URL parameter, and the server directly fetches it. An attacker can pass http://169.254.169.254/latest/meta-data/ and the server will return the cloud metadata. A professional developer knows to avoid such raw input. Instead, they should validate the URL against a whitelist of allowed domains, or at least check that the URL does not resolve to a private IP.
In cloud environments, SSRF is even more critical because of metadata services. AWS metadata is at 169.254.169.254, Azure metadata at 169.254.169.254 (and also a specific link-local address), and Google Cloud at 169.254.169.254. These endpoints provide instance identity documents and access tokens. Even if the attacker cannot directly read the response, blind SSRF can be used to trigger actions, such as modifying a cloud resource or exfiltrating data via DNS queries.
What can go wrong? Many developers think that checking the URL for 'http' or 'https' is enough, but it is not. Attackers can use redirects: if the attacker's server returns a 302 redirect to an internal IP, the server will follow it. Also, some applications parse URLs incorrectly, so an attacker can use formats like http://evil.com@10.0.0.1 or encode the IP in hex. Professionals should disable following redirects, validate the final resolved IP address, and restrict the outbound firewall rules for the server.
For IT cert exams, you must know that the best defense is input validation (whitelisting allowed hosts) and network segmentation (blocking outbound traffic from application servers to internal networks unless explicitly required). Understanding these practical aspects will help you both in the exam and in real-world security work.
Memory Tip
Remember SSRF by "Server Makes Requests Forged", the server does the dirty work.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Legacy Exam Context
Older materials may mention these exam versions, but learners should use the current objectives for their target exam.
SY0-601SY0-701(current version)Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
Frequently Asked Questions
Can SSRF happen over FTP or other protocols?
Yes, SSRF is not limited to HTTP. If the application accepts URLs and uses a library that supports other protocols like FTP, gopher, or file, the attacker can exploit those to read local files or interact with other services.
Is SSRF only an attack on web servers?
While it is most common in web applications, any server software that makes network requests based on user input can be vulnerable. This includes API servers, microservices, and even some desktop applications.
How can I test if my application is vulnerable to SSRF?
You can test by providing URLs to internal IP addresses (like 127.0.0.1 or 10.0.0.1) and observing if the server's response reveals data. You can also set up a listener on an external server and check if the server makes a request to it.
What is the difference between basic and blind SSRF?
In basic SSRF, the server returns the response from the internal resource directly to the attacker. In blind SSRF, the attacker cannot see the response but can still cause actions or infer information through side channels like time delays or DNS queries.
Does using a VPN protect against SSRF?
No, a VPN protects the user's traffic, not the server's. SSRF exploits the server's own network access. A VPN on the server might even expand the attack surface by giving the server access to additional internal networks.
Can SSRF be used to attack other users?
Yes, if the server uses SSRF to fetch resources that are then displayed to other users, or if SSRF is used to modify shared data, it can affect others indirectly. However, the direct victim is usually the server and the internal network.
Summary
SSRF is a serious security vulnerability that allows an attacker to trick a server into making unauthorized requests to internal resources. It is a server-side attack that exploits the trust the server has in itself and its network. The attacker supplies a malicious URL, and the server fetches it, potentially leaking sensitive data such as cloud credentials, internal API keys, or database contents. Understanding SSRF is crucial for anyone in IT security, as it can bypass traditional firewalls and lead to widespread compromise.
In certification exams, SSRF is tested across security and cloud domains. Exam questions often test the ability to identify SSRF in a scenario, distinguish it from other attacks like CSRF or XSS, and choose appropriate mitigations. The most effective defenses include rigorous input validation with allow-listing, disabling unnecessary URL schemes, and implementing strong network segmentation. Cloud-specific defenses involve disabling metadata service v1 and restricting outbound traffic from application servers.
The key takeaway for exam preparation is to recognize that any application that makes network requests based on user input is a potential vector for SSRF. Knowing how to identify it, how it differs from other vulnerabilities, and how to defend against it will serve you well both on exams and in real-world IT roles. Remember: never trust user-supplied URLs; always validate and restrict.