Website-Launch-Checkliste: acht Sicherheitschecks vor dem Go-live

1. Die Checkliste vor dem Go-live im Überblick

Prüfen Sie jeden öffentlichen Hostnamen, unter dem die Website erreichbar ist, in der Regel die Domain ohne www und www, jeweils über http:// und https://. Noch vor der DNS-Umstellung können Sie den neuen Server unter dem echten Namen testen: curl -sI --resolve example.com:443:203.0.113.10 https://example.com/, mit der IP-Adresse des neuen Servers statt der Beispieladresse.

Die acht Zeilen folgen den acht passiven Prüfungen des kostenlosen Snapshots, der einen öffentlichen Origin ohne Konto betrachtet. Die Schritte von Hand gehen weiter, als ein einzelner Durchlauf an einem Origin es kann: Sie decken jeden Hostnamen, beide Schemata, Fehlerseiten, DKIM und die Einstellungen beim Registrar ab.

2. DNS-Auflösung: Jeder Name zeigt auf den neuen Host

Warum das wichtig ist. Ein halb erledigter Umzug fällt oft nicht auf: Die Domain ohne www läuft schon auf dem neuen Server, www ist noch ein CNAME auf die alte Plattform. Übrig gebliebene Einträge sind außerdem ein Sicherheitsproblem. Das OWASP Cheat Sheet zur Subdomain-Übernahme erklärt, wie ein CNAME, der auf eine gelöschte Cloud-Ressource zeigt, Dritten erlaubt, die Subdomain zu übernehmen, und wie ein verwaister MX-Eintrag einem Angreifer Mail für diese Subdomain zuspielen und ihm sogar Zertifikate über E-Mail-basierte Validierung verschaffen kann.

So prüfen Sie.

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short NS example.com

Wiederholen Sie die Abfragen über einen öffentlichen Resolver (dig @1.1.1.1 …), falls Ihr Netz noch eine Antwort im Cache hält, und gehen Sie danach den vollständigen Zonenexport Ihres DNS-Anbieters durch.

So sieht ein gutes Ergebnis aus. Jeder öffentliche Name löst auf den erwarteten Host auf, AAAA-Einträge gibt es nur, wenn der Host die Website wirklich über IPv6 ausliefert, mindestens zwei Nameserver antworten (das Minimum aus RFC 1034), und jeder Eintrag hat einen bekannten Zweck und eine verantwortliche Person.

Was hilft. Veraltete Einträge korrigieren oder löschen. Wenn Sie einen Dienst stilllegen, halten Sie die Reihenfolge ein, die OWASP empfiehlt: DNS-Eintrag ändern oder entfernen, mindestens eine TTL abwarten und erst dann die Cloud-Ressource löschen. Senken Sie vor einer Umstellung die TTL so früh, dass die alte, längere TTL zum Umstellungszeitpunkt abgelaufen ist, und erhöhen Sie sie wieder, sobald der Umzug stabil läuft.

3. SPF, DMARC und CAA: die Einträge, die für Ihre Domain sprechen

Warum das wichtig ist. Jeder kann Ihre Domain in eine From-Zeile schreiben. SPF listet die Server, die für die Domain Mail senden dürfen, DKIM signiert Nachrichten, und DMARC sagt Empfängern, was zu tun ist, wenn weder SPF noch DKIM passend zur sichtbaren From-Domain besteht. Gmail, Yahoo und Outlook.com verlangen alle drei von Massenversendern. CAA nennt die Zertifikatsaussteller (CAs), die Zertifikate für Ihre Namen ausstellen dürfen, und öffentliche CAs müssen den Eintrag vor jeder Ausstellung prüfen.

So prüfen Sie. Fragen Sie die Domain ab, die in Ihren From-Adressen steht, meist die registrierte Domain und nicht www:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

So sieht ein gutes Ergebnis aus.

• SPF: genau ein v=spf1-Eintrag, innerhalb der Grenze von 10 Termen mit DNS-Abfrage aus RFC 7208 (verschachtelte includes zählen mit), mit ~all oder -all am Ende, nie +all.
• DMARC: ein Eintrag wie v=DMARC1; p=none; rua=mailto:dmarc@example.com, damit Berichte eintreffen, bevor Sie die Richtlinie verschärfen. Der aktuelle Standard, RFC 9989 (Mai 2026), sagt, dass Domains, deren Nutzer an Mailinglisten schreiben könnten, kein p=reject veröffentlichen sollten; wer es dennoch will, soll zuerst mindestens einen Monat mit p=none und ebenso lange mit quarantine arbeiten und die Berichte vergleichen. Die TR-03182 des BSI erwartet dagegen quarantine oder reject und empfiehlt sendenden Domains reject.
• DKIM: Jeder Dienst, der für Sie sendet, signiert mit Ihrer Domain. Die öffentlichen Schlüssel liegen unter selector._domainkey.example.com; zum Abfragen brauchen Sie also den jeweiligen Selektor. Er steht im Tag s= des Headers DKIM-Signature einer Nachricht, die der Dienst verschickt hat.
• CAA: ein Eintrag wie 0 issue "letsencrypt.org" für jede CA, die Sie nutzen, auch die Ihres CDN. Ganz auf CAA zu verzichten, ist ebenfalls zulässig; eine Fehlausstellung durch eine berechtigte CA verhindert CAA ohnehin nicht.

Was hilft. Doppelte SPF-Einträge zusammenführen, includes für stillgelegte Dienste streichen und DMARC mit p=none und Berichten beginnen. Ein harter Fail ist nicht automatisch sicherer: RFC 9989 warnt, dass Mail bei -all schon am SPF-Ergebnis abgelehnt werden kann, bevor DMARC greift, selbst wenn eine passende DKIM-Signatur bestanden hätte, und dass solche Ablehnungen in keinem DMARC-Bericht auftauchen. Findet ein Empfänger auf einer Subdomain keinen DMARC-Eintrag, geht er im DNS-Baum zur Richtlinie der übergeordneten Domain hinauf, und eine CA verwendet den nächstgelegenen CAA-Eintrag am Namen oder darüber, wie die CAA-Seite von Let’s Encrypt erklärt. Ein fehlender _dmarc- oder CAA-Eintrag auf www ist also für sich genommen keine Lücke. Der SPF- und DMARC-Check erklärt, wie Sie diese Einträge lesen und korrigieren.

4. TLS-Zertifikat: gültig, passend und mit klarer Zuständigkeit erneuert

Warum das wichtig ist. Ein abgelaufenes oder nicht passendes Zertifikat stoppt Besucher an einer Browserwarnung, und auf einem Host mit HSTS können sie diese nicht wegklicken. Erneuerungen werden außerdem häufiger: Nach Ballot SC081v3 des CA/Browser Forums sind öffentlich vertrauenswürdige Zertifikate, die seit dem 15. März 2026 ausgestellt werden, höchstens 200 Tage gültig; ab März 2027 sind es 100 Tage, ab März 2029 nur noch 47. Let’s Encrypt hat am 4. Juni 2025 den Versand von Ablauf-E-Mails eingestellt.

So prüfen Sie. Für jeden Hostnamen:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

Führen Sie s_client auch allein aus: Die Ausgabe sollte Verify return code: 0 (ok) enthalten und das ausgehandelte Protokoll zeigen.

So sieht ein gutes Ergebnis aus. Die Kette lässt sich mit den Zwischenzertifikaten verifizieren, die der Server mitschickt, das Zertifikat deckt jeden ausgelieferten Namen ab, die Verbindung nutzt TLS 1.3 oder 1.2, die Erneuerung läuft automatisch, und im Betriebshandbuch steht, wer dafür zuständig ist. Es gibt eine Ablaufwarnung, die nicht von der CA abhängt.

Was hilft. Erneuerung per ACME automatisieren. Let’s Encrypt empfiehlt ACME Renewal Information (ARI) oder eine Erneuerung nach etwa zwei Dritteln der Laufzeit und warnt, dass ein festes Erneuerungsintervall von 60 Tagen nicht mehr reicht, sobald Zertifikate nur noch 45 Tage gelten. Prüfen Sie nach einem Umzug, ob die neue Plattform tatsächlich erneuert. Ein einzelner Handshake zeigt nur das ausgehandelte Protokoll; ob TLS 1.0 und 1.1 abgeschaltet sind, bestätigt ein Scanner, der alle unterstützten Versionen auflistet.

Wie Zertifikat, HSTS und die übrigen Schutzmechanismen des Browsers bei einem HTTPS-Besuch zusammenspielen, erklärt der Leitfaden So funktioniert HTTPS.

5. HTTPS-Weiterleitung: ein Schritt zu HTTPS, ein kanonischer Host, dann HSTS

Warum das wichtig ist. Alte Links, Lesezeichen, Skripte und ältere Clients rufen weiterhin http://-Adressen auf. Eine Weiterleitung bringt sie zu HTTPS, aber, wie hstspreload.org anmerkt, kann ein Angreifer auf dem Übertragungsweg diese Weiterleitung abfangen und umschreiben. HSTS schließt die Lücke für jeden Besuch nach dem ersten sicheren.

So prüfen Sie.

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sIL "http://example.com/page?x=1" | grep -iE '^(HTTP|location)'

So sieht ein gutes Ergebnis aus.

• Eine dauerhafte Weiterleitung (301 oder, wenn die Anfragemethode erhalten bleiben soll, 308) auf denselben Pfad per HTTPS beim selben Host, wie es der TLS-Leitfaden von MDN rät, danach höchstens ein weiterer Schritt zum kanonischen Host. Pfad und Query-String bleiben erhalten.
• Die HTTPS-Antwort sendet Strict-Transport-Security. Über unverschlüsseltes HTTP ignorieren Browser den Header, die Weiterleitung selbst braucht ihn also nicht.
• Kein Mixed Content: Browser blockieren Skripte, die auf HTTPS-Seiten über http:// geladen werden.

Was hilft. Im Server oder CDN weiterleiten, nicht per JavaScript. Das HSTS-max-age stufenweise bis zu einem langen Wert wie 31536000 (ein Jahr) erhöhen und includeSubDomains erst ergänzen, wenn jede Subdomain HTTPS ausliefert. hstspreload.org empfiehlt inzwischen HSTS, aber kein Preloading. Werden Zertifikate über die ACME-Challenge HTTP-01 ausgestellt, muss Port 80 erreichbar bleiben. Um diesen Punkt mit dem kostenlosen Snapshot zu testen, geben Sie die http://-Adresse ein; bei einer Domain ohne Schema oder einer https://-Adresse prüft er stattdessen HSTS-max-age und Mixed Content.

6. Security-Header: die letzte Antwort und die Fehlerseiten prüfen

Warum das wichtig ist. Security-Header sagen dem Browser, was eine Seite laden darf, wer sie einbetten darf und wie er mit Inhaltstypen umgeht. Sie stehen oft in der Konfiguration von Server oder CDN, und ein Hosting-Umzug kann sie verlieren, etwa wenn eine .htaccess nicht mit umzieht. Sie begrenzen den Schaden von Fehlern wie Cross-Site-Scripting; beheben können sie die Fehler nicht.

So prüfen Sie.

curl -sIL https://example.com/
curl -sI https://example.com/no-such-page

Prüfen Sie auch die Fehlerseite: Ohne den Parameter always sendet nginx add_header-Werte nur bei bestimmten Statuscodes, wie das OWASP HTTP Headers Cheat Sheet anmerkt; bei Apache gilt Entsprechendes für Header set ohne always.

So sieht ein gutes Ergebnis aus. Ein vernünftiger Startsatz für eine einfache Website:

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

• Führen Sie die CSP zuerst als Content-Security-Policy-Report-Only ein. Sie muss alles erlauben, was Ihre Seiten legitim laden, und 'unsafe-inline' hebelt einen großen Teil ihres Nutzens aus.
• frame-ancestors erbt nicht von default-src und wird in einem <meta>-Tag ignoriert; X-Frame-Options: DENY ist die ältere Rückfallebene.
• Session-Cookies tragen Secure, HttpOnly und ein ausdrückliches SameSite (siehe MDN zu Set-Cookie). HttpOnly verhindert, dass Skripte auf der Seite das Cookie lesen (etwa über document.cookie), der Browser sendet es aber weiterhin mit passenden Anfragen; es erschwert also Cookie-Diebstahl per XSS, verhindert XSS selbst aber nicht.
• Kein X-XSS-Protection-Header, oder er steht auf 0.

Was hilft. Header auf einer Ebene setzen (Server, Anwendung oder CDN), sodass jede Antwort, Fehlerseiten eingeschlossen, jeden Header genau einmal erhält. Der Security Headers Check erklärt jeden Header im Detail, mit Beispielen für nginx, Apache und statische Hosts.

7. Technologie-Angaben, Caching und Kompression

Technologie-Angaben

Warum das wichtig ist. Server, X-Powered-By und Generator-Tags verraten jedem, welche Software Sie einsetzen, und MDN weist darauf hin, dass genaue Versionsnummern bekannte Schwachstellen leichter auffindbar machen. Sie zu verbergen ist Hygiene, kein Schutz: Der OWASP-Testleitfaden nennt das Security through Obscurity, und MDN hält Patchen für den robusteren Ansatz.

So prüfen Sie. Führen Sie curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):' aus und durchsuchen Sie dann den Seitenquelltext nach generator und nach Skriptdateinamen mit Versionsnummern.

So sieht ein gutes Ergebnis aus. Server: nginx ohne Versionsnummer und kein X-Powered-By.

Was hilft. server_tokens off; in nginx, expose_php = Off in der php.ini, app.disable('x-powered-by') in Express. Verrät eine Seite eine veraltete Bibliothek, aktualisieren Sie sie, statt sie zu verstecken.

Cache, Kompression und CDN

Warum das wichtig ist. Caching-Regeln entscheiden, wer eine gespeicherte Kopie einer Antwort bekommt. Eine persönliche Seite, die ein CDN zwischenspeichert, kann beim nächsten Besucher landen; deshalb brauchen personalisierte Antworten laut MDN Cache-Control: private.

So prüfen Sie. Führen Sie curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/ aus, melden Sie sich dann an, öffnen Sie eine Kontoseite und lesen Sie deren Antwort-Header in den Entwicklerwerkzeugen des Browsers.

So sieht ein gutes Ergebnis aus. HTML wird mit Content-Encoding: br oder gzip ausgeliefert; jede Antwort hat ein ausdrückliches Cache-Control; ein langes max-age plus immutable gibt es nur für versionierte statische Dateien; Seiten mit Nutzerdaten tragen private oder no-store (no-cache erlaubt das Speichern weiterhin).

Was hilft. Cache-Control je nach Art der Route setzen, angemeldete Bereiche aus dem CDN-Cache heraushalten und Text auf dem Server oder im CDN komprimieren. Kein CDN zu haben ist für sich kein Risiko; der Leitfaden zur Website-Performance behandelt die Geschwindigkeit.

8. Domainregistrierung: Ablauf, Sperre und Kontakte

Warum das wichtig ist. Läuft eine Domain unter einer generischen Top-Level-Domain wie .com ab, verlangt die Expired Registration Recovery Policy der ICANN, dass der Registrar ihre DNS-Auflösung für eine gewisse Zeit unterbricht; Website und E-Mail fallen dann gemeinsam aus. Erinnerungen an die Verlängerung gehen an den hinterlegten Kontakt, womöglich eine ehemalige Mitarbeiterin oder ein Postfach auf genau der Domain, die gerade abläuft.

So prüfen Sie. Für generische Domains wie .com, .org oder .shop nutzen Sie das Lookup-Tool der ICANN. Seit dem 28. Januar 2025 ist RDAP die maßgebliche Quelle für Registrierungsdaten generischer Top-Level-Domains; WHOIS ist nur noch für .com, .name und .post vorgeschrieben. Für Länderendungen fragen Sie die zuständige Registry oder Ihren Registrar. Für .de zeigt die Domainabfrage der DENIC unter anderem Domainstatus und Nameserver; per RDAP oder whois.denic.de liefert DENIC zusätzlich das Datum der letzten Änderung. Für .at ist nic.at zuständig, für .ch und .li Switch. Laufzeit, automatische Verlängerung und Zahlungsart sehen Sie im Kundenkonto Ihres Registrars oder Hosters; melden Sie sich dort an und prüfen Sie die Einstellungen.

So sieht ein gutes Ergebnis aus.

• Ablauf erst in Monaten, automatische Verlängerung aktiv und eine Zahlungsart, die am Verlängerungstag noch gültig ist.
• Bei generischen Domains ist clientTransferProhibited gesetzt, dazu Update- und Löschsperren, wo der Registrar sie anbietet; kein clientHold oder serverHold, die die Domain aus dem DNS nehmen. Für Länderendungen gelten die Statuswerte der jeweiligen Registry.
• Kontakte, die mehr als eine Person erreichen, mit mindestens einer Adresse, die nicht auf der Domain selbst liegt, und Mehr-Faktor-Authentifizierung für das Registrar-Konto.

Was hilft. Automatische Verlängerung einschalten, für mehrere Jahre verlängern, den Registrar bitten, die Sperren zu setzen (der Leitfaden der ICANN zu EPP-Statuscodes erklärt jeden einzelnen), und die Kontakte aktualisieren.

9. Was diese Checkliste nicht abdeckt

Diese acht Punkte beschreiben das öffentliche Umfeld Ihrer Website. Eine Website kann alle bestehen und trotzdem leicht angreifbar sein, weil keiner davon die Anwendung oder ihren Betrieb betrachtet. Prüfen Sie Folgendes getrennt:

• Schwachstellen der Anwendung: Injection, Cross-Site-Scripting in Ihren Templates, unsichere Uploads, Zugriffe zwischen Konten.
• Authentifizierung und Sessions: Login, Passwort-Zurücksetzung, Mehr-Faktor-Authentifizierung, Admin-Bereiche.
• Abhängigkeiten und Server: CMS-Plugins, Pakete, Patches des Betriebssystems.
• Secrets und Zugänge: Schlüssel und Tokens in Repositories oder Frontend-Bundles, und wer Zugriff auf Produktion, DNS-Anbieter und Registrar hat.
• Backups: eine Wiederherstellung, die Sie tatsächlich getestet haben.

Der Leitfaden Website-Sicherheit prüfen geht Login, Berechtigungen und weitere Prüfungen auf Anwendungsseite durch, und der OWASP Web Security Testing Guide liefert ausführliche Testfälle.

Ein schneller erster Durchgang für einen Origin. Der kostenlose Snapshot braucht kein Konto. Für einen öffentlichen Origin liest er öffentliches DNS, Mail-Einträge im DNS, Daten zur Domainregistrierung, den TLS-Handshake und die HTTP-Antwort der Startseite; er sendet keine Exploits, Portscans, Login-Versuche oder Last. Sie erhalten einen Score, eine Härtungsnote, die Zahl der Risikosignale und der bestandenen Prüfungen und bis zu drei Signale, die Sie sich zuerst ansehen sollten. Er ist kein Penetrationstest: Ein guter Score heißt, dass diese öffentlichen Signale zu diesem Zeitpunkt in Ordnung aussahen. Der Free-Plan umfasst nur Sicherheitsprüfungen; die sechs Audit-Bereiche (Sicherheit, technisches SEO, KI-Sichtbarkeit, Barrierefreiheit, Performance, Integrationen) gibt es ab dem Starter-Plan für 49 US-Dollar im Monat.