Website Security Audit: Ablauf und Checkliste

Eine beauftragte Sicherheitsprüfung läuft in fünf Abschnitten ab. Vor dem ersten Aufruf wird schriftlich festgelegt, was geprüft wird, in welchem Zeitfenster, wer auf beiden Seiten erreichbar ist und wann abgebrochen wird. Diese Beauftragung ist keine Formalie, sondern der Anfang der Kette, aus der sich die Berechtigung ergibt. Dann arbeitet sich der Prüfer von außen nach innen: zuerst ohne jeden Zugang, dann als unangemeldeter Besucher, und nur wo ausdrücklich freigegeben mit Zugangsdaten oder Einsicht in den Quellcode. Was dabei drankommt, ist nicht beliebig: Der Web Security Testing Guide der OWASP Foundation gliedert eine Webanwendung in zwölf Prüfbereiche. Jeder Fund bekommt eine Einstufung nach dem Common Vulnerability Scoring System, kurz CVSS, damit zwei Leute über dieselbe Lücke gleich sprechen. Brauchbar ist der Bericht, wenn zu jedem Fund dabeisteht, wie man ihn nachstellt und wie man ihn repariert. Und nach der Reparatur kommt die Nachprüfung, sonst weiß niemand, ob sie gewirkt hat.

Diese Arbeit macht bei mir ein KI-Mitarbeiter, mit eigenem Rahmen und eigener Freigabe je Auftrag. Dazu unten mehr. Willst du erst selbst schauen, ist Website-Sicherheit online prüfen der günstigere Einstieg. Warum ich solche Aufgaben abgebe, steht in KI für kleine Unternehmen.

Was vor dem ersten Aufruf geklärt wird

Dieser Teil wird auf Agenturseiten gern als Vorgeplänkel abgehandelt. Er ist es nicht. Ein Sicherheitstest greift in ein laufendes System ein, auch wenn er harmlos aussieht. Der Rechtsrahmen ist dabei genauer, als Merksätze es gern machen: § 202a StGB setzt besonders gesicherte Daten und die Überwindung einer Zugangssicherung voraus, § 202b StGB das unbefugte Abfangen einer nichtöffentlichen Datenübermittlung. Nicht jeder passive Abruf einer öffentlichen Seite erfüllt das. Umgekehrt reicht die Erlaubnis deines Auftraggebers nicht automatisch für Infrastruktur, die einem Hoster, einem Software-Anbieter oder weiteren Mandanten gehört. Ich bin kein Anwalt, und das hier ist keine Rechtsberatung. Praktisch: Die schriftliche Beauftragung bleibt feste Hauspraxis, ist aber nicht die ganze Berechtigung. Dazu gehören die Kette bis zum Eigentümer jedes berührten Systems, die Bedingungen deiner Anbieter, die Auftragsverarbeitung, der Umgang mit Testdaten und die Frage, welches Recht gilt.

Sieben Punkte haben sich in meiner Vorlage bewährt, als Vorabskizze:

Zwei Dinge werden dabei regelmäßig übersehen. Erstens reicht es bei gemieteter Infrastruktur nicht, den Hoster oder Software-Anbieter zu informieren: Seine Richtlinie kann eine ausdrückliche Genehmigung, ein Zeitfenster oder bestimmte Testmethoden verlangen, und die holst du vor dem Test ein, nicht am Testtag. Zweitens gehört alles, was nicht ausdrücklich freigegeben ist, nicht zum Umfang.

Die Stufen: von außen nach innen

Prüfungen unterscheiden sich vor allem darin, wie viel der Prüfer vorher weiß und bekommt. Ich arbeite mit vier Stufen, und das ist ein Auftragsmodell, keine Norm: Aufklärung ist in den gängigen Methodiken eine Phase, während Black-, Grey- und Whitebox beschreiben, wie viel Wissen und Zugriff der Prüfer hat. Der Web Security Testing Guide führt Prüfkategorien und mehrere Methodiken auf, schreibt diese vier Begriffe aber nicht als Pflichtreihenfolge fest.

