How to use the SSRF Security Testing Checklist agent skill

What the skill makes the agent do

Once the skill is active, the agent follows a checklist rather than improvising. The checklist covers spotting features that are likely to be vulnerable, such as URL preview generators, document imports from URLs, webhooks and PDF or screenshot export. It then walks through setting up a callback listener to detect blind SSRF, checking cloud metadata endpoints on AWS, GCP and Azure, and trying filter bypass methods such as IP encoding, DNS rebinding and redirect chains.

The agent also considers how SSRF could be escalated, tracks which checklist items are complete, and suggests next steps based on what it finds.

Install the skill from the ZIP

Download the ZIP for the offensive-ssrf skill from this page and unzip it. The skill folder contains a single file, SKILL.md. Place the offensive-ssrf folder in one of these locations:

• Personal skills: ~/.claude/skills/
• Project skills: the .claude/skills/ folder inside a specific project
• Claude apps: upload the ZIP under Settings → Capabilities → Skills

Trigger the skill with natural requests

You do not need a special command. The skill is meant to activate when the conversation involves SSRF topics. The source lists trigger phrases including SSRF, server-side request forgery, blind SSRF, cloud metadata, AWS metadata, GCP metadata, SSRF bypass, DNS rebinding, redirect chain, SSRF RCE and internal port scan.

Describe your context in the request so the agent can judge which checklist items apply. For example, state that the target is a web application you are authorised to test, and name the feature under review.

• Walk me through an SSRF checklist for the PDF export feature on this app. I have written authorisation to test it.
• Which bypass techniques should I try if the URL fetcher blocks 127.0.0.1?
• Set up a blind SSRF test plan for our webhook configuration page and track what is done.
• Review our URL preview code for SSRF exposure and list the cloud metadata paths to check on AWS and GCP.

What the checklist covers

The methodology is organised as a shortcut and a fuller set of sections. The core workflow is to identify vectors, set up a listener, test internal addresses, observe responses, check callbacks, try bypasses if protection exists, and then pick an escalation path.

Bypass techniques are grouped into allowlist bypasses and denylist bypasses. Denylist examples include alternate IP representations such as decimal, octal and hex forms, IPv6 variations, URL encoding tricks and case manipulation.

• Identify vectors: URL inputs, proxy features, file processing and integration points
• Set up a callback listener: a public server, Burp Collaborator, Interactsh or canarytokens.org
• Test internal access: localhost, 127.0.0.1, 0.0.0.0, internal hostnames and 169.254.169.254 cloud metadata
• Observe responses for timing differences, error messages, content leakage and callbacks

Safety notes on scripts and network access

According to the skill listing, offensive-ssrf requires nothing extra, does not run scripts and does not use the network itself. The skill is a set of instructions for the agent, so any network activity would come from the testing work you direct, not from the skill files.

The skill is offensive methodology. Only use it against systems you own or have written permission to test. Unauthorised testing may be illegal. The file lists techniques only and gives no defensive remediation, so pair it with your own fixes and secure coding guidance when reporting.

Tips for better results

Give the agent scope and context up front, including what is in and out of bounds. Ask it to keep a running checklist so you can see which items are done. When a probe is blocked, ask for the next bypass family rather than retrying the same payload.

• State the authorisation and scope in the first message
• Name the specific feature, such as a webhook or preview generator
• Ask for progress tracking and next-step suggestions after each finding