Webserver-Sicherheitstest: Die umfassende Checkliste

Ein Webserver-Sicherheitstest prüft neun Aspekte: TLS-Protokoll und Cipher-Konfiguration, Zertifikatgültigkeit, HTTP-Sicherheits-Header, Content Security Policy, Cookie-Attribute, Offenlegung der Softwareversion, bekannte Schwachstellen in Server und CMS, DNSSEC-Konfiguration sowie unnötig exponierte Dienste und Methoden. Die meisten davon lassen sich kostenlos in weniger als einer Minute über einen Browser verifizieren, und alle sind Konfigurationsprobleme, was bedeutet, dass sie ohne Änderungen am Anwendungscode behoben werden können.

Anwendungsschwachstellen stehen zwar im Fokus, doch ein großer Teil der realen Exposure liegt in der reinen Serverkonfiguration: eine veraltete TLS-Version, die noch aktiviert ist, ein Server-Header, der die genaue Build preisgibt, ein Session-Cookie ohne Secure-Flag, gar keine Content Security Policy. Für nichts davon ist ein Bug in Ihrem Code erforderlich. Alles davon ist von außen sichtbar, was bedeutet, dass ein Angreifer sie vor Ihnen sieht.

Der Vorteil besteht darin, dass sich Konfigurationsprobleme kostengünstig beheben lassen. Diese Checkliste deckt ab, was zu testen ist, warum jeder Punkt wichtig ist und wie man es verifiziert, ohne etwas zu installieren.

Webserver-Sicherheitstest-Checkliste

1. TLS-Protokolle und Cipher-Suiten

SSL 3.0, TLS 1.0 und TLS 1.1 sind veraltet und sollten vollständig deaktiviert werden. TLS 1.2 mit modernen Cipher Suites ist das Minimum, TLS 1.3 ist das Ziel. Cipher Suites sollten Forward Secrecy bieten, damit eine zukünftige Kompromittierung des privaten Schlüssels den abgefangenen Datenverkehr nicht rückwirkend entschlüsseln kann.

Konkret sind folgende Elemente zu entfernen: RC4, 3DES, Export-Grade-Chiffren, alles mit NULL- oder anonymem Schlüsselaustausch sowie Suiten im CBC-Modus, für die es eine moderne Alternative gibt.

Hinzufügen zur Liste für 2026: Post-Quantum-Bereitschaft. Heute erfasster verschlüsselter Datenverkehr kann gespeichert und später entschlüsselt werden, sobald Quantencomputer dazu in der Lage sind, was ihn zu einem aktuellen Problem für alles mit einer langen Vertraulichkeitsdauer macht.

Testen Sie all dies mit dem kostenlosen SSL Security Test, der Web- and E-Mail-Server abdeckt und neben der Compliance mit PCI DSS, GDPR, HIPAA und NIST auch die Bereitschaft für Post-Quantum-Kryptografie meldet.

2. Zertifikatgültigkeit und -kette

Drei Fehlermuster sind für fast jeden Zertifikat-Vorfall verantwortlich. Das Zertifikat läuft ab, meist auf einem Host, der im Scope vergessen wurde. Die Zwischenzertifikatkette ist unvollständig, sodass es in einem Desktop-Browser, der Zwischenzertifikate zwischenspeichert, funktioniert, auf Mobilgeräten und in API-Clients jedoch fehlschlägt. Oder das Zertifikat deckt den tatsächlich verwendeten Hostnamen nicht ab, typischerweise ein „www“ oder eine neue Subdomain.

Alle drei sind unsichtbar, bis sie ausfallen. Continuous ist die einzige wirkliche Lösung, denn ein Zertifikat, das heute gültig ist, läuft zu einem Zeitpunkt ab, den niemand im Blick hat.

3. HTTP Strict Transport Security

HSTS weist Browser an, HTTP für Ihre Domain vollständig abzulehnen. Ohne HSTS kann die allererste Anfrage eines Nutzers abgefangen und herabgestuft werden, noch bevor Ihre Weiterleitung zu HTTPS erfolgt.

Ein sinnvoller Produktions-Header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Fügen Sie „includeSubDomains“ nur hinzu, wenn Sie sicher sind, dass jede Subdomain HTTPS bereitstellt, und behandeln Sie „preload“ als Einbahnstraße, da das Entfernen aus der Preload-Liste langsam ist.

4. Content Security Policy

CSP ist der mit Abstand wirksamste Header gegen Cross-Site-Scripting und Web-Skimming und zugleich der am häufigsten fehlende, da das Verfassen einer Richtlinie, die die Website nicht beeinträchtigt, erheblichen Aufwand erfordert.

Eine Richtlinie ist nur so gut, wie sie streng ist. script-src 'self' 'unsafe-inline' bietet im Grunde keinen Schutz, da unsafe-inline genau die Injektion zulässt, die der Header verhindern soll. Verwenden Sie stattdessen Nonces oder Hashes. Eine Wildcard-Quelle wie script-src * ist dasselbe Problem in anderer Form.

Starten Sie im reinen Berichtsmodus, erfassen Sie Verstöße aus dem tatsächlichen Datenverkehr, verschärfen Sie die Richtlinien und setzen Sie sie anschließend durch. Der kostenlose Website Security Test bewertet die CSP-Stärke und nicht nur deren Vorhandensein – genau das ist entscheidend.

5. Die übrigen Sicherheits-Header

X-Content-Type-Options: nosniff verhindert, dass Browser Content-Typen erraten, wodurch eine vom Nutzer hochgeladene Datei zu einem ausführbaren Skript wird.

X-Frame-Options: DENY oder besser frame-ancestors 'none' in CSP verhindert Clickjacking, indem es das Framing Ihrer Seiten blockiert.

