Mixed content errors in Laravel and Keycloak behind a reverse proxy

What the mixed content error means behind a proxy

A mixed content error means a page delivered over https asked the browser to load something over plain http. Browsers block active content such as scripts, stylesheets, iframes and form targets outright, because an attacker on the network could change them. Images, audio and video are treated as passive content, and current Chrome and Firefox try to upgrade those to https automatically before giving up.

In Chrome the console message looks like this:

Mixed Content: The page at 'https://app.example.com/login' was loaded over HTTPS,
but requested an insecure stylesheet 'http://app.example.com/css/app.css'.
This request has been blocked; the content must be served over HTTPS.

On a normal single server the application terminates TLS itself and knows the request was secure. Behind a proxy the picture changes:

Browser --https--> Load balancer / nginx / Cloudflare --http--> Laravel or Keycloak

The application receives an ordinary http request on port 80 or 8080. Unless something tells it otherwise, it believes the visitor is on http, so helpers such as asset(), url(), route() and redirect builders all produce http:// addresses. Keycloak does the same with its login form action, its resource paths and the redirect it sends back to your application.

The standard way to pass the original scheme along is the X-Forwarded-Proto header, set by the proxy to https. The newer standard Forwarded header carries the same information as proto=https. The application must also be told which proxies it may believe, otherwise it ignores those headers, which is the correct and safe default.

Common causes

Almost every case comes down to one of these. Work out which applies before changing code, because forcing https in the application can hide a broken proxy that will bite you elsewhere.

If only one or two images on a page are http and everything else is fine, you probably have the last cause, which the WordPress mixed content guide covers in detail. If every generated address is http, the proxy chain is the problem.

How to find where the https is lost

Start in the browser. Open DevTools, go to the Console and reload. Note the exact insecure addresses, then open the Network panel and look at the response headers of the page itself, especially any Location header on a redirect after login.

Next, see what the server sends without the browser getting involved:

curl -s https://app.example.com/login | grep -o 'http://[^"]*' | sort -u
curl -sI https://app.example.com/dashboard | grep -i '^location'

If the first command prints addresses on your own domain, the application is generating them. Now check what actually reaches the application. Temporarily add a route in Laravel and visit it through the proxy:

// routes/web.php (remove after testing)
Route::get('/proxy-test', fn (\Illuminate\Http\Request $r) => [
    'scheme'     => $r->getScheme(),
    'secure'     => $r->isSecure(),
    'xfp_header' => $r->header('X-Forwarded-Proto'),
    'client_ip'  => $r->ip(),
    'remote'     => $r->server('REMOTE_ADDR'),
]);

Read the result like this:

• xfp_header is empty. The proxy is not sending the header. Fix the proxy.
• xfp_header is https but secure is false. The header arrives but Laravel does not trust the address in remote. Fix TrustProxies.
• xfp_header is http. A second proxy, or Cloudflare Flexible mode, is overwriting it.

For Keycloak, request the OpenID discovery document and check every endpoint starts with https:

curl -s https://auth.example.com/realms/myrealm/.well-known/openid-configuration | grep -o '"[a-z_]*endpoint": *"[^"]*"'

Setting X-Forwarded-Proto at the proxy

The proxy that terminates TLS must state the original scheme. In nginx, inside the https server block:

location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host  $host;
    proxy_set_header X-Forwarded-Port  $server_port;
}

In Apache with mod_proxy and mod_headers, inside the port 443 virtual host:

ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
ProxyPass        / http://127.0.0.1:8000/
ProxyPassReverse / http://127.0.0.1:8000/

AWS Application Load Balancers, Traefik and most Kubernetes ingress controllers add X-Forwarded-Proto by default, so with those the fault is usually trust in the application, or an extra nginx layer that replaces the header.

Two proxies in a row

If a load balancer or Cloudflare sits in front of your own nginx, $scheme in nginx is the scheme of the hop from the load balancer, which may be http. Pass the outer value through instead:

map $http_x_forwarded_proto $fwd_proto {
    default $http_x_forwarded_proto;
    ''      $scheme;
}
# then in the location block
proxy_set_header X-Forwarded-Proto $fwd_proto;

The application changes: Laravel and Keycloak

Laravel 11 and later

Trust the proxy in bootstrap/app.php. Use the proxy's address or private range where you know it:

