No SSRF protection for HTTP clienttt.

[CandleHeads]

Laravel Version
13

PHP Version
8.5

Database Driver & Version
No response

Description
When a user-controlled $url is passed directly to Http::get(), it can be abused for SSRF attacks. An attacker can probe ports and internal services on your server (for example, checking whether MySQL is listening on port 3306) or access cloud metadata endpoints such as http://169.254.169.254/latest/meta-data/ on AWS, potentially exposing temporary IAM credentials and allowing further compromise.

Symfony has an implementation for this problem: https://symfony.com/blog/new-in-symfony-5-1-server-side-request-forgery-protection

Steps To Reproduce
If you have an AWS instance created before around 2024, IMDSv1 is enabled by default. Calling Http::get('http://169.254.169.254/latest/meta-data/...') can return the instance's temporary AWS credentials.

[maulanaa121]

I don't think you should manually verify the Passport access token using hash_hmac().

Laravel Passport already handles access-token validation through its authentication guard. You can protect your API route with Passport:

Route::get('/user', function (Request $request) {
    return $request->user();
})->middleware('auth:api');

Then send the token as a Bearer token:

Authorization: Bearer YOUR_ACCESS_TOKEN

Passport will handle the token parsing and signature/expiration/revocation checks for you.

If you really need to inspect or verify the JWT manually, you should use a JWT library and verify it using Passport's configured public key and the algorithm specified by the token, rather than recreating the signature with hash_hmac('SHA256', ...).

So the main issue with the current implementation is that it is trying to reproduce Passport's token verification logic manually.

[wasifahmed85]

Problem

Laravel's Http:: facade (built on Guzzle) has no built-in SSRF protection. If a user-controlled URL is ever passed to Http::get($url) — e.g., a webhook URL, an "import from URL" feature, avatar-fetching, etc. — an attacker can point it at:

• Internal services: http://127.0.0.1:6379, http://169.254.169.254/latest/meta-data/ (cloud metadata endpoints — AWS/GCP/Azure credential theft)
• Internal-only hosts: http://internal-admin.local
• Redirect chains that bounce from an allowed public URL to an internal one

Since Laravel doesn't validate or restrict the destination host by default, this is a classic SSRF vector any time a URL from user input reaches the HTTP client.

Why it's not built in

Guzzle (and thus Laravel's client) is a general-purpose HTTP client — restricting destinations by default would break legitimate internal API calls, so Laravel leaves this to the developer. But there's no opt-in helper either, which means most developers roll their own (often incorrectly, e.g. missing IPv6/DNS-rebinding checks).

Suggested improvements

1. A middleware/guard option on the HTTP client:

Http::withOptions([
    'allow_redirects' => false, // prevent redirect-based bypass
])->withMiddleware(BlockPrivateIps::class)
  ->get($url);

2. Built-in helper, e.g.:

Http::ssrfSafe()->get($url); // rejects private/reserved IP ranges, link-local, loopback

Should resolve DNS first and check the resolved IP (not just the hostname string) against RFC 1918 / loopback / link-local ranges, and re-check on every redirect hop (to stop DNS-rebinding and open-redirect bypasses).

3. Config-level allowlist/denylist for outbound host patterns, similar to how CSP works, so teams can enforce it globally rather than per-call.

Workaround today

use GuzzleHttp\RequestOptions;

$ip = gethostbyname(parse_url($url, PHP_URL_HOST));
if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) === false) {
    abort(422, 'URL not allowed');
}

This must run after DNS resolution and be re-checked on redirects, or it's bypassable.