Controle van HTTPS-redirect

Hoe deze controle werkt

Scanaris vraagt je pagina op via http://, zonder de s, zonder omleidingen te volgen, en kijkt wat de server antwoordt. Geeft hij een omleidingscode (301, 302, 307 of 308) naar een https://-URL terug, dan is alles in orde. Antwoordt hij 200 en serveert hij de pagina onversleuteld, dan opent hij een bevinding met gemiddelde ernst: de onversleutelde versie van je site bestaat en werkt. Leidt hij om maar is de bestemming nog http:// (bijvoorbeeld van de root naar http://www), dan opent hij een bevinding met lage ernst: de omleidingsketen heeft een onversleutelde schakel. Alleen de gescande URL wordt getest; het gedrag hoort op alle routes hetzelfde te zijn, niet alleen op de homepage.

Waarom dit belangrijk is

Zolang een HTTP-versie antwoordt, kan elke oude link, elk met de hand getypt adres en elk openbaar netwerk de gebruiker zonder versleuteling op je site brengen. In die toestand leest wie het netwerk beheert (de wifi op het vliegveld, een kwaadwillende provider) wat er wordt verstuurd en kan hij de pagina aanpassen voordat ze aankomt. Dat is de basis van man-in-the-middle-aanvallen. Een 301 naar HTTPS sluit die deur bij het eerste verzoek, en HSTS sluit hem voor alle volgende.

Hoe je het oplost, afhankelijk van je hosting

• Vercel, Netlify, Cloudflare Pages, Railway, Render: de omleiding staat standaard aan. Zie je de bevinding, dan wijst het domein meestal naar een andere server of antwoordt een proxy ervoor via HTTP.
• Cloudflare als proxy: zet "Always Use HTTPS" aan en stel de SSL-modus in op "Full (strict)". Met "Flexible" loopt het stuk tussen Cloudflare en je server onversleuteld.
• nginx:

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

• Apache: in de VirtualHost van poort 80, Redirect permanent / https://jouwdomein.nl/.
• Express achter een proxy: een middleware die req.headers['x-forwarded-proto'] !== 'https' controleert en antwoordt met res.redirect(301, 'https://' + req.headers.host + req.url), met app.set('trust proxy', 1).

Gebruik een 301 of 308 (permanent) en geen 302: zoekmachines bundelen de autoriteit op de HTTPS-versie en browsers cachen de sprong. Voeg daarna de HSTS-header toe, die de controle zwakke HSTS meet, zodat de browser de volgende keer HTTP niet eens meer probeert.

Controleer of het opgelost is

curl -sI http://jouwdomein.nl | grep -iE "^HTTP|^location"
curl -sI http://jouwdomein.nl/een-willekeurige-pagina | grep -iE "^HTTP|^location"
curl -sI http://www.jouwdomein.nl | grep -iE "^HTTP|^location"

Alle drie moeten 301 of 308 antwoorden met een Location die begint met https://. Leidt de tweede niet om, dan dekt je regel alleen de homepage.

Veelgestelde vragen

Is HTTPS aan hebben niet genoeg?

Nee. Een certificaat hebben betekent dat de veilige versie bestaat; de omleiding betekent dat de onveilige niet wordt gebruikt. Zonder omleiding bestaan ze naast elkaar.

Waarom 301 en geen 302?

De 302 is tijdelijk: browsers vragen elke keer opnieuw de HTTP-versie op en zoekmachines dragen de autoriteit niet over. De 301 (of de 308, die ook de methode behoudt) is het signaal dat de wijziging definitief is.

Mijn API heeft geen HTTPS nodig, alleen mijn app gebruikt hem.

Toch wel: via die API gaan tokens en gegevens van je gebruikers. En als de app hem via HTTP aanroept vanaf een HTTPS-pagina, blokkeert de browser hem als mixed content.