HTTPS/SSL en websitebeveiliging

Wat is HTTPS/SSL?

HTTPS (HTTP Secure) is een protocol dat de gegevensuitwisseling tussen een website en de browser van de bezoeker versleutelt. Deze versleuteling wordt verzorgd door een SSL/TLS-certificaat van de website; het certificaat fungeert als een digitaal document dat de identiteit van de website aan de browser bevestigt. Het slotje in de adresbalk van de browser geeft aan dat de verbinding versleuteld is en dat het certificaat geldig is.

Gegevens die via HTTP worden verzonden, worden in leesbare tekst (plaintext) doorgegeven; dit betekent dat een derde partij op hetzelfde netwerk (bijv. openbare wifi) de gegevens kan lezen. HTTPS versleutelt deze gegevens, waardoor ze alleen leesbaar zijn voor de verzender en de ontvanger.

SSL-certificaten zijn doorgaans voor een bepaalde periode (bijvoorbeeld een jaar) geldig en moeten worden vernieuwd wanneer ze verlopen; tegenwoordig automatiseren veel hostingproviders dit proces, waardoor het certificaat automatisch wordt vernieuwd, wat de noodzaak van handmatige opvolging vermindert.

Waarom is dit belangrijk?

HTTPS zorgt ervoor dat gebruikersgegevens (formulierinvoer, inloggegevens, betalingsgegevens) worden beschermd tegen man-in-the-middle-aanvallen. Google beschouwt het gebruik van HTTPS als een lichtwegend signaal voor de rangschikking en browsers geven bij HTTP-sites de waarschuwing 'Niet veilig' weer; dit heeft een directe invloed op het vertrouwen van de gebruiker.

Een onveilige website vermindert de bereidheid van bezoekers om op de site te blijven; met name gebruikers die een formulier invullen of een betaling uitvoeren, kunnen de site verlaten zonder de transactie af te ronden wanneer ze de waarschuwing „Niet veilig“ zien. Dit is een vertrouwenskwestie die rechtstreeks van invloed is op de conversieratio.

Bovendien werken de meeste moderne browserfuncties (bijv. locatiediensten, meldingen, bepaalde betalings-API’s) uitsluitend via HTTPS; een website die op HTTP blijft draaien, kan geen gebruik maken van deze functies en wordt technisch gezien steeds beperkter.

Hoe lost u dit op?

• Installeer een geldig SSL-certificaat op uw website en zorg voor automatische verlenging om te voorkomen dat het certificaat verloopt.
• Leid alle HTTP-verzoeken met een 301-omleiding door naar de HTTPS-versie.
• Verhelp waarschuwingen voor gemengde inhoud (mixed content): zorg ervoor dat alle afbeeldingen, scripts en CSS-bestanden op de pagina via HTTPS worden geladen; anders kan de browser de pagina als „gedeeltelijk veilig“ markeren.
• Voeg indien mogelijk een HSTS-header (HTTP Strict Transport Security) toe, zodat de browser altijd via HTTPS verbinding moet maken met de website.
• Beperk omleidingsketens (meerdere opeenvolgende omleidingen, zoals HTTP → HTTPS → www → non-www) tot één stap; elke extra omleiding zorgt voor een kleine vertraging bij het laden van de pagina.
• Controleer of bronnen die door diensten van derden worden geleverd (zoals een beeld-CDN, formulierprovider of chatwidget) ook via HTTPS worden aangeboden; dit zijn vaak de over het hoofd geziene bronnen van het probleem met gemengde inhoud.

Voorbeeld

# .htaccess voorbeeld
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Slecht voorbeeld: vergeten om na de overstap naar HTTPS de oude <img src="http://example.com/logo.png"> absolute HTTP-links op de pagina vergeten bij te werken; dit leidt tot een waarschuwing voor gemengde inhoud in de browser, zelfs als de pagina over het algemeen veilig lijkt.

Veelgemaakte fouten

• De HTTP-versie open laten staan in plaats van deze uit te schakelen; hierdoor blijft de site zowel via HTTP als via HTTPS toegankelijk en wordt de inhoud op twee verschillende adressen gedupliceerd.
• Afbeeldingen of scripts op de pagina laten staan die via HTTP worden geladen terwijl de pagina onder HTTPS staat (gemengde inhoud).
• Het SSL-certificaat laten verlopen; in dat geval kan de browser de site als volledig ontoegankelijk weergeven.
• Onnodige omleidingsketens creëren die uit meerdere stappen bestaan.
• Het certificaat alleen voor de hoofddomeinnaam aanschaffen en subdomeinnamen (bijv. blog.example.com) buiten de dekking laten vallen.
• In interne links (menu, footer, interne links) nog steeds de oude HTTP-adressen gebruiken; dit veroorzaakt bij elke klik een onnodige 301-omleiding en vertraagt het laden van de pagina enigszins.
• In de sitemap en canonical-tags nog steeds naar de oude HTTP-adressen verwijzen; dit stuurt verwarrende signalen naar de zoekmachine.
• Het per ongeluk overzetten van het zelfondertekende certificaat dat in de lokale ontwikkelomgeving (localhost) wordt gebruikt naar de live-omgeving; browsers beschouwen dit soort certificaten niet als betrouwbaar.
• Het rapport van Seoraporu.co markeert het ontbreken van HTTPS of waarschuwingen voor gemengde inhoud als prioriteit in het gedeelte met technische bevindingen, omdat dit zowel het vertrouwen als de prestaties beïnvloedt.