Cbox SSRF
Cbox SSRF
Server-side request forgery is what happens when an attacker gets your server to make a request it shouldn't — at your cloud metadata endpoint, your Redis socket, an internal admin panel. Any URL your application fetches on a user's behalf (a webhook, an avatar import, an OAuth callback) is a potential SSRF vector.
cboxdk/laravel-ssrf is the guard you put in front of those requests. It resolves
the target, refuses anything that lands on a private/reserved/metadata address, and
pins the connection so the answer can't change between check and fetch.
The mental model
A URL is safe to fetch server-side only when all of these hold:
- its scheme is
http/https, - it carries no embedded credentials,
- its host isn't on a block-list (name or suffix), and
- every address it resolves to is public unicast — for IPv4 and IPv6.
The guard then hands your HTTP client connection options that pin the request to those validated addresses and disable redirects, closing the two bypasses that defeat naive checks (DNS rebinding and redirect hops).
When to use it
- Delivering webhooks to customer-supplied endpoints.
- Importing from a user-supplied URL (avatars, feeds, documents).
- Validating OAuth/SSO callback and authorize URLs.
- Anywhere a URL crosses the trust boundary from user input into an outbound fetch.
Read next
- Installation
- Quickstart — guard a request in one line
- Cookbook — webhooks, form validation, custom clients
- Architecture — the guard, the resolver, the policy
- Extending — custom resolvers and policy
- Testing — the
FakeResolverseam - Security — threat model and honest scope