insecure XHR mixed content CORS error

[clifmo]

Bug description

I installed a new site using the Statamic CLI to test a solo site and decided to deploy to my home server behind a reverse proxy. I updated .env APP_URL to the secure URL and brought up the site. The frontend works fine, and control panel mostly works but content is partially loading due to insecure/mixed content. Checking network tabs shows Axios XHR requests sent to the site URL but over HTTP.

Is there some build command I should run after updating APP_URL? I've run every artisan command I can think of. Naturally my thought is to use a middlware but I just noticed there's no Kernel.php in this site. Should I be adding statamic to an existing Laravel installation?

This seems like a very simple thing I'm missing. If I paste and navigate directly to these HTTP URLs they properly redirect and the content is rendered. It's just CORS that's failing. How can we disable or configure CORS in a statamic site? Are we expected to do this on the web server? What's going on?

    php artisan clear-compiled && \
    php artisan config:clear && \
    php artisan cache:clear && \
    php artisan view:clear && \
    php artisan config:cache

How to reproduce

Use ngrok to simplify and illustrate the behavior:

1. Install a new Statamic site, login to cp, do stuff. It works.

2. Install ngrok and serve
   brew install ngrok
php artisan serve
ngrok http 8000

3. Update .env APP_URL to public HTTPS endpoint.

4. Navigate to HTTPS endpoint see everything is loading via HTTP.

Logs

Devtools Console:
Blocked loading mixed active content “http://slurp.clifmo.com/cp/updater/count”
posts
Blocked loading mixed active content “http://slurp.clifmo.com/cp/collections/posts/entries?sort=date&order=desc&page=1&perPage=50&columns=title,slug,status”
Blocked loading mixed active content “http://slurp.clifmo.com/cp/fields/field-meta

Network tab:
POST http://slurp.clifmo.com/cp/fields/field-meta
POST http://slurp.clifmo.com/cp/fields/field-meta
GET http://slurp.clifmo.com/cp/collections/posts/entries?sort=date&order=desc&page=1&perPage=50&columns=title,slug,status
GET http://slurp.clifmo.com/cp/updater/count

Environment

lifmo@docker01:~/vacuum-solo$ docker exec -it vacuum-solo-slurp-1 php please support:details

Environment
Application Name: Extended Vacuum Solo
Laravel Version: 11.34.2
PHP Version: 8.3.14
Composer Version: 2.8.3
Environment: production
Debug Mode: OFF
URL: slurp.clifmo.com
Maintenance Mode: OFF
Timezone: EST
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: file
Database: sqlite
Logs: stack / single
Mail: log
Queue: sync
Session: file

Statamic
Addons: 1
Sites: 1
Stache Watcher: Disabled (auto)
Static Caching: Disabled
Version: 5.41.0 Solo

Statamic Addons
statamic/ssg: 3.1.0

Installation

Starter Kit using via CLI

Additional details

No response

[duncanmcclean]

If you're using a proxy, you'll need to configure "trusted proxies" in order for the HTTPS stuff to work properly: https://laravel.com/docs/master/requests#configuring-trusted-proxies

[clifmo]

Traefik (rev. proxy) is properly redirecting it to HTTPs. I've tried adding fully permissive CORS headers to NGINX, too. But it seems like a bandaid over the fact that XHR requests are unencrypted to begin with.

I tried adding cross origin headers to public/index.php.

 header("Access-Control-Allow-Origin: *");
    header("Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token, X-API-KEY, Origin, X-Requested-With, Content-Type, Accept, Access-Control-Request-Method");
    header("Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE");
    header("Allow: POST, GET, OPTIONS, PUT, DELETE");

I wondered if it was similar to this old Axios issue. I hacked an override via DevTools but that didn't help.

Trusting all proxies doesn't seem to have an effect.

->withMiddleware(function (Middleware $middleware) {
       $middleware->trustProxies(at: '*');
})

[clifmo]

It appears I have resolved this by forcing HTTPS in Laravel.

AppServiceProvider.php

public function boot(): void 
{
  if(env('FORCE_HTTPS',false)===true) {
      URL::forceScheme('https');
  }
}

.env

FORCE_HTTPS=true

[duncanmcclean]

Glad you managed to get it sorted! 🎉

Like I said on Bluesky, it's usually a trused proxies thing, but if that doesn't work, forcing the scheme will do it.

[mtimoustafa]

I've also run into this issue and fixed it by forcing HTTPS as @clifmo described above.

I'm running into the issue on Fly.io, so I might have misunderstood how to bypass proxies using trustProxies(). Here's how I set up the middleware in bootstrap/app.php:

<?php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware): void {
        # Allow Fly as a proxy to use HTTPS and avoid mixed content browser errors
        # This currently does not work, and I'm not sure why. HTTPS is being forced in
        # AppServiceProvider.php using the FORCE_HTTPS environment variable, instead.
        # https://github.com/statamic/cms/discussions/11216
        $middleware->trustProxies(at: [
          '0.0.0.0',
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions): void {
        //
    })->create();

I don't have a specific ask here - just wanted to share in case it helps anyone 🙂