Server-side request forgery (SSRF)
A server-side fetch crosses the feature’s destination, network, or credential policy.
Candidate CWE: CWE-918
Test hypothesis#
Start with an ordinary controlled receiver. In the replica, compare a policy-permitted destination with an owner-designated prohibited canary, and separately test one controlled redirect between them.
Evidence required#
Correlated server/receiver logs show the prohibited request or synthetic authority transfer. State whether evidence proves DNS, HTTP connectivity, readable response, or credential forwarding.
Rule out false positives#
Intended public URL fetching, a callback from your own browser, or DNS resolution without HTTP access does not prove the broader claim.
Playbook and command references#
- Server-side fetching and network trust boundaries — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.
Find the associated command snippets
Referenced by these target playbooks#
Report checklist#
- Capture the affected version, configuration, identities, and object ownership.
- Preserve a valid baseline and a negative control.
- Reproduce the forbidden data access, action, or state change on controlled fixtures.
- Explain the intended security rule and why the observed behavior violates it.
- State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.
Conditional ATT&CK mapping#
- T1552.005 · Unsecured Credentials: Cloud Instance Metadata API — Only if: SSRF or local access reaches cloud instance metadata and demonstrates access to credential-bearing metadata; use isolated fixtures or explicitly permitted controlled identities. Not established by: An outbound callback, generic internal reachability, or harmless metadata document alone does not prove credential access. Do not infer a metadata-to-cloud takeover chain.