Download the PHP package cboxdk/laravel-ssrf without Composer
On this page you can find all versions of the php package cboxdk/laravel-ssrf. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package laravel-ssrf
Cbox SSRF
A hardened, config-driven guard against server-side request forgery (SSRF) for outbound URLs in Laravel. It validates any URL your application is about to fetch — a webhook endpoint, an avatar/import URL, an OAuth callback — and refuses anything that points at a private, reserved, or cloud-metadata address.
Why
An attacker who controls a URL your server fetches can reach your internal
network: http://169.254.169.254/latest/meta-data/ (cloud credentials),
http://127.0.0.1:6379/ (Redis), http://10.0.0.5/admin. A correct SSRF guard
is deceptively hard — most home-grown checks miss DNS rebinding, redirect hops, or
IPv6 transition forms. This package handles them, and is honest about the one thing
application code cannot fully solve (see Scope).
What it defends against
- DNS rebinding (TOCTOU) — resolves once and pins the connection to that exact
IP via
CURLOPT_RESOLVE(keeping TLS/SNI intact), with a post-connection check that the socket connected to a validated address. - Redirect-based bypass — refuses to follow redirects on guarded requests, so a
30xto an internal host can't smuggle the request onward. - Alternate IP encodings — decimal (
2130706433) and hex (0x7f000001) IPv4 literals are normalized before validation (browser-redirect mode). - IPv6 transition forms — IPv4-mapped (
::ffff:127.0.0.1), IPv4-compatible, 6to4 (2002::/16), NAT64 (64:ff9b::/96), and Teredo (2001::/32) are blocked wholesale and their embedded IPv4 is extracted and re-checked (the Symfony CVE-2026-48736 class). - Cloud metadata — AWS/GCP/Azure
169.254.169.254, AWS IMDSv2 IPv6fd00:ec2::254, Alibaba100.100.100.200, Oracle192.0.0.192, and themetadata.google.internalname. - Reserved ranges — loopback, RFC 1918, link-local, ULA, CGNAT
(
100.64.0.0/10), TEST-NET, benchmarking, and multicast, for IPv4 and IPv6. - URL tricks — embedded credentials (
user:pass@host), blocked host suffixes (.internal,.local,.localhost,.intra), and non-http(s) schemes (file://,gopher://,dict://, …).
Install
The service provider auto-registers. Publish the config to tune the policy:
Usage
Guard an outbound request
The URL is validated and pinned at send time, so the URL that is checked is by construction the URL that is fetched. Every request this client makes is guarded, so one client can serve a loop:
Passing the URL up front still works and additionally fails fast, before a request object exists — useful when you want the rejection where the URL is chosen rather than where it is sent:
Validate user-supplied URLs (form input)
Check or assert directly
Per-sink scheme & credential rules
One guard (with one shared block-list policy) can serve several outbound sinks with different rules. Pass a scheme allow-list and/or permit embedded credentials for that call only — the IP/host enforcement is never relaxed:
allowed_schemes and allow_credentials in config/ssrf.php set the defaults; a
per-call override wins for that call and inherits every other setting.
Browser-redirect targets (OAuth authorize URLs)
A URL you hand to the user's browser as a redirect — rather than fetch yourself — is validated without a DNS lookup (the browser resolves it), while still blocking IP-literal and blocked-host targets:
Configuration
config/ssrf.php exposes the full policy: allowed_schemes, allow_credentials,
blocked_hosts, blocked_host_suffixes, blocked_ips, blocked_cidrs, pin_dns,
and a master enforce switch. A single-tenant/on-prem install that must reach internal hosts can
set SSRF_ENFORCE=false (scheme, credential, and blocked-host checks still run).
Honest scope
An application-layer guard is defense in depth, not a complete fix:
- A network egress allow-list is the real answer. A firewall / security-group /
egress proxy that can only reach approved destinations closes SSRF completely,
because it doesn't depend on parsing the URL the same way the HTTP client does.
Use this guard and restrict egress. Block
169.254.169.254at the network and require IMDSv2 (hop-limit 1, token-required). - An HTTP proxy defeats connection pinning — when
HTTP_PROXYis set, the proxy resolves DNS, not this library, so rebinding protection no longer applies. - Response content is out of scope. The guard controls where a request goes, not what comes back; SSRF-via-response, stored XSS, and deserialization remain the caller's responsibility.
Testing
Bind the FakeResolver to make DNS deterministic in your own tests:
Documentation
Full docs in installation, architecture, testing.
License
MIT © Cbox. See LICENSE. Security policy: SECURITY.md.
All versions of laravel-ssrf with dependencies
guzzlehttp/guzzle Version ^7.8.2 || ^8.0
guzzlehttp/promises Version ^2.0 || ^3.0
illuminate/contracts Version ^12.0 || ^13.0
illuminate/http Version ^12.0 || ^13.0
illuminate/support Version ^12.0 || ^13.0
psr/http-message Version ^1.1 || ^2.0
symfony/http-foundation Version ^7.0 || ^8.0