Referrer-Policy: strict-origin-when-cross-origin verhindert, dass vollständige URLs – einschließlich etwaiger Kennungen im Pfad oder in der Query-String – über den Referer-Header an Dritte gesendet werden.

Permissions-Policy deaktiviert Browserfunktionen, die die Website nicht nutzt, wie Kamera, Mikrofon und Geolokalisierung, und schränkt die Möglichkeiten injizierter Skripte ein.

6. Cookie-Attribute

Jedes Session-Cookie benötigt drei Attribute. „Secure“ verhindert die Übertragung über unverschlüsseltes HTTP. „HttpOnly“ macht das Cookie für JavaScript unzugänglich, wodurch viele XSS-Befunde, die zu einer Kontoübernahme führen könnten, zu einer bloßen Störung werden. „SameSite=Lax“ oder „Strict“ blockiert das Cross-Site-Request-Forgery-Muster.

Dies ist eine einzeilige Änderung in nahezu jedem Framework und fehlt dennoch auf einem großen Teil der Produktionswebsites.

7. Versionenoffenlegung

Server: Apache/2.4.29 (Ubuntu) und X-Powered-By: PHP/7.2.24 zeigen einem Angreifer genau, welche veröffentlichten Exploits er ausprobieren kann, noch bevor er eine einzige relevante Anfrage gesendet hat. Generator-Meta-Tags, versionierte Asset-Pfade und Standard-Fehlerseiten geben dieselben Informationen preis.

Das Unterdrücken der Header ist allein keine Lösung, da Verschleierung nichts behebt, aber es entfernt Sie aus den Ziellisten automatisierter Massenscans, was eine sinnvolle Reduzierung des Rauschens darstellt.

8. Bekannte Schwachstellen im Server und im CMS

Die Versionsangabe ist nur deshalb von Bedeutung, weil veraltete Software so weit verbreitet ist. Ein Webserver, ein CMS und dessen Plugins haben jeweils ihren eigenen Release-Zyklus, und Plugins sind in der Regel das schwächste Glied, da sie einmal installiert und danach nie wieder überprüft werden.

Der kostenlose Website Security Test identifiziert neben den Header- und CSP-Prüfungen auch veraltete und anfällige Softwarekomponenten, sodass hierfür kein separates Tool erforderlich ist.

DNSSEC und offengelegte Dienste

DNSSEC signiert DNS-Antworten, sodass diese bei der Übertragung nicht gefälscht werden können. Ohne DNSSEC kann ein Angreifer, der das DNS manipulieren kann, Ihre Nutzer auf seinen Server umleiten und dabei ein gültiges, selbst ausgestelltes Zertifikat vorlegen.

Überprüfen Sie neben DNS, was der Server unnötig offenlegt: TRACE und andere unnötige HTTP-Methoden, Verzeichnisauflistungen, .git-Verzeichnisse, Sicherungsdateien, über das öffentliche Internet erreichbare Admin-Panels sowie offene Status- oder Metrik-Endpunkte.

Weitere sinnvollen Prüfungen

Ein Webserver ist nicht isoliert. Drei ergänzende Tests schließen die verbleibenden Lücken und dauern jeweils eine Minute.

Der Email Security Test prüft die Mail-Seite, auf der TLS-Konfigurations- und Authentifizierungsprobleme weit häufiger auftreten als auf dem Webserver, einfach weil niemand hinschaut.

Der Website-Datenschutztest zeigt, welche Drittanbieter-Skripte, Tracker und Pixel Ihre Seiten laden und wohin Ihre Formulare übermittelt werden – was direkt relevant ist, wenn der Server Zahlungen verarbeitet.

Der Dark Web and Threat Exposure Test sucht extern nach leakten Credentials, Domain-Squatting und Phishing-Seiten, die Ihre Marke missbrauchen – nichts davon erscheint bei einem Server-Scan.

So führen Sie den Test durch

Der schnellste Weg ist der kostenlose Website Security Test für Header, CSP, DNSSEC, Softwareversionen sowie die Einhaltung von GDPR und PCI DSS, und der kostenlose SSL Security Test für die Verschlüsselungsebene. Beide laufen im Browser, erfordern kein Konto und liefern eine Bewertung sowie einen Bericht zum Herunterladen.

Für wiederholte Prüfungen lassen sich beide Tests über die Kommandozeile mit iwtools ausführen, das als Python-Skript und als Docker-Image verfügbar ist:

./iwtools.py websec --api-key ABCDE-12345-FGHIJ-67890 --recheck -p https://example.com
./iwtools.py ssl --api-key ABCDE-12345-FGHIJ-67890 --recheck -p example.com:443

Exit-Code 0 bedeutet, dass alle konfigurierten Prüfungen erfolgreich bestanden wurden, 3 bedeutet, dass mindestens eine fehlgeschlagen ist. Das reicht aus, um eine Bereitstellung scheitern zu lassen, wenn ein Header fehlt oder eine schwache Chiffre wiederkehrt.

Jenseits eines einmaligen Tests

Configuration Drift. Zertifikate laufen ab, ein Plugin-Update entfernt einen Header, eine neue Subdomain wird gestartet, ohne dass dies umgesetzt wurde. Ein Test zeigt Ihnen, wo Sie an einem bestimmten Tag stehen.

ImmuniWeb® Discovery entdeckt kontinuierlich internetexponierte Ressourcen, einschließlich solcher, die von niemandem bei der IT-Sicherheit registriert wurden, und überwacht deren Konfiguration, Zertifikate und Compliance-Status im Zeitverlauf. ImmuniWeb® Neuron deckt die Anwendungsschicht oberhalb des Servers ab und bietet eine SLA ohne Fehlalarme.