Website-Sicherheit: HTTPS und Sicherheits-Header richtig einstellen

Warum braucht jede Website HTTPS mit gültigem Zertifikat?

HTTPS verschlüsselt die Verbindung zwischen Browser und Server, damit niemand unterwegs Daten mitlesen oder verändern kann. Ohne gültiges Zertifikat warnen Browser vor Ihrer Seite – und Google Chrome fragt laut Ankündigung von Google ab Version 154 (Oktober 2026) standardmäßig nach, bevor es eine öffentliche Seite ohne HTTPS zum ersten Mal öffnet.

Auch Google wertet HTTPS: Schon 2014 hat Google es als – damals sehr leichtes – Rankingsignal eingeführt, und in der Selbstprüfung zur Nutzererfahrung fragt Google, ob Seiten sicher ausgeliefert werden. Leiten Sie alle Aufrufe über http:// per 301 auf https:// um; wie das geht, zeigt der Artikel über Weiterleitungen.

Ein Zertifikat ist nur gültig, wenn es nicht abgelaufen ist, zum aufgerufenen Hostnamen passt – also auch zur Variante mit oder ohne www, falls beide erreichbar sind –, von einer vertrauenswürdigen Zertifizierungsstelle stammt und mit vollständiger Zertifikatskette einschließlich Zwischenzertifikat ausgeliefert wird.

Kürzere Laufzeiten ab 2026

Die Laufzeit öffentlicher TLS-Zertifikate sinkt in drei Schritten. Grundlage sind die Baseline Requirements des CA/Browser Forum, nach denen sich die Zertifizierungsstellen richten.

Let’s Encrypt geht schneller vor: Ab 10. Februar 2027 stellt der kostenlose Anbieter standardmäßig Zertifikate mit 64 Tagen Laufzeit aus, 2028 sollen es 45 Tage sein. Manuelles Erneuern ist damit praktisch keine Option mehr. Richten Sie die automatische Verlängerung über das ACME-Protokoll ein, und lassen Sie Ihr Hosting oder Ihre Agentur bestätigen, dass sie läuft. Let’s Encrypt rät, keine festen Erneuerungsintervalle einzuprogrammieren: Clients mit ACME Renewal Information (ARI) erfahren vom Anbieter, wann sie erneuern sollen.

Welche Sicherheits-Header sollte Ihr Server senden?

Mindestens fünf: HSTS, X-Content-Type-Options, einen Schutz vor Clickjacking, eine Referrer-Policy und eine Content-Security-Policy; dazu die Permissions-Policy. Diese HTTP-Header setzen Sie in der Server-Konfiguration, nicht im Seiteninhalt.

So sieht das in der Konfiguration von nginx aus. Der Zusatz always sorgt dafür, dass die Header auch bei Fehlerseiten gesendet werden:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'" always;

Für Apache mit dem Modul mod_headers, etwa in der .htaccess:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'"
</IfModule>

Bei gemietetem Webspace oder Website-Baukästen hängt es vom Anbieter ab, ob Sie Header selbst setzen können. Fragen Sie im Zweifel Ihren Hoster. Was Ihr Server tatsächlich sendet, zeigt der HTTP-Header-Check.

HSTS mit Bedacht einführen

HSTS wirkt nur, wenn der Header über HTTPS kommt; über HTTP ignorieren Browser ihn. Setzen Sie includeSubDomains erst, wenn wirklich jede Subdomain HTTPS beherrscht, denn sonst sind diese Subdomains für ein Jahr blockiert. Die Aufnahme in die Preload-Liste der Browser (preload) verlangt mindestens ein Jahr max-age und lässt sich laut hstspreload.org nur schwer und mit monatelanger Verzögerung rückgängig machen.

Content-Security-Policy schrittweise schärfen

Eine CSP ist die wirksamste, aber auch anspruchsvollste dieser Angaben. Beginnen Sie mit dem Header Content-Security-Policy-Report-Only: Der Browser meldet Verstöße, blockiert aber noch nichts. Erst wenn keine berechtigten Inhalte mehr gemeldet werden, stellen Sie auf Content-Security-Policy um. Vermeiden Sie 'unsafe-inline', denn damit verliert die Policy einen Großteil ihrer Schutzwirkung; für nötige Inline-Skripte gibt es Nonces und Hashes.

Was ist Mixed Content und wie beheben Sie ihn?

Mixed Content heißt: Eine Seite wird über HTTPS geladen, bindet aber einzelne Dateien über unverschlüsseltes http:// ein. Browser stellen Bilder, Audio und Video dann automatisch auf HTTPS um, blockieren aber Skripte, Stylesheets, iframes, Schriften und Datenabfragen – Teile der Seite funktionieren dann nicht.

<link rel="stylesheet" href="http://www.example.com/css/style.css">
<script src="http://www.example.com/js/slider.js"></script>

<link rel="stylesheet" href="/css/style.css">
<script src="https://www.example.com/js/slider.js"></script>

• Liefern Sie alle eigenen Dateien über HTTPS aus und verweisen Sie mit relativen Pfaden oder https:// darauf.
• Ersetzen Sie in einem CMS alte http://-Adressen auch in der Datenbank, etwa in Beiträgen und Theme-Einstellungen. Legen Sie vorher eine Sicherung an.
• Nutzen Sie bei fremden Diensten deren HTTPS-Adressen.
• Formulare mit action="http://…" übertragen Eingaben unverschlüsselt – stellen Sie auch sie um.

Als Übergangslösung schreibt die CSP-Anweisung upgrade-insecure-requests Anfragen der Seite automatisch auf HTTPS um. Sie ersetzt aber weder die Korrektur der Adressen noch HSTS.

Warum sollten Sie Versionsnummern verbergen?

Header wie Server: Apache/2.4.2 (Unix) PHP/4.2.2 oder X-Powered-By: PHP/8.1.2 verraten, welche Software in welcher Version läuft. Das erleichtert die gezielte Suche nach bekannten Lücken. Verbergen ersetzt keine Updates, nimmt Angreifern aber eine einfache Abkürzung.

Das OWASP-Projekt empfiehlt außerdem, X-Powered-By ganz zu entfernen und den Header Server wegzulassen oder neutral zu halten.

Wie gefährlich sind veraltete JavaScript-Bibliotheken?

Alte Versionen verbreiteter Bibliotheken enthalten öffentlich dokumentierte Sicherheitslücken, die jeder nachlesen kann. Themes und Plugins bringen oft eigene Bibliotheken mit, die erst mit einem Update des Themes oder Plugins erneuert werden.

Welche Version geladen wird, sehen Sie oft schon am Dateinamen oder am Parameter, etwa jquery.min.js?ver=1.12.4. Aktualisieren Sie CMS, Theme und Plugins regelmäßig. Bricht nach einem jQuery-Update alter Code, hilft das offizielle Plugin jQuery Migrate beim Übergang; setzen Sie es nur so lange ein, bis der Code angepasst ist.

Was ist eine security.txt?

Die security.txt ist eine kleine Textdatei unter /.well-known/security.txt, die Sicherheitsforschern zeigt, wie sie Ihnen eine Lücke melden können. Das Format beschreibt RFC 9116 aus dem Jahr 2022.

Pflicht sind zwei Felder: Contact mit einem Kontaktweg und Expires mit einem Ablaufdatum, das laut RFC weniger als ein Jahr in der Zukunft liegen sollte. Die Datei muss über HTTPS und als text/plain in UTF-8 ausgeliefert werden. Optional sind unter anderem Preferred-Languages, Canonical, Policy und Encryption.

Contact: mailto:sicherheit@example.com
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://www.example.com/.well-known/security.txt

Tragen Sie sich eine Erinnerung ein, bevor Expires erreicht ist: Eine abgelaufene Datei signalisiert, dass die Angaben veraltet sein könnten. Wie es um die Datenschutz-Technik Ihrer Website steht, erklärt der Artikel über DSGVO und Impressum.