Vérificateur de redirection vers HTTPS

Comment fonctionne cette vérification

Scanaris demande ta page en http://, sans le s, sans suivre les redirections, et regarde ce que répond le serveur. S'il renvoie un code de redirection (301, 302, 307 ou 308) vers une URL https://, tout va bien. S'il répond 200 et sert la page en clair, il ouvre un constat de sévérité moyenne : la version non chiffrée de ton site existe et fonctionne. S'il redirige mais que la destination est encore en http:// (par exemple de la racine vers http://www), il ouvre un constat de sévérité faible : la chaîne de redirections a un maillon non chiffré. Seule l'URL scannée est testée ; le comportement devrait être le même sur toutes les routes, pas seulement sur la page d'accueil.

Pourquoi c'est important

Tant qu'une version HTTP répond, n'importe quel vieux lien, n'importe quelle adresse tapée à la main et n'importe quel réseau public peuvent amener l'utilisateur sur ton site sans chiffrement. Dans cet état, celui qui contrôle le réseau (le wifi de l'aéroport, un fournisseur malveillant) lit ce qui est envoyé et peut modifier la page avant qu'elle n'arrive. C'est la base des attaques de l'homme du milieu. Un 301 vers HTTPS ferme cette porte à la première requête, et HSTS la ferme pour toutes les suivantes.

Comment corriger selon ton hébergement

• Vercel, Netlify, Cloudflare Pages, Railway, Render : la redirection est activée d'office. Si tu vois le constat, le domaine pointe généralement vers un autre serveur ou un proxy devant répond en HTTP.
• Cloudflare comme proxy : active « Always Use HTTPS » et règle le mode SSL sur « Full (strict) ». Avec « Flexible », le tronçon entre Cloudflare et ton serveur passe en clair.
• nginx :

server {
  listen 80;
  server_name tondomaine.com www.tondomaine.com;
  return 301 https://$host$request_uri;
}

• Apache : dans le VirtualHost du port 80, Redirect permanent / https://tondomaine.com/.
• Express derrière un proxy : un middleware qui vérifie req.headers['x-forwarded-proto'] !== 'https' et répond par res.redirect(301, 'https://' + req.headers.host + req.url), avec app.set('trust proxy', 1).

Utilise un 301 ou un 308 (permanents) et pas un 302 : les moteurs de recherche consolident l'autorité sur la version HTTPS et les navigateurs mettent le saut en cache. Ajoute ensuite l'en-tête HSTS, que mesure la vérification HSTS faible, pour que le navigateur n'essaie même plus HTTP la fois suivante.

Vérifie que c'est corrigé

curl -sI http://tondomaine.com | grep -iE "^HTTP|^location"
curl -sI http://tondomaine.com/une-page-quelconque | grep -iE "^HTTP|^location"
curl -sI http://www.tondomaine.com | grep -iE "^HTTP|^location"

Les trois doivent répondre 301 ou 308 avec un Location commençant par https://. Si la deuxième ne redirige pas, ta règle ne couvre que la page d'accueil.

Questions fréquentes

Avoir HTTPS activé ne suffit-il pas ?

Non. Avoir un certificat signifie que la version sécurisée existe ; la redirection signifie que la version non sécurisée n'est pas utilisée. Sans elle, les deux coexistent.

Pourquoi 301 et pas 302 ?

Le 302 est temporaire : les navigateurs redemandent la version HTTP à chaque fois et les moteurs ne transfèrent pas l'autorité. Le 301 (ou le 308, qui conserve en plus la méthode) est le signal que le changement est définitif.

Mon API n'a pas besoin de HTTPS, seule mon appli l'utilise.

Si : des jetons et des données de tes utilisateurs transitent par cette API. Et si l'appli l'appelle en HTTP depuis une page HTTPS, le navigateur la bloque comme contenu mixte.