Nicht jedes Projekt braucht alle vier. Die Prüftiefe leitest du aus der Angriffsfläche ab, nicht aus dem Namen einer Stufe: Welche Daten liegen da, welche Technik steckt dahinter, wie oft ändert sich etwas, wie viel Risiko trägst du bewusst. Für eine weitgehend statische Seite kann eine externe Baseline angemessen sein; ein Vollständigkeitsnachweis ist sie nicht, weil ein Test von außen weder Quellcode noch Dateirechte und viele serverseitige Fehler sieht. Prüfziele und Kategorien legst du je Auftrag fest, und das gehört in die Beauftragung.

Das Vorgehen steht dabei nicht allein: Der Web Security Testing Guide der OWASP Foundation führt mehrere etablierte Methodiken auf, darunter den Penetration Testing Execution Standard mit seinen sieben Phasen von der Vorabklärung bis zum Bericht, den NIST-Leitfaden 800-115 und das OSSTMM.

Die Checkliste: zwölf Bereiche

Als frei verfügbare Checkliste nehme ich den Web Security Testing Guide. Aktuell stabil ist Version 4.2, Version 5.0 ist in Arbeit (Stand September 2026). Er teilt die Prüfung einer Webanwendung in zwölf Bereiche:

Die Liste ist ein Prüfrahmen, keine Abhakliste mit garantiertem Ergebnis: Sie sagt, wo man hinschaut, nicht, was man findet. Im Angebotsgespräch ist sie trotzdem nützlich. Frag nach, welche Bereiche im Umfang enthalten sind. Ein Angebot ohne Autorisierung und Geschäftslogik ist kein schlechtes, aber ein anderes.

Wie Funde eingestuft werden, und wo die Zahl aufhört

Am Ende steht eine Liste, und die Liste braucht eine Reihenfolge. Der verbreitete Standard dafür ist das Common Vulnerability Scoring System, gepflegt bei FIRST.Org, aktuell in Version 4.0 aus dem November 2023. Es übersetzt die Eigenschaften einer Schwachstelle in eine Zahl zwischen 0 und 10 und diese in Stufen: 0,1 bis 3,9 niedrig, 4,0 bis 6,9 mittel, 7,0 bis 8,9 hoch, 9,0 bis 10,0 kritisch. Von den vier Metrikgruppen Base, Threat, Environmental und Supplemental nennen die meisten Berichte nur den Base-Wert, also die Lücke selbst, ohne dein Umfeld.

Besser als „kritisch" nach Gefühl ist das aus zwei Gründen: Die Einstufung folgt aus benannten Eigenschaften, und du kannst ihr begründet widersprechen. Dafür braucht der Bericht neben der Zahl den CVSS-Vektor und die Begründung. Zwei Prüfer können dieselbe Lücke unterschiedlich bewerten, weil sie einzelne Metriken anders einschätzen; nachvollziehbar wird das erst über den Vektor.

Und jetzt die Grenze, die selten jemand dazusagt: Eine CVSS-Zahl kennt deinen Geschäftskontext nicht. Die Spezifikation von FIRST sagt das selbst. Anwender sollen die Base-Metriken um Threat- und Environmental-Werte für ihre eigene Nutzung ergänzen. Und sie nennt Faktoren, die außerhalb von CVSS liegen und trotzdem über die Reihenfolge entscheiden: regulatorische Anforderungen, die Zahl betroffener Kunden, finanzielle Verluste durch einen Vorfall, Gefahr für Leib oder Eigentum, Rufschaden.

Übersetzt in deinen Alltag: Ein „mittel" in dem Formular, über das alle deine Anfragen hereinkommen, kann dringender sein als ein „hoch" in einem Bereich, den du nächsten Monat abschaltest. Die Zahl sortiert die Technik, die Reihenfolge entscheidest du. Ein guter Prüfer fragt deshalb vorher, was dein Geschäft trägt.

Was in einem brauchbaren Bericht steht

Hier trennt sich gute von schlechter Arbeit. Das Qualitätsziel: Zu jedem Fund gehören der Weg, ihn nachzustellen, und der Weg, ihn zu reparieren. Fehlen beide, kann dein Entwickler nichts damit anfangen, die Nachprüfung hat keine Grundlage, und der gesparte Aufwand landet bei dir. Eine Ausnahme: Bei besonders heiklen Funden gehören die Einzelheiten nicht in ein Dokument, das im Haus herumgereicht wird, sondern geschützt an die Leute, die sie zum Reparieren brauchen.

