Cybreach Consulting Prendre RDV →
Back to articles
Vulnerabilities

SSRF: server-side request forgery

Antoine Heriaud · December 2025 · 7 min read

SSRF (Server-Side Request Forgery) occurs when an application makes HTTP requests to a URL controlled by the attacker. Affected features: URL preview, remote file import, webhook, proxy, image fetch from a user-supplied URL. The server becomes a proxy: it issues requests from its own network, giving it access to resources unreachable from the outside.

Impact in cloud environments

The most severe SSRF impact in cloud environments is access to the instance metadata service. AWS, GCP, and Azure expose an HTTP endpoint at http://169.254.169.254/ (or http://metadata.google.internal/) accessible only from the instance. This service provides temporary IAM credentials for the instance, which grant access to cloud services according to the associated role's permissions.

SSRF exploitation example towards AWS metadata

# L'attaquant soumet cette URL dans le champ "importer une image" :
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Le serveur effectue la requête et retourne les credentials IAM temporaires :
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2026-07-09T14:00:00Z"
}

Access to internal services

Beyond the metadata service, SSRF enables access to internal services not exposed to the internet. Common examples: Elasticsearch admin interface on port 9200, unauthenticated Redis on port 6379, Kubernetes dashboard, web server management interface, internal deployment services. The attacker can also scan the internal network by testing different IP addresses and ports.

Prevention

The primary defence is strict URL validation before issuing requests. Recommended approach: whitelist of allowed domains (if target URLs are predictable), DNS resolution then validation of the resolved IP (reject RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and link-local addresses: 169.254.0.0/16), disabling HTTP redirects (an attacker can bypass initial validation with a redirect to an internal IP).

URL validation with internal IP blocking (Node.js)

const dns = require('dns').promises;
const ipaddr = require('ipaddr.js');

async function isSafeUrl(url) {
  const parsed = new URL(url);
  if (!['http:', 'https:'].includes(parsed.protocol)) return false;

  const { address } = await dns.lookup(parsed.hostname);
  const ip = ipaddr.parse(address);

  // Bloquer les plages privées, loopback et link-local
  const range = ip.range();
  return !['private', 'loopback', 'linkLocal', 'carrierGradeNat'].includes(range);
}

In cloud environments, enable IMDSv2 (Instance Metadata Service v2) on AWS: it requires a session token obtained via a PUT request, preventing simple SSRF attacks based on GET requests.

Further reading

Vulnerabilities OS command injection and HTTP header injection When a server builds a shell command by inserting unvalidated user input, the attacker can insert metacharacters to execute their own commands: read files, establish a reverse shell, extract the database. The impact is total. July 2026·7 min read → Vulnerabilities Broken access control: IDOR, privilege escalation and authorisation bypass Access control answers one question: is this user allowed to do this? The answer must be checked server-side, on every request, for every resource. When this check is missing or partial, an ordinary user can access another's data, or elevate to administrator. July 2026·10 min read → Vulnerabilities Sensitive information disclosure: error messages, versions and exposed data A stack trace in production, a Server: Apache/2.4.49 header, a cookie with an internal IP address, a log containing plaintext passwords: none of these is a directly exploitable vulnerability, but they considerably reduce the attacker's workload. July 2026·7 min read →

A question after reading?

Does your application make requests to external URLs? Send a message.

Or book a 30-minute scoping call directly

Book a call →