Contenu mixte derrière un proxy : pourquoi votre appli produit des liens http://, et le correctif par cadriciel.

Le navigateur du visiteur se connecte au proxy en HTTPS. Le proxy déchiffre la requête et la transmet à votre appli sur un port local, en HTTP. Du côté de l’appli, rien n’indique que la requête d’origine était sécurisée. Un cadriciel qui construit des URL absolues à partir de la requête reçue (aides pour les ressources, appels url() et redirect(), URL de rappel OAuth, liens du plan du site) écrit http://.

Les proxys transmettent les détails d’origine dans des en-têtes. Votre cadriciel les ignore tant que vous ne lui dites pas quel proxy croire, parce que n’importe quel client peut envoyer son propre en-tête X-Forwarded-Proto.

Les navigateurs séparent les ressources http:// d’une page HTTPS en deux groupes :

• Une boucle de redirection (ERR_TOO_MANY_REDIRECTS) est le même bogue vu de l’autre côté : l’appli force le HTTPS, voit du HTTP à chaque requête et redirige encore.
• Des connexions qui ne tiennent pas : un témoin de session marqué secure n’est jamais défini quand le cadriciel croit la connexion en HTTP.
• Tous les visiteurs ont la même adresse IP, celle du proxy, dans vos journaux et vos limites de débit. C’est X-Forwarded-For qui est ignoré.

Sur Canner, Caddy termine le HTTPS et transmet à votre appli sur 127.0.0.1. Voici les en-têtes que reçoit votre appli. Caddy ignore les valeurs X-Forwarded-* envoyées par les clients : ce sont les siennes.

Faites confiance à l’adresse du proxy, pas à tout le monde. Sur Canner, cette adresse est l’adresse de bouclage, parce que votre appli écoute sur 127.0.0.1. La dernière colonne indique ce que la commande de démarrage par défaut de Canner règle déjà.

// Express
app.set("trust proxy", "loopback");

# Django (settings.py)
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

# Flask
from werkzeug.middleware.proxy_fix import ProxyFix
app.wsgi_app = ProxyFix(app.wsgi_app, x_for=1, x_proto=1, x_host=1)

# Rails (config/environments/production.rb, Rails 8 default)
config.assume_ssl = true
config.force_ssl = true

// Laravel (bootstrap/app.php)
->withMiddleware(function (Middleware $middleware): void {
    $middleware->trustProxies(at: '127.0.0.1');
})

# Spring Boot (application.properties)
server.forward-headers-strategy=native

Des réglages comme trust proxy: true, trustProxies(at: '*') ou --forwarded-allow-ips='*' croient n’importe quel en-tête X-Forwarded-* de quiconque peut joindre l’appli. La documentation d’Express prévient qu’un client peut alors fournir n’importe quelle valeur, à moins que le dernier proxy écrase les en-têtes. Sur une plateforme où votre appli n’accepte de connexions que sur l’adresse de bouclage, faire confiance au bouclage est le réglage exact.

Content-Security-Policy: upgrade-insecure-requests fait réécrire par le navigateur les sous-ressources http:// en https://, y compris celles qui seraient bloquées. Le symptôme disparaît de la page, mais redirections, témoins, courriels et réponses d’API gardent le mauvais schéma. Corrigez d’abord le paramètre du cadriciel.

Ajoutez une route temporaire qui affiche le schéma, l’hôte et l’IP du client tels que les voit votre cadriciel, déployez, ouvrez-la en HTTPS, puis supprimez-la. La version Express est ci-dessous; chaque cadriciel a son équivalent (request.is_secure() dans Django, request.ssl? dans Rails, $request->secure() dans Laravel). Définissez les valeurs nécessaires avec l’interface en ligne de commande (canner env set) ou le tableau de bord, et lisez la sortie de l’appli dans les journaux.

// A throwaway route: what does the app think the request was?
app.get("/_debug/proto", (req, res) => {
  res.json({
    protocol: req.protocol,        // want "https"
    secure: req.secure,            // want true
    host: req.hostname,            // want your public hostname
    ip: req.ip,                    // want the visitor's IP, not 127.0.0.1
    xfp: req.get("x-forwarded-proto"),
  });
});

Si l’URL http:// est codée en dur (un champ de CMS, une valeur .env comme APP_URL=http://…, une ligne de base de données d’avant le HTTPS), aucun réglage de proxy ne la change. Cherchez http:// dans le code source de la page et corrigez la valeur à sa source. D’autres guides sont dans hébergement par cadriciel.