Der Web Security Testing Guide beschreibt in seinem Berichtskapitel den üblichen Aufbau: eine Einleitung mit Versionsstand, Umfang, Einschränkungen, Zeitraum und Prüfteam, eine Zusammenfassung für die Geschäftsführung ohne technische Einzelheiten, eine Übersichtstabelle aller Funde mit Kennung, Titel und Risikostufe, dann die Einzelbefunde. Zu jedem gehören laut Guide Ausnutzbarkeit, Auswirkung, Risikostufe von informativ bis kritisch, eine Beschreibung und, wörtlich, detaillierte Schritte zur Behebung, dazu Belegmaterial.

Lass dir vor dem Auftrag ein Berichtsmuster zeigen und schau auf drei Dinge:

1. Steht bei jedem Fund ein Beleg? Ein Bildschirmfoto, eine Anfrage, eine Protokollzeile. Ohne Beleg ist es eine Behauptung.
2. Steht dabei, wie man den Fund nachstellt? Wer ihn nicht reproduzieren kann, hält ihn für einen Fehlalarm.
3. Ist der Reparaturvorschlag konkret? „Eingaben validieren" ist keiner. Welcher Parameter, an welcher Stelle, mit welcher Einstellung, das ist einer.

Ein vierter Punkt gehört dazu, auch wenn ihn selten jemand nennt: Wie viele Fehlalarme anfallen, hängt am Werkzeug und an der Prüfart; bei Mustererkennung von außen sind sie häufig, bei manuell bestätigten Funden selten. In einem brauchbaren Bericht stehen deshalb bestätigte und unbestätigte Treffer getrennt, mit der Angabe, was jemand von Hand nachgeprüft hat.

Nach der Übergabe: die Nachprüfung

Mit der Übergabe ist der Auftrag nicht zu Ende, sondern in der Mitte. Danach folgen vier Schritte: Reihenfolge festlegen, reparieren, nachprüfen, Restrisiko dokumentieren. Die Reihenfolge ist deine Entscheidung, aus dem Grund oben. Nicht alles wird repariert: Bei manchen Funden ist die richtige Entscheidung, das Risiko bewusst zu tragen und das mit Datum und Begründung aufzuschreiben. Die Nachprüfung geht die reparierten Funde entlang der Reproduktionsschritte aus dem Bericht durch und ist deshalb schneller als der Erstdurchgang. Erst danach gilt ein Fund als erledigt, denn eine Reparatur, die niemand nachgeprüft hat, ist eine Absicht.

Der nächste sinnvolle Anlass ist danach keine Jahreszahl, sondern eine Änderung: ein Umbau, ein Umzug, ein neues Zahlungs- oder Buchungsmodul. Dabei verschieben sich Weiterleitungen, Rechte und Zertifikate. Für die beiden Dinge, die sich am schnellsten wieder verschieben, gibt es eigene Anleitungen: SSL-Zertifikat prüfen und, wenn du den Server selbst betreibst, Eigenen Server absichern.

Wie Falk diesen Ablauf fährt

Genau diesen Ablauf fährt bei mir Falk, mein KI-Mitarbeiter für Sicherheit. Er prüft in den vier Stufen von oben und folgt innerhalb einer Stufe fünf Phasen: Bestandsaufnahme der Technik ausschließlich aus öffentlich ausgelieferten Dateien, ein Angriffsflächenmodell entlang von Anmeldung und Sitzungsverwaltung, manuelle Tests, eine Werkzeugprüfung von Verschlüsselung und bekannten Mustern, und am Ende die Bewertung. Zu jedem Fund gehören Beleg, CVSS-Einstufung und ein konkreter Fix.

Drei Dinge daran sind die Umsetzung dessen, was oben steht, und alle drei stehen schriftlich in seiner Rollenbeschreibung, nicht nur in der Absicht. Die Freigabe: Bevor eine einzige Anfrage an das Zielsystem geht, liegt eine schriftliche Freigabe für genau dieses System vor. Das Tempo: Der automatisierte Teil läuft gedrosselt auf höchstens 20 Anfragen pro Minute, ohne Last- und Stresstests und ohne Ausprobieren von Zugangsdaten. Und die Abbruchkriterien: Instabilität, unerwartete Datenzugriffe, ein Ziel, das einem Dritten gehört, oder Warnungen wegen zu vieler Anfragen stoppen den Test sofort. Der fertige Bericht durchläuft danach eine getrennte Prüf-Rolle, bevor ich ihn sehe.

