ssrf-preventionlisted

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/ssrf-prevention/SKILL.md. --> # SSRF Prevention Defend against Server-Side Request Forgery: cloud metadata blocking, internal IP filtering, DNS rebinding defense, allowlist-based URL fetching ## ALWAYS - Validate **every** URL fetched on behalf of a client through an **allowlist** of expected hosts. The allowlist is the only durable defense — block-lists are bypassable through encoding tricks, IPv6 dual-stack, and DNS rebinding. - Resolve the hostname **once**, validate the resolved IP against your block-list of private / reserved / link-local ranges, then connect to that pinned IP using SNI. Otherwise an attacker can race a DNS rebind between validation and connect (`time-of-check / time-of-use`). - Block at the network layer **and** at the application layer. Drop egress to `169.254.169.254`, `[fd00:ec2::254]`, `metadata.google.internal`, and `100.100.100.200` from any service that doesn't legitimately need the metadata service. - Enforce **IMDSv2** on AWS EC2 (session-token, hop-limit=1). IMDSv1 — the pattern Capital One's 2019 breach exploited — must be disabled at the instance level. - Disable HTTP redirects by default on server-side fetchers (or follow only a small bounded number, re-validating the new URL against the allowlist at each hop). The most common SSRF bypass is `https://allowed.example.com