SSRF testing proven with an out-of-band callback
Server-side request forgery (SSRF) is when an attacker makes your server fetch a URL of their choosing — reaching internal services, cloud metadata endpoints or your private network from the trusted side. Sintropyc proves SSRF with a real out-of-band callback the server actually makes, not a URL that merely appears in a response.
Why SSRF is so dangerous in the cloud
Your server sits inside a trusted network. If an attacker can steer its outbound requests, they inherit that trust:
- Cloud metadata (
169.254.169.254) — often a path to temporary credentials and account takeover - Internal services with no auth because they assume the network is private (admin panels, databases, dashboards)
- Port and network scanning from inside the perimeter
- Bypassing IP allowlists by originating from your own server
Where SSRF hides
Anywhere your app fetches a URL, imports from a link, renders a preview or calls a webhook is a candidate — including features that don't look like fetchers: a PDF generator loading images, an avatar-by-URL, an SSO metadata import, a link unfurl.
Most SSRF is blind — the response never comes back to the attacker. That's why detection has to rely on the server reaching out, not on reflected content.
How Sintropyc tests it
Sintropyc is an autonomous AI penetration testing agent. It signs in as real users across different roles, drives your product the way a customer would, and proves every finding with a working exploit — never a scanner guess. Each finding is checked by a human before it reaches you, comes with the exact fix, and is attacked again after you ship it to confirm it held.
For SSRF, Sintropyc feeds attacker-controlled URLs into every fetch-like input and watches a unique out-of-band canary for a real hit from your server. When the canary fires, that is the proof — your server made the request. It then assesses what the position can reach (metadata, internal hosts) with the smallest safe evidence.
What you get
- Every URL-handling and webhook feature tested for forced requests
- Each finding proven by a real server-side callback to a unique canary
- Reachability assessed (metadata, internal services) without exfiltrating secrets
- The fix (allowlist, metadata block, egress control) and a retest
Common questions
What's an out-of-band canary?
A unique, attacker-controlled endpoint Sintropyc plants in the payload. If your server requests it, the request lands on the canary — undeniable proof the SSRF is real, even when nothing is reflected back.
Will you actually read our cloud credentials?
No. Reachability is demonstrated with the smallest safe proof (that the metadata endpoint is reachable), not by exfiltrating live keys. Full exploitation happens only with your explicit go-ahead.
Does a WAF or allowlist protect us?
Sometimes — but allowlists are often bypassable via redirects, DNS rebinding or alternate IP encodings. Sintropyc tests whether yours actually holds rather than assuming it does.