Website-Sicherheit prüfen: Was eine passive Prüfung verrät – und was nicht

Auf die Frage „Ist meine Website sicher?“ gibt es kein Ja oder Nein, wohl aber einen sinnvollen ersten Schritt: Prüfen Sie die Teile Ihrer Sicherheit, die ohnehin jeder im Internet sehen kann. Jeder Browser, der Ihre Website besucht, erhält Ihre HTTPS-Konfiguration, Ihr Zertifikat, Ihre Antwortheader und Ihre Cookies. Sind diese falsch konfiguriert, machen Sie Angriffe ohne Not leichter – und die Korrektur ist meist eine Änderung an den Einstellungen, keine Neuentwicklung.

Dieser Leitfaden zeigt, was Sie prüfen sollten, wie Sie dabei vorgehen und – genauso wichtig – was Ihnen eine solche Prüfung nicht sagen kann.

Passive Prüfungen und Sicherheitstests im Vergleich

Eine passive Prüfung stellt die gleiche Art von Anfragen wie ein Browser und liest die Antworten. Sie sendet niemals Angriffs-Payloads, schickt keine Formulare ab und versucht nie, sich anzumelden. Deshalb können Sie sie jederzeit gefahrlos auf eine Live-Website anwenden, und Konfigurationsfehler findet sie zuverlässig.

Ein Penetrationstest ist etwas anderes: Eine qualifizierte Person versucht mit Ihrer Erlaubnis aktiv einzudringen und testet dabei Logins, die Verarbeitung von Eingaben, die Zugriffskontrolle und die Geschäftslogik. Er findet die Schwachstellen, die eine passive Prüfung nicht sehen kann – und ist nichts, was man an einem Produktivsystem improvisiert.

Beginnen Sie mit der passiven Ebene. Das geht schnell, und eine Website, bei der schon die sichtbaren Grundlagen nicht stimmen, hat meist auch andere Probleme.

Was Sie prüfen sollten – und wie es richtig aussieht

1. Durchgehend HTTPS, mit dauerhafter Weiterleitung

Jede Seite sollte über https:// laden, und wer die bloße http://-Adresse eingibt, sollte eine Weiterleitung mit 301 oder 308 auf die HTTPS-Version erhalten. Ein 302 funktioniert zwar, wird aber nicht gespeichert, und eine Website, die Seiten weiterhin über unverschlüsseltes HTTP ausliefert, erlaubt es jedem im selben Netzwerk, sie mitzulesen oder zu verändern. Testen Sie es mit curl -I http://yourdomain.com/ und achten Sie auf die Statuszeile und den Location-Header.

2. Ein gültiges Zertifikat, das sich selbst erneuert

Das Zertifikat muss vertrauenswürdig sein, zu Ihrer Domain passen und darf nicht kurz vor dem Ablauf stehen. Hinter abgelaufenen Zertifikaten steckt fast immer ein Erneuerungsjob, der nach einer Server- oder DNS-Änderung unbemerkt ausgefallen ist. Klicken Sie im Browser auf das Schloss-Symbol, um Aussteller und Ablaufdatum zu sehen, und stellen Sie sicher, dass die Erneuerung automatisiert ist.

3. Security-Header mit sinnvollen Werten

Header wie Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options und Referrer-Policy schalten Schutzfunktionen ein, die in den Browsern eingebaut sind. Ihre Werte zählen ebenso viel wie ihr Vorhandensein: Ein HSTS-max-age von 300 Sekunden, das vom Testen übrig geblieben ist, schützt so gut wie gar nicht, und eine CSP mit 'unsafe-inline' oder * in script-src richtet gegen eingeschleuste Skripte wenig aus. Sichere Werte erklären unsere Leitfäden zu Security-Headern und zur Content-Security-Policy.

4. Cookie-Flags

Session- und Login-Cookies sollten Secure (nur über HTTPS) und HttpOnly (für JavaScript unsichtbar) sein und einen ausdrücklichen SameSite-Wert tragen. Öffnen Sie im Browser die Entwicklertools und sehen Sie unter „Application“ (Chrome, Edge) beziehungsweise „Web-Speicher“ (Firefox) → Cookies nach. Der Leitfaden zum Prüfen der Cookie-Sicherheit geht jedes Flag einzeln durch.

5. CORS, das nicht jedem vertraut

Header für Cross-Origin Resource Sharing teilen Browsern mit, welche anderen Websites Ihre Antworten lesen dürfen. Riskant ist ein Server, der jeden empfangenen Origin in Access-Control-Allow-Origin übernimmt und zusätzlich Access-Control-Allow-Credentials: true sendet. Dann kann jede beliebige Website Antworten lesen, die mit den Cookies Ihrer Besucher abgerufen wurden. Erlauben Sie stattdessen gezielt einzelne Origins.

6. Kein Mixed Content

Eine HTTPS-Seite, die Skripte, Stylesheets oder Frames über http:// lädt, enthält aktiven Mixed Content. Moderne Browser blockieren ihn, was die Seite oft unbrauchbar macht. Bilder und Medien über unverschlüsseltes HTTP sind passiver Mixed Content: weniger gefährlich, aber auch sie schwächen das Schloss-Symbol. Durchsuchen Sie Ihre Templates und Ihre Datenbank nach fest eingetragenen http://-URLs.

7. Was Sie Angreifern verraten

Header wie Server: Apache/2.4.41 oder X-Powered-By: PHP/7.4 geben exakte Versionen preis. Öffentlich erreichbare JavaScript-Source-Maps können Ihren ursprünglichen Frontend-Code offenlegen. Beides ist für sich genommen keine Schwachstelle, spart einem Angreifer aber Zeit. Überlegen Sie außerdem, eine Datei /.well-known/security.txt mit einem Contact-Eintrag und einem Expires-Datum zu veröffentlichen, damit Menschen, die ein Problem finden, wissen, wie sie Sie erreichen.

So geht Rudras Sicherheitscheck vor

Der kostenlose Website-Sicherheitscheck automatisiert die obige Liste. Er sendet eine gewöhnliche Anfrage an Ihre Seite und liest die Header, die gesetzten Cookies (nur Namen und Flags, niemals Werte) und das HTML. Anschließend stellt er eine kleine, feste Anzahl zusätzlicher, rein lesender Anfragen: eine TLS-Verbindung für das Zertifikat, eine Anfrage an http://yourdomain/, um die Weiterleitung zu sehen, eine Anfrage mit einem erfundenen Test-Origin (https://rudra-audit.invalid), um die Reaktion Ihrer CORS-Header zu sehen, und eine kurze Positivliste bekannter Dateien wie security.txt und robots.txt.

Jeder Befund zeigt den beobachteten Wert, wie ein unbedenklicher Wert aussieht und wie sicher sich die Prüfung ist. Manche Muster – etwa Inline-onclick-Handler oder Drittanbieter-Skripte ohne Subresource Integrity – können je nach Kontext harmlos oder riskant sein. Sie werden deshalb mit geringer Sicherheit zur Überprüfung markiert, statt als bestätigte Probleme dargestellt zu werden. Der Bericht führt außerdem die erkannten Technologien und die öffentlich sichtbare Angriffsfläche auf, etwa Login-Formulare und API-URLs, die auf der Seite erwähnt werden – so wissen Sie, was von außen sichtbar ist.

Was eine passive Prüfung nicht verrät

An dieser Stelle wird in eine gute Bewertung gern zu viel hineingelesen. Eine passive Prüfung – unsere eingeschlossen – kann Folgendes nicht:

• Schwachstellen in Ihrem Code finden, etwa SQL-Injection, Cross-Site-Scripting oder eine fehlerhafte Zugriffskontrolle;
• Ihr CMS, Ihre Plugins, Bibliotheken oder Ihren Server auf bekannte verwundbare Versionen untersuchen (es sei denn, ein Header verrät zufällig eine Version);
• irgendetwas hinter einem Login testen, einschließlich Admin-Bereichen und Kontoseiten;
• testen, wie sich Formulare beim Absenden verhalten, einschließlich CSRF-Schutz und Rate Limiting;
• Malware, Defacement oder ein kompromittiertes Konto erkennen;
• Ihr Hosting, Ihre Backups, Ihre Zugriffsrechte oder die Frage prüfen, wer die Admin-Passwörter kennt.

Ein sauberes Ergebnis bedeutet, dass die sichtbare Konfiguration in gutem Zustand ist. Es bedeutet nicht, dass die Website in jeder Hinsicht sicher ist – und kein automatisierter Scan kann das versprechen.

Was Sie über den Scan hinaus tun sollten

1. Halten Sie Software aktuell. Spielen Sie Updates für CMS, Plugins, Themes und Frameworks zeitnah ein und entfernen Sie Plugins, die Sie nicht nutzen.
2. Schützen Sie Admin-Konten. Verwenden Sie für jedes Konto, das die Website ändern kann, ein einzigartiges Passwort und Zwei-Faktor-Authentifizierung.
3. Halten Sie getestete Backups vor. Ein Backup, das Sie nie wiederhergestellt haben, ist eine Hoffnung, kein Plan.
4. Achten Sie auf Veränderungen. Wiederholen Sie die passive Prüfung nach Deployments und immer dann, wenn Sie ein Drittanbieter-Skript einbinden.
5. Beauftragen Sie einen professionellen Test, wenn genug auf dem Spiel steht. Wenn Sie Zahlungen, Gesundheitsdaten oder Benutzerkonten verarbeiten, geben Sie einen Penetrationstest bei einem qualifizierten Tester mit schriftlich festgelegtem Umfang in Auftrag.

Für alles Weitere rund um den Zustand Ihrer Website – Geschwindigkeit, SEO, Barrierefreiheit und defekte Links – führen Sie für dieselbe Seite ein vollständiges Website-Audit durch.