Dass jeder Auftrag eigenen Rahmen und eigene Freigabe bekommt, ist auch der Grund, warum es Falk nicht als Paket zum Herunterladen gibt: Eine Prüfung von der Stange gäbe es nur, wenn es das zu prüfende System von der Stange gäbe. Wie er vorgeht und wo ich ihn bremse, steht auf Sicherheitslücken aufspüren: so arbeitet Falk.

Häufige Fragen

Wie lange dauert ein Website Security Audit?

Das hängt am Umfang und an den freigegebenen Stufen. Der Blick von außen ist der schnellste Teil, die manuelle Prüfung der Zugriffsrechte hinter der Anmeldung der langsamste, weil jemand sich dafür mit mehreren Konten anmelden und Grenzen einzeln durchprobieren muss. Verlang ein festes Zeitfenster in der Beauftragung statt einer mündlichen Zusage; dieselben Treiber bestimmen auch, was ein Sicherheitsaudit kostet.

Bekomme ich nach dem Audit ein Zertifikat?

Nicht im üblichen Sinn. Ein Prüfbericht ist eine Momentaufnahme mit Datum. Der Begriff meint meist eines von drei Dingen: das SSL-Zertifikat deiner Website, das damit nichts zu tun hat und in SSL-Zertifikat prüfen erklärt ist, ein Anbietersiegel über einen bestandenen Scan zu einem Zeitpunkt, oder eine Zertifizierung, die sich meist auf Organisation und Prozesse bezieht statt auf eine Anwendung.

Reicht ein kostenloses Online-Werkzeug nicht aus?

Für den Anfang ist es besser als nichts, und für Zertifikat, Kopfzeilen und veraltete Software liefert es brauchbare Ergebnisse. Unsichtbar bleibt der Bereich hinter der Anmeldung, die Serverseite und die Geschäftslogik. Welches Werkzeug was kann, steht in Website-Sicherheit online prüfen.

Wer darf eine Prüfung überhaupt beauftragen?

Die berechtigte Stelle für jedes berührte System. Bei eigener Infrastruktur ist das regelmäßig der Betreiber; bei Hoster, CDN, SaaS oder gemieteter Software können Anbieterbedingungen und eine zusätzliche Freigabe gelten. Deshalb prüfst du vorab die Berechtigungskette statt nur den Auftraggebernamen.

Lohnt sich das für eine Firmenseite ohne Kundenkonten?

Der Blick von außen ist dort oft der richtige Einstieg. „Keine Kundenkonten" heißt aber nicht „keine Angriffsfläche": Auch eine einfache Seite hat meist einen Redaktionszugang, Formulare, fremde Skripte, eine Veröffentlichungskette und eine Serverkonfiguration. Was davon geprüft werden soll, entscheidest du beim Punkt Prüftiefe, nicht der Umstand, dass es keinen Kundenbereich gibt.

Wie du weitermachst

Schreib die Beauftragung, bevor du Angebote einholst, nicht danach. Für die Vorabskizze reichen sieben Zeilen: Umfang, Zeitfenster, Ansprechpartner mit Notfallkontakt, Prüftiefe, Ausschlüsse, Abbruchkriterien, Vertraulichkeit. Vor dem Start wächst daraus die eigentliche Vereinbarung, in der auch Datenschutz, Haftung, Beweissicherung und das Notfallverfahren stehen. Dieses eine Blatt macht Angebote vergleichbar, weil alle Anbieter denselben Umfang kalkulieren, und es ist der Anfang der Berechtigungskette, nicht schon die ganze. Verlang zusätzlich ein Berichtsmuster und prüf es an den drei Punkten oben: Beleg, Reproduktionsschritte, konkreter Reparaturvorschlag. Wenn du beim Zuschnitt unsicher bist, leg den Entwurf jemandem vor, der das schon gemacht hat, statt ihn allein zu raten. Und wenn du den Schritt dahinter gehen willst, einen KI-Mitarbeiter, der diesen Ablauf fährt und jeden Fund belegt: Der Weg dorthin und die fertigen Rollen liegen in meiner Community Claude Practitioners.