Web applications often need to fetch data from external sources — such as importing files from URLs, sending notifications to webhooks, or generating previews of links. While these features provide great functionality, they also introduce a serious security risk called Server-Side Request Forgery (SSRF).

In an SSRF attack, an attacker tricks your server into making HTTP requests to unintended destinations, potentially accessing internal systems that should be protected. In this lesson, we'll explore what SSRF vulnerabilities are, how they work, and how to identify risky patterns in web applications using a real pastebin service as our example.

To understand SSRF, we first need to recognize a fundamental truth about web servers: they often need to make HTTP requests on behalf of users. When a user asks your server to "import this code from GitHub" or "send a notification to my webhook," your server becomes an HTTP client, reaching out to other services across the internet.

Here is where the vulnerability comes in. In a typical SSRF attack, an attacker provides a malicious URL where a legitimate one was expected. Instead of pointing to an external resource, this URL might target internal services that are normally unreachable from the internet. For example, an attacker might input http://localhost:8080/admin instead of https://github.com/user/file.txt.

The critical issue is trust. Your server often has privileges that external users do not. It can access internal network resources, cloud metadata endpoints, databases, and administrative interfaces. When your server makes a request to an attacker-controlled URL, it is essentially using its elevated privileges on the attacker's behalf.

The basic attack flow looks like this: an attacker finds a feature that accepts URLs as input. They provide a malicious URL pointing to an internal resource. Your server, trusting the input, makes the request. The server can then access resources the attacker could not reach directly, potentially returning sensitive data back to the attacker or performing unauthorized actions.

SSRF vulnerabilities are particularly dangerous because they break through multiple layers of security at once. Most organizations rely on network segmentation to protect sensitive systems — putting databases, admin panels, and internal APIs behind firewalls that block internet traffic. SSRF bypasses these protections entirely because the server making the request is already inside the trusted network.

One of the most notorious SSRF targets is cloud metadata services. Cloud providers like AWS, Azure, and Google Cloud expose metadata endpoints at special IP addresses (like 169.254.169.254) that provide information about the server instance, including temporary security credentials. If an attacker can force your server to request these endpoints, they might steal credentials that grant access to your entire cloud infrastructure.

Internal APIs represent another high-value target. Many organizations run internal services without authentication because they assume only trusted machines can reach them. An SSRF vulnerability turns this assumption into a critical weakness. Attackers can interact with these APIs to modify configurations, access sensitive data, or escalate their privileges within your system.

Real-world SSRF attacks have led to massive data breaches and complete infrastructure compromises. The Capital One breach in 2019, which exposed data from over 100 million customers, involved an SSRF-like vulnerability that allowed access to cloud metadata. These are not theoretical risks — they are real threats with serious consequences.

Understanding where SSRF vulnerabilities hide is crucial for both finding and preventing them. Certain feature patterns are particularly prone to SSRF issues, and learning to recognize them will help you audit applications for security risks.

• URL fetching features are the most obvious SSRF candidates. Any functionality that accepts a URL and retrieves its content creates an attack surface. This includes features that import data from external sources, download files from user-provided links, or fetch remote resources for processing. For example, a "Clone repository from URL" feature or an "Import spreadsheet from web" option both need careful SSRF protection.

• Webhook functionality is another common vulnerability point. Webhooks allow your application to notify external services when events occur, but they require your server to make HTTP POST requests to user-specified URLs. If an attacker can register a webhook pointing to http://localhost/admin/delete-all-data, your server might dutifully make that request with every triggering event.

• Link and image preview generators are frequently overlooked SSRF surfaces. When users paste URLs and your application generates rich previews by fetching the content, you are making server-side requests based on user input. Social media platforms, chat applications, and content management systems often implement this feature; without proper validation, it becomes an SSRF vector.

Other risky patterns include PDF generators that accept HTML with external resources, image processing services that fetch images from URLs, RSS feed readers, and any feature performing server-side XML/HTML parsing with external entity support. In essence, if your server makes HTTP requests based on user-controllable input, you have a potential SSRF attack surface.

Throughout this course, we'll use a pastebin application to explore SSRF vulnerabilities hands-on. A pastebin is a web service where users can store and share text snippets or code. It is a perfect learning environment because it has several realistic features that involve making HTTP requests.

Our application is built using a React frontend (utilizing CodeMirror for the editor) and an Express backend. For data persistence, it uses SQLite managed by Sequelize. The application is intentionally insecure for educational purposes—it contains hard-coded JWT secrets, permissive CORS settings, and lacks proper input validation. These weaknesses simulate a legacy internal tool or a rapid prototype, making the impact of an SSRF vulnerability even more severe.

Let's look at the main server setup to understand the foundation:

import express from 'express';
import cors from 'cors';
import authRoutes from './routes/auth';
import snippetRoutes from './routes/snippets';
import webhookRoutes from './routes/webhooks';
import importRoutes from './routes/import';

const app = express();

app.use(cors()); // Permissive CORS default
app.use(express.json());

This code creates an Express application, enables CORS (Cross-Origin Resource Sharing), and configures it to parse JSON request bodies. The express.json() middleware allows our server to accept JSON data from clients, which is how users will send URLs and other information to our endpoints.

Next, the server registers separate route modules:

app.use('/api/auth', authRoutes);
app.use('/api/snippets', snippetRoutes);
app.use('/api/webhooks', webhookRoutes);
app.use('/api/import', importRoutes);

Each of these route modules handles a specific feature area: authentication, snippet management, webhook notifications, and importing snippets. The /api/auth endpoint is particularly interesting; the application has a self-assignable admin role vulnerability. If an SSRF attack allows us to make internal requests to this endpoint, we might be able to escalate privileges or manipulate user accounts from within the trusted network.

Our pastebin has three features that make HTTP requests, and each one presents unique SSRF challenges. Understanding these features and their risks will prepare you for the hands-on exercises ahead.

• The import snippet from URL feature allows users to create a new snippet by providing a URL to existing code hosted elsewhere. For example, a user might want to import a configuration file from https://raw.githubusercontent.com/user/repo/main/config.json. The server fetches the content from that URL and creates a new snippet with the retrieved data. This feature is useful for quickly sharing code from other sources, but it is a textbook SSRF vulnerability. If we do not validate the URL properly, an attacker could provide http://localhost:3001/api/auth or http://169.254.169.254/latest/meta-data/ to probe internal services or steal cloud credentials.

• The webhook notification system lets users register callback URLs that get notified whenever certain events occur — such as when a new snippet is created or an existing one is updated. This is common in modern applications that need to integrate with external services. When someone creates a snippet, the server makes an HTTP POST request to all registered webhook URLs with details about the new snippet. The SSRF risk here is that an attacker can register a webhook pointing to internal services. Every time someone creates a snippet, your server would dutifully send that POST request to the attacker's chosen target, potentially triggering admin actions or probing internal APIs.

• The link preview generation feature enhances the user experience by showing rich previews when snippets contain URLs. If a user pastes a link to a documentation page, the application fetches that page's metadata (title, description, image) and displays a professional preview card. This requires the server to make HTTP requests to extract this information. An attacker could embed URLs to internal services in their snippets, causing the server to request those URLs whenever someone views the snippet. This can be used for network scanning, accessing internal dashboards, or exploiting other internal services.

Each of these features seems harmless in isolation — they all provide legitimate functionality that users want. The danger lies in the fact that the server is making HTTP requests based on user-controlled input without proper validation. The server has access to networks and resources that external attackers do not, and through SSRF, attackers can abuse this trust relationship.

We've covered the fundamentals of Server-Side Request Forgery vulnerabilities and how they pose serious security risks to web applications. You now understand that SSRF occurs when attackers trick servers into making HTTP requests to unintended destinations, potentially accessing internal networks, cloud metadata, and protected APIs. We've identified common attack surfaces — URL fetching, webhooks, and preview generators — and explored how our pastebin application implements all three of these risky patterns.

As you move forward, keep this mental checklist for identifying SSRF risks: Does the feature accept URLs from users? Does the server make HTTP requests based on that input? What internal resources could be accessed if the URL pointed somewhere unexpected? In the upcoming lessons, you'll get hands-on experience exploiting these vulnerabilities and learning how to defend against them properly.