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 Server-Side Request Forgery: allowlisting the destination of a server-side fetch, when re-resolution between check and connect matters, redirect and scheme bypasses, parsers that fetch on their own (XXE, SVG, HTML-to-PDF), cloud metadata, and keeping the response from becoming an oracle. Use when fetching a client-supplied URL, wiring webhooks, image proxies, PDF or preview renderers, or reviewing any HTTP-client wrapper. ## ALWAYS - Constrain the destination with an **allowlist of hosts you intend to reach**, not a denylist of addresses you intend to avoid. A denylist has to enumerate every spelling of every internal address — decimal and octal IPv4, IPv6 and IPv4-mapped IPv6, a hostname whose A record is private, a public wildcard resolver like `nip.io` that encodes any address into a name — and it only has to be wrong once. - Know which of the two controls you built, because it decides whether re-resolution matters. An **allowlist of hostnames** survives DNS rebinding: the attacker controls DNS only for names they own, and those names are not on the list. An **IP-range check** does not: the name resolves to a public address when you validate and a private one when you connect, and the two resolutions are independent. If your control is address-based, reso