use Illuminate\Foundation\Configuration\Middleware;
use Illuminate\Http\Request;

->withMiddleware(function (Middleware $middleware) {
    $middleware->trustProxies(
        at: ['10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16'],
        headers: Request::HEADER_X_FORWARDED_FOR |
                 Request::HEADER_X_FORWARDED_HOST |
                 Request::HEADER_X_FORWARDED_PORT |
                 Request::HEADER_X_FORWARDED_PROTO
    );
})

Laravel 10 and earlier

Edit app/Http/Middleware/TrustProxies.php and set the $proxies property to the proxy addresses, or to '*' if the application is only reachable through the proxy. The default $headers value already includes the forwarded proto header.

forceScheme as a backstop

If the proxy cannot be changed, for example on some managed platforms, force https for generated addresses in AppServiceProvider:

public function boot(): void
{
    if ($this->app->environment('production')) {
        \Illuminate\Support\Facades\URL::forceScheme('https');
    }
}

This fixes links and assets but does not make $request->isSecure() true, so secure cookies and anything that checks the request itself still need trusted proxies. Also set APP_URL=https://app.example.com, which is what Artisan commands, queued mail and scheduled jobs use, since they have no incoming request.

Keycloak 25 and later

Current Keycloak replaces the old --proxy edge option with --proxy-headers. With TLS ending at the proxy:

bin/kc.sh start \
  --hostname https://auth.example.com \
  --proxy-headers xforwarded \
  --http-enabled true

Or as environment variables in Docker: KC_HOSTNAME=https://auth.example.com, KC_PROXY_HEADERS=xforwarded and KC_HTTP_ENABLED=true. Use forwarded instead of xforwarded if your proxy sends the standard Forwarded header. Setting the full https hostname also fixes the issuer in tokens, which otherwise breaks sign-in for your client applications.

Platform notes

• Cloudflare. Set SSL/TLS to Full (strict) and install an origin certificate. Flexible mode connects to your server over http, so your origin is told the truth: the request is http. That produces mixed content or a redirect loop. See redirects in Cloudflare and redirect loops.
• Plesk. For an application in Docker or on a local port, add the proxy_set_header lines from the nginx example under Apache and nginx Settings, Additional nginx directives, for that domain.
• Kubernetes ingress-nginx. The controller sends the forwarded headers itself. If it sits behind a cloud load balancer that ends TLS, enable use-forwarded-headers in the controller ConfigMap so it passes the outer scheme on.
• Other frameworks. Django uses SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https'), Express uses app.set('trust proxy', 1), and Spring Boot uses server.forward-headers-strategy=native. The principle is identical.

Once the scheme is right, add Strict-Transport-Security so browsers never try http first. The HSTS guide shows how, and security headers in nginx covers the rest of the header set.

The fix, step by step

Edge cases worth knowing

• Trusting every proxy. '*' in Laravel or a permissive proxy setting in Keycloak is only safe if the application port is closed to the internet. Otherwise a visitor can forge X-Forwarded-Host and poison password reset links. Firewall the port or list the proxy addresses.
• upgrade-insecure-requests. A Content-Security-Policy: upgrade-insecure-requests header makes the browser rewrite http subresources to https. It hides symptoms but does not fix server-side redirects, form actions in emails or token issuers. Treat it as a safety net. The CSP for frameworks guide explains how to add it.
• Cached pages. Full-page caches and CDNs may still hold copies with http addresses. Purge them after the fix.
• Livewire, Vite and Inertia. Vite's dev server and old compiled manifests can still point at http. Rebuild assets and check ASSET_URL if you set one.
• Keycloak admin console. A blocked iframe or script in the admin console usually means the admin hostname differs from the public one. Set hostname-admin to its https address or leave it unset.

Keeping it fixed

1. Keep the proxy headers in a shared snippet included by every site's server block, so new applications inherit them.
2. Add the curl check for http addresses on your own domain to your deployment script and fail the deploy if it prints anything.
3. Keep APP_URL, KC_HOSTNAME and similar settings in version-controlled environment templates, with https values.
4. When you add a new layer, such as a CDN in front of an existing load balancer, retest the scheme the application sees with the test route before going live.

Run a security audit after each infrastructure change, and check redirect behaviour with the https redirects guide if visitors arriving on http are not sent straight to https.