Website-Sicherheit prüfen: Was ein Sicherheitsaudit umfasst und wie Sie anfangen

1. Schutzmaßnahmen entlang eines echten Ablaufs verfolgen

Beginnen Sie mit einer Aufgabe, die für Besucher zählt: ein Konto anlegen, eine Bestellung einsehen oder eine Supportanfrage stellen. Listen Sie die beteiligten Seiten, Dienste und Datensätze auf. So bekommt die Prüfung ein praktisches Ziel, und die technische Arbeit bleibt mit dem verbunden, was Ihren Besuchern wichtig ist.

Jede Schicht trägt ihren Teil bei. Das Netzwerk macht die vorgesehenen Dienste erreichbar. Die Anwendung erkennt das Konto und wendet Berechtigungen an. Der Browser erhält Inhalte über eine verschlüsselte Verbindung und befolgt die Richtlinien der Antwort. Hosting-Anbieter und Softwareabhängigkeiten tragen das alles im Hintergrund. Der OWASP Web Security Testing Guide bietet eine strukturierte Möglichkeit, diese Schichten nacheinander zu untersuchen. Ein gemeinsamer Ablauf zeigt Entwicklung, Betrieb und Support, wie ihre Arbeit ineinandergreift.

2. Jede Schutzmaßnahme mit einem konkreten Nutzen verbinden

Mit diesen Zielen lassen sich Prioritäten sachlich besprechen. Ein Kontoablauf, den viele Kunden nutzen, verdient oft zuerst Aufmerksamkeit. Eine gemeinsam genutzte Komponente lohnt sich besonders, weil gute Praxis dort auf viele Seiten gleichzeitig wirkt. Wählen Sie die Arbeit danach aus, welchen Ablauf sie unterstützt und an wie vielen Stellen sie hilft.

3. Anmeldung und Berechtigungen gemeinsam prüfen

Authentifizierung stellt fest, welches Konto den Dienst gerade nutzt. Autorisierung bestimmt anschließend, welche Aktionen und Datensätze erlaubt sind. Beschreiben Sie diese Regeln in Alltagssprache: Eine Kundin sieht ihre eigenen Rechnungen, ein Supportmitarbeiter bearbeitet die ihm zugewiesenen Anfragen, eine Administratorin verwaltet die Teameinstellungen. Aus dieser Beschreibung wird ein brauchbarer Testplan. Eine typische Testfrage lautet: Kann Testkonto A die Rechnung von Testkonto B öffnen, wenn es die Rechnungsnummer in der Adresse ändert? Verhindern muss das der Server; eine ausgeblendete Schaltfläche reicht nicht.

Prüfen Sie Registrierung, Anmeldung, Verifizierung, Wiederherstellung und Abmeldung als zusammenhängenden Ablauf. Unterstützen Sie Passwortmanager und klare Formularbeschriftungen. Wo Mehr-Faktor-Authentifizierung (MFA) sinnvoll ist, sorgen Sie für eine verständliche Einrichtung und einen ebenso verständlichen Wiederherstellungsweg. Die OWASP-Empfehlungen zur Authentifizierung erläutern die zugrunde liegenden Kontrollen. Testen Sie mit eigenen Testkonten für jede vorgesehene Rolle und mit Beispieldaten, die man auf den ersten Blick erkennt.

4. Technische Beobachtungen so festhalten, dass andere sie nutzen können

Eine gute Prüfung hält fest, was untersucht wurde und was dabei passiert ist. Dazu gehören die genaue Seite oder der Dienst, der relevante Wert aus der Antwort, das erwartete Verhalten und die einzelnen Schritte. Verwenden Sie in geteilten Notizen Beispieldaten und unkenntlich gemachte Zugangsdaten. So erhalten Entwicklung, Support und spätere Prüfer eine gemeinsame Grundlage.

Ordnen Sie zusammengehörige Beobachtungen der Komponente zu, die dafür zuständig ist. Mehrere Seiten können dieselbe Sitzungskonfiguration nutzen, mehrere Netzwerkbefunde können denselben Dienst beschreiben. Bei einer öffentlichen Website läuft HTTPS üblicherweise über Port 443; Port 80 dient meist nur der Weiterleitung auf die HTTPS-Adresse. Wer den Zweck jedes erreichbaren Dienstes notiert, macht aus einer Liste technischer Details eine verständliche Karte.

Bewerten Sie Befunde realistisch. Ein Server-Header, der Software und Version nennt, ist laut OWASP für sich genommen nicht unbedingt eine Schwachstelle. Die Angabe zu kürzen schadet nicht; wirksamer ist es aber, die Server mit aktuellen Updates und Sicherheitspatches zu versorgen. Halten Sie erfolgreiche Prüfungen neben sinnvollen Folgeaufgaben fest, damit das Protokoll auch zeigt, welche Schutzmaßnahmen bereits greifen.

5. Gute Praxis in die tägliche Entwicklung einbauen

Setzen Sie auf bewährte Authentifizierungskomponenten, parametrisierte Datenbankabfragen und Berechtigungsprüfungen auf dem Server. Bewahren Sie Zugangsdaten und API-Schlüssel außerhalb des Quellcodes in einem Secrets-Manager auf, mit einer verantwortlichen Person und einem festen Verfahren zur Erneuerung. Geben Sie Sitzungscookies Einstellungen, die zum echten Kontoablauf passen: Secure, damit der Browser sie nur über HTTPS sendet, HttpOnly, damit Skripte auf der Seite sie nicht auslesen können, und einen bewusst gewählten SameSite-Wert. Der Browser schickt ein HttpOnly-Cookie weiterhin mit passenden Anfragen mit; Cross-Site-Scripting selbst verhindert das Attribut nicht. Die MDN-Referenz zu Set-Cookie und die OWASP-Hinweise zu HTTP-Headern erklären, wie Cookie- und Browserrichtlinien zu dieser Grundlage beitragen.

Führen Sie ein kurzes Dienstregister mit Zweck, verantwortlicher Person, Softwareversion und Aktualisierungsweg. Kommt ein Zahlungsanbieter oder ein Support-Widget hinzu, tragen Sie es dort ein und durchlaufen Sie den zugehörigen Nutzerablauf. Geplante Updates und eine gesicherte, funktionierende Konfiguration, zu der Sie zurückkehren können, erleichtern die Abstimmung im Team. Wenige Praktiken, die in allen Vorlagen konsequent angewendet werden, geben allen, die an der Website arbeiten, einen gemeinsamen Standard.

6. Einen wiederholbaren Prüfrhythmus etablieren

Legen Sie eine Ausgangsbasis fest und wiederholen Sie dieselben Prüfungen nach relevanten Änderungen. Verwenden Sie dasselbe Ziel, dieselbe Rolle und denselben Ablauf, damit Vergleiche aussagekräftig bleiben. Bei Berechtigungen bestätigen Sie, dass jedes Testkonto genau den vorgesehenen Zugriff erhält. Bei Browserrichtlinien durchlaufen Sie dieselben Formulare und externen Rücksprünge wie Ihre Besucher.

1. Halten Sie Seiten, Rollen und Aktionen fest, die zur Prüfung gehören.
2. Untersuchen Sie die ausgelieferten Antworten und notieren Sie die beobachtete Schutzmaßnahme.
3. Durchlaufen Sie den vorgesehenen Ablauf mit repräsentativen Testkonten.
4. Dokumentieren Sie Ergebnis, verantwortliche Person und den nächsten Prüfanlass.

Sinnvolle Anlässe für eine erneute Prüfung sind Änderungen an Hosting, Anmeldung, gemeinsam genutzten Vorlagen oder angebundenen Diensten. Ein datiertes Protokoll hilft neuen Kolleginnen und Kollegen, die Gründe hinter der Konfiguration zu verstehen. Mit der Zeit entsteht so eine praktische Chronik, wie die Website gepflegt wird und wie wichtige Kundenaktionen abgesichert sind.

7. Mit einer kleinen ersten Prüfung beginnen

Wählen Sie eine öffentliche Seite und eine Kontoaktion und beschreiben Sie ihre Schutzmaßnahmen in einer kurzen Checkliste. Einen ersten Blick von außen auf Ihre Domain liefert der kostenlose Snapshot von Sitelemetry: Er führt ohne Anmeldung acht passive Prüfungen an der Startadresse Ihrer Domain aus, von DNS und TLS-Zertifikat über Security-Header bis zum Status der Domainregistrierung. Er ist kein Penetrationstest; Konten und Berechtigungen prüfen Sie weiterhin selbst mit Testkonten. Mehr zur Verbindungsebene steht im Leitfaden zu SSL/TLS-Zertifikat und HTTPS; welche Header Ihre Website sendet und wie Sie fehlende ergänzen, zeigt der Security Headers Check, und die Domainkommunikation behandelt der Leitfaden zu SPF, DKIM und DMARC. Vor dem Go-live einer neuen Website oder nach einem Umzug geht die Website-Launch-Checkliste diese öffentlichen Einstellungen Punkt für Punkt durch. Einzelne Ebenen prüfen Sie kostenlos mit dem Security Headers Checker, der acht wichtige Header auf der Startseite bewertet, und dem SPF- und DMARC-Checker für die Mail-Einträge einer Domain.