Website Security Checklist 2026

Das Zertifikat ist gültig, nicht abgelaufen und passt zu Ihrer Domain. Prüfen Sie es mit dem SSL-Labs-Servertest.

TLS 1.0 und 1.1 sind seit 2021 offiziell veraltet (RFC 8996). Schalten Sie sie ab und bevorzugen Sie TLS 1.3.

Leiten Sie jeden HTTP-Aufruf per 301 automatisch auf HTTPS um.

Installieren Sie die Zwischenzertifikate und binden Sie sie korrekt ein.

Nutzen Sie ein aktuelles Server-Profil und schalten Sie schwache Verfahren wie RC4, DES und 3DES ab.

Schützt aufgezeichnete Sitzungen auch dann, wenn der private Schlüssel später bekannt wird. TLS 1.3 bringt PFS immer mit.

Die Laufzeiten sinken weiter. Nach den Baseline Requirements des CA/Browser Forums dürfen öffentliche Zertifikate seit dem 15. März 2026 höchstens 200 Tage gelten, ab dem 15. März 2027 höchstens 100 Tage und ab dem 15. März 2029 höchstens 47 Tage. Erneuern Sie per ACME und lassen Sie sich bei einer fehlgeschlagenen Erneuerung warnen.

Keine HTTP-Ressourcen auf HTTPS-Seiten.

Ein CAA-Eintrag (RFC 8659) legt fest, welche Zertifizierungsstellen für Ihre Domain Zertifikate ausstellen dürfen.

Erzwingt HTTPS. Senden Sie max-age=31536000 (ein Jahr) oder mehr, dazu includeSubDomains, sobald jede Subdomain über HTTPS läuft.

Die Preload-Liste verlangt max-age von mindestens einem Jahr, includeSubDomains und preload. Ein Austrag dauert Monate. Melden Sie die Domain nur an, wenn alle Subdomains dauerhaft HTTPS halten (hstspreload.org).

Setzen Sie eine strikte Richtlinie: pro Antwort ein neuer Zufalls-Nonce (bei statischen Seiten Hashes), 'strict-dynamic', object-src 'none' und base-uri 'none'. Testen Sie zuerst im Report-Only-Modus (web.dev/articles/strict-csp).

Setzen Sie die CSP-Direktive frame-ancestors auf 'none' oder 'self'. X-Frame-Options DENY oder SAMEORIGIN bleibt als Rückfall für ältere Browser.

Verhindert MIME-Type-Sniffing.

Aktuelle Browser ignorieren den alten XSS-Filter, in älteren konnte er neue Lücken öffnen. Diese Aufgabe übernimmt Ihre Content-Security-Policy.

Steuert, welche Referrer-Daten Anfragen mitschicken. strict-origin-when-cross-origin ist ein sinnvoller Standard.

Ersetzt den alten Feature-Policy-Header. Schalten Sie Kamera, Mikrofon, Standort und weitere Browser-Funktionen ab, die Ihre Seite nicht nutzt.

Verhindern Sie das Zwischenspeichern sensibler Seiten (no-store für private Inhalte).

Verraten Sie keine Versionen Ihrer Server-Software (Apache, nginx und so weiter).

Holen Sie die Einwilligung ein, bevor Sie nicht notwendige Daten auf dem Gerät speichern oder auslesen (§ 25 TDDDG). Keine vorausgewählten Kästchen.

Alle Datenverarbeitungen aufführen und die Rechtsgrundlagen nennen.

Name, Anschrift, Kontaktdaten und, falls vorhanden, USt-IdNr.

Erforderlich bei Hoster, Analyse-Tools und E-Mail-Diensten.

Betroffene können die über sie gespeicherten Daten anfordern.

Es gibt einen Ablauf, mit dem Betroffene die Löschung ihrer Daten verlangen können.

Betroffene können ihre Daten in einem maschinenlesbaren Format erhalten.

Informieren Sie darüber, wie die Formulardaten verarbeitet werden.

Führen Sie alle externen Dienste auf: Analyse, Schriften, CDNs und so weiter. Binden Sie Schriften nach Möglichkeit lokal ein.

Legen Sie fest, wie lange welche Daten gespeichert werden, und löschen Sie sie fristgerecht.

Cloudflare, Sucuri oder eine serverseitige WAF filtert schädlichen Datenverkehr.

Automatische Suche nach verdächtigen Dateien mindestens wöchentlich.

Halten Sie WordPress, Joomla, Drupal und deren Plugins auf dem neuesten Stand.

Auch inaktiver Code kann Sicherheitslücken enthalten.

Sie erhalten eine Warnung, wenn sich Kerndateien ohne geplantes Update ändern.

Nutzen Sie parametrisierte Abfragen und prüfen Sie Eingaben auf dem Server. Injection ist Platz A05 der OWASP Top 10:2025.

Kodieren Sie jede Ausgabe passend zum Kontext und bereinigen Sie Nutzereingaben. Eine strikte CSP ergänzt das als zweite Schicht.

Kombinieren Sie SameSite-Cookies mit eindeutigen Tokens bei Formularen und Aktionen, die Daten ändern.

Pflegen Sie Lockfiles, führen Sie npm audit oder ein Äquivalent im Build aus und laden Sie Fremd-Skripte möglichst mit Subresource Integrity. OWASP führt Software Supply Chain Failures als A03:2025.

CDN oder Hoster mit DDoS-Abwehr, dazu Ratenbegrenzung für Login und Formulare.

Sichern Sie Datenbank und Dateien automatisch.

3 Kopien auf 2 verschiedenen Medien, 1 Kopie an einem anderen Ort.

Auf einem anderen Server oder Cloud-Konto. Halten Sie mindestens eine Kopie vor, die auch jemand mit Zugriff auf Ihre Seite nicht überschreiben oder löschen kann (unveränderbar oder offline).

Schützen Sie Backup-Dateien mit starker Verschlüsselung (AES-256).

Spielen Sie jedes Quartal ein Test-Backup ein, um zu prüfen, dass es funktioniert.

Legen Sie fest, wie lange Sie tägliche, wöchentliche und monatliche Backups behalten.

Schritt-für-Schritt-Anleitung für die vollständige Wiederherstellung der Seite.

Die längste Ausfallzeit, die Sie nach einem Ausfall hinnehmen können.

Mindestens 15 Zeichen, wenn das Passwort der einzige Faktor ist, mindestens 8 bei Multi-Faktor. Erlauben Sie lange Passphrasen, gleichen Sie gegen Listen bekannter Passwörter ab, verlangen Sie keine Zeichenmischung und keinen Wechsel nach Zeitplan. Nach einer Kompromittierung erzwingen Sie den Wechsel.

Bevorzugen Sie Passkeys oder Hardware-Sicherheitsschlüssel. Eine Authenticator-App (TOTP) ist das Minimum. SMS-Codes schützen am schwächsten.

Passkeys (FIDO2/WebAuthn) sind phishing-resistent. NIST SP 800-63B-4 erlaubt synchronisierbare Authentifikatoren bis Vertrauensstufe AAL2, nicht aber bei AAL3.

Begrenzen Sie die Rate von Anmeldeversuchen, sperren Sie Konten nach mehreren Fehlversuchen oder zeigen Sie ein CAPTCHA.

Schützen Sie /admin, /wp-admin und ähnliche Pfade per IP-Freigabe, VPN oder Zugriffs-Gateway. Eine umbenannte URL allein schützt nicht.

Jeder Nutzer erhält nur die Rechte, die er braucht. Broken Access Control ist Platz A01 der OWASP Top 10:2025.

Session-Cookies mit Secure, HttpOnly und SameSite, ein Timeout und eine neue Sitzungs-ID nach der Anmeldung.

OWASP empfiehlt zuerst Argon2id. bcrypt nutzen Sie nur in Altsystemen. Speichern Sie nie Klartext oder schnelle Hashes wie MD5 oder SHA-1.

Entfernen Sie inaktive Konten und prüfen Sie die Rechte jedes Quartal.

Zeitlich begrenzte Einmal-Tokens, keine Sicherheitsfragen, Bestätigung per E-Mail.

Spielen Sie Sicherheitsupdates regelmäßig ein.

Apache, nginx oder IIS in einer unterstützten Version.

Laufzeitumgebungen ohne Sicherheitsupdates sind ein Risiko. Prüfen Sie das Support-Ende Ihrer Version.

Nur nötige Ports offen (80, 443, SSH).

Schalten Sie das Passwort-Login ab, nutzen Sie SSH-Schlüssel und ergänzen Sie fail2ban oder Ähnliches.

Verzeichnisse 755, Dateien 644, Konfigurationsdateien 600.

Verhindern Sie, dass Besucher Verzeichnisinhalte durchsuchen können.

MySQL oder PostgreSQL nur von localhost oder aus einem privaten Netz erreichbar.

Sperren Sie den Zugriff auf Konfigurationsdateien über das Web.

Sie erhalten eine Warnung, wenn die Seite ausfällt (UptimeRobot, Pingdom).

Protokollieren Sie Anmeldungen, Fehlversuche, Dateiänderungen und Admin-Aktionen und lassen Sie sich bei auffälligen Mustern warnen. Protokolle ohne Alarm sind Platz A09 der OWASP Top 10:2025.

Protokollieren Sie Fehler intern, zeigen Sie Nutzern allgemeine Meldungen und lassen Sie im Zweifel den Zugriff scheitern. OWASP führt das als A10:2025, Mishandling of Exceptional Conditions.

Suchen Sie nach auffälligen Mustern und Angriffen.

Aktivieren Sie Dependabot oder einen ähnlichen Dienst, damit Sie von bekannten Schwachstellen in Ihren Paketen erfahren.

Lassen Sie sich warnen, wenn Google die Seite als gefährlich einstuft, zum Beispiel über den Bericht zu Sicherheitsproblemen in der Search Console.

Bewahren Sie Protokolle lange genug für eine Analyse auf, aber nicht länger, als Ihre Datenschutzerklärung angibt.

Die Schritte bei einem Sicherheitsvorfall. Eine Datenpanne mit voraussichtlichem Risiko melden Sie innerhalb von 72 Stunden an die Aufsichtsbehörde (Art. 33 DSGVO).