Wissen / Sicherheit und Prüfumfang

Website-Sicherheitscheck: Den Umfang klären

Kurz gesagt: Ein Website-Sicherheitscheck ist nur so aussagekräftig wie sein vereinbarter Umfang. Klären Sie Systeme, Prüfziele, Methoden, Berechtigungen und Nachweise vor dem Auftrag. Eine Kontrolle von Einstellungen ist etwas anderes als ein gezielter Penetrationstest. Der Bericht soll bestätigte Befunde, ungeprüfte Bereiche und nächste Schritte verständlich trennen; er garantiert keine vollständige Sicherheit.

Veröffentlicht am / Aktualisiert am / Redaktion: Ruhrstack / 11 Minuten Lesezeit

01 / PRÜFZIEL

Welche Frage soll der Sicherheitscheck beantworten?

Ein Angebot mit dem Wort Sicherheit braucht eine konkrete Aufgabe.

„Bitte prüfen Sie unsere Website“ kann vieles bedeuten. Ein Unternehmen möchte wissen, ob vorhandene Software gepflegt wird. Ein anderes braucht eine Bewertung von Rollen und Zugängen. Bei einer Anwendung mit Kundenkonten steht vielleicht eine gezielte Untersuchung der Schutzmechanismen im Vordergrund. Ohne die zugrunde liegende Frage lassen sich Umfang und Ergebnis kaum sinnvoll vergleichen.

Beschreiben Sie zunächst den Anlass: neue Website, unbekannter Zustand, Wechsel der Betreuung oder eine neue Funktion mit zusätzlichen Daten. Notieren Sie, welche Entscheidung Sie danach treffen möchten. Soll eine konkrete Einstellung korrigiert werden? Müssen Verantwortlichkeiten geklärt werden? Brauchen qualifizierte Spezialisten einen weitergehenden Prüfauftrag? Diese Fragen führen zu unterschiedlichen Arbeiten und Nachweisen.

Der Begriff Website-Sicherheitscheck bezeichnet hier eine vereinbarte Prüfung. Aus dem Namen allein folgt kein einheitlicher Umfang. Fragen Sie deshalb nach der tatsächlichen Tätigkeit und nach ausdrücklichen Ausschlüssen. Ein begrenzter Check kann eine sinnvolle erste Bestandsaufnahme sein, wenn seine Aussagekraft ehrlich beschrieben wird. Er sollte nicht als Nachweis für Bereiche verwendet werden, die niemand untersucht hat.

Die NIST-Veröffentlichung SP 800-115 behandelt die Planung technischer Sicherheitsprüfungen, unterschiedliche Verfahren, ihre Grenzen und die Auswertung von Befunden. Der Leitfaden stammt von 2008; hier dient er als Grundlage für die Abgrenzung von Prüfmethoden, nicht als Quelle für aktuelle einzelne Schwachstellen.

02 / METHODEN

Kontrollprüfung, Schwachstellensuche und Penetrationstest unterscheiden.

Eine passende Methode folgt dem Prüfziel und den zulässigen Eingriffen.

Eine Kontrollprüfung kann etwa dokumentierte Rollen, verfügbare Softwarestände oder vereinbarte Backup-Nachweise betrachten. Eine technische Schwachstellensuche untersucht definierte Komponenten mit geeigneten Verfahren auf mögliche Probleme. Ein Penetrationstest geht darüber hinaus und versucht innerhalb einer ausdrücklichen Vereinbarung, Schutzmechanismen gezielt zu überwinden. Welche Kombination nötig ist, hängt vom System und der Frage ab.

Ein Scanner-Ergebnis ist zunächst eine Auskunft über das verwendete Werkzeug und seine Prüfungen. Es muss eingeordnet werden: Betrifft die Meldung die tatsächlich eingesetzte Komponente? Ist sie in Ihrer Konfiguration relevant? Wurde sie fachlich bestätigt oder bleibt sie ein Hinweis? Die Zahl der Meldungen allein sagt wenig darüber aus, welches Problem zuerst behandelt werden sollte.

Der OWASP Web Security Testing Guide 4.2 behandelt verschiedene Prüfverfahren und ihre Verbindung. Daraus lässt sich kein vollständiger Sicherheitsnachweis allein durch ein Werkzeug ableiten. Für den Auftrag zählen die eingesetzten Verfahren, die untersuchten Bereiche und die dokumentierten Grenzen.

Ein weiterer Unterschied ist die Frage nach einem bereits geschehenen Angriff. Die Untersuchung eines Vorfalls und die Sicherung oder Auswertung von Spuren sind andere Aufgaben als ein vorbeugender Check. Wenn ein solcher Verdacht besteht, muss die zuständige Betreuung zunächst klären, welche Unterstützung benötigt wird. Ein gewöhnlicher Prüfauftrag darf diese Spezialaufgabe nicht stillschweigend mitversprechen.

03 / SYSTEMGRENZEN

Die Website ist nicht immer die gesamte zu prüfende Umgebung.

Benennen Sie Anwendungen, Konten und Schnittstellen statt nur eine Startseitenadresse.

Zu einem Webauftritt können mehrere Bereiche gehören: öffentlich erreichbare Seiten, ein Redaktionssystem, ein Kontaktendpunkt, Hostingverwaltung und verbundene Dienste. Sie können unterschiedliche Verantwortliche haben. Eine Prüfung der öffentlichen Darstellung sagt beispielsweise nichts darüber aus, ob alte Administratorkonten im Redaktionssystem noch bestehen.

Erstellen Sie eine überschaubare Liste und ordnen Sie jedem Bereich eine Frage zu. Bei einer statischen Informationsseite kann die Rolle der Auslieferung und der eingesetzten Formfunktion im Vordergrund stehen. Bei einem geschützten Kundenbereich können Anmelden, Berechtigungen und Datenzugriff zusätzliche Prüfziele sein. Fragen Sie die Betreuung, welche Bereiche zum angebotenen Auftrag gehören und welche separat betrachtet werden müssen.

Der OWASP Application Security Verification Standard bietet Anforderungen zur Prüfung technischer Schutzmaßnahmen von Webanwendungen. Wenn solche Anforderungen im Auftrag verwendet werden, sollten Version und ausgewählte Anforderungen benannt sein. Eine pauschale Aussage „nach OWASP geprüft“ beschreibt noch nicht, was tatsächlich untersucht wurde.

Halten Sie auch Abhängigkeiten fest, die nicht in den Auftrag fallen. Ein externer Buchungsdienst kann für Ihren Nutzerweg wichtig sein, obwohl Sie seine Infrastruktur nicht prüfen lassen dürfen. Der Ausschluss bleibt eine relevante Grenze des Ergebnisses. Er wird weder durch ein grünes Gesamtsymbol aufgehoben noch automatisch zur bestätigten Schwachstelle.

04 / BERECHTIGUNG

Die Prüfung braucht vereinbarte Zugänge und klare Grenzen.

Eigene Zuständigkeit für die Website bedeutet nicht automatisch Prüfberechtigung für fremde Systeme.

Bestimmen Sie vor technischen Prüfungen, wer den Auftrag wirksam freigeben kann und welche Systeme ausdrücklich umfasst sind. Klären Sie die benötigten Zugänge über einen vereinbarten sicheren Weg. Schreiben Sie keine Passwörter in ein allgemeines Kontaktformular oder eine öffentliche Projektnotiz. Für die Vorbereitung genügt zunächst eine Beschreibung der Umgebung.

Der GOV.UK Service Manual zu Sicherheitsprüfungen hebt die Abstimmung mit Drittanbietern und die erforderliche Zustimmung zur Prüfung ihrer Systeme hervor. Die Anleitung richtet sich an britische öffentliche Dienste. Wir verwenden hier die praktische Abgrenzung von Zuständigkeiten, keine daraus abgeleitete allgemeine Rechtspflicht für deutsche Websitebetreiber.

Vereinbaren Sie zulässige Methoden, ausgeschlossene Systeme und den Umgang mit unerwarteten Auswirkungen. Bei eingriffsintensiven Untersuchungen gehören ein Ansprechpartner, ein passendes Zeitfenster und klare Unterbrechungsregeln in die Planung. Eine Prüfung soll nicht aus einem unklaren Auftrag heraus zum unkontrollierten Experiment am laufenden Geschäft werden.

Ebenso wichtig ist der Umgang mit Prüfunterlagen. Ein Bericht kann Informationen über Konten, Konfiguration und Schwachstellen enthalten. Legen Sie fest, wer ihn erhält und wie er bereitgestellt und aufbewahrt wird. Für eine öffentliche Referenzbeschreibung sind solche Einzelheiten regelmäßig ungeeignet. Welche vertraglichen oder rechtlichen Anforderungen im konkreten Projekt gelten, ist gesondert zu klären.

05 / AUFTRAGSVORLAGE

Eine Prüfumfangvorlage vor der Beauftragung ausfüllen.

Diese eigene Arbeitshilfe macht Angebote vergleichbar, ohne einen bestimmten Prüfstandard vorzuschreiben.

Sie können die folgenden Punkte in ein kurzes Projektdokument übernehmen. Die Vorlage ersetzt die fachliche Planung durch die prüfende Person nicht. Sie hilft jedoch, fehlende Voraussetzungen früh zu erkennen und eine scheinbar ähnliche Leistung sachlich zu vergleichen. Unbekannte Angaben sollten als Klärungsbedarf stehen bleiben.

Prüfauftrag mit Aufgabe, Nachweisen und Grenzen
PunktWas vereinbart wirdBeispiel einer offenen Frage
EntscheidungsfrageWelches Ergebnis wird zur nächsten Entscheidung benötigt?Bestandsaufnahme oder gezielte Prüfung einer Funktion?
UmgebungWelche Anwendung, Fassung und Bereiche gehören dazu?Sind Redaktionssystem und Formfunktion beide enthalten?
BerechtigungWer gibt welche Prüfung ausdrücklich frei?Welche Zustimmung muss der Hostinganbieter geben?
VerfahrenWelche Tätigkeiten sind vorgesehen und ausgeschlossen?Nur Einstellungen prüfen oder weitergehende Tests?
DurchführungAnsprechpartner, Zugänge und UnterbrechungsregelnWer entscheidet bei unerwarteten Auswirkungen?
ErgebnisNachweise, Status und verständliche EinordnungWie werden bestätigte Befunde von Hinweisen getrennt?
FolgeschrittKorrekturverantwortung und vereinbarte NachprüfungWer bestätigt die Erledigung eines konkreten Befunds?

Ergänzen Sie eine Liste der ausdrücklich ungeprüften Bereiche. Gerade diese Angaben machen einen begrenzten Check nachvollziehbar. Die Entscheidung über spätere technische Anpassungen ist ein eigener Schritt; dafür bietet Website-Änderungen planen eine passende Ergänzung.

06 / BERICHT VERSTEHEN

Ein lesbarer Bericht zeigt, was belegt ist.

Ein Befund braucht einen nachvollziehbaren Zusammenhang mit Ihrem tatsächlichen Betrieb.

Ein brauchbarer Bericht beantwortet auch für die nichttechnische Verantwortung: Was wurde betrachtet? Welche Auffälligkeit wurde bestätigt? Worin liegt das mögliche Problem für dieses Unternehmen? Was sollte als Nächstes geschehen und wer übernimmt es? Fachliche Einzelheiten können in einem gesonderten Nachweis stehen, ohne die verständliche Einordnung zu ersetzen.

Die Berichtsempfehlungen des OWASP WSTG 4.2 behandeln unter anderem Prüfumfang, Einschränkungen, Befunde und Gegenmaßnahmen. Sie weisen auf den begrenzten zeitlichen Aussagewert einer Prüfung hin. Die folgende Darstellung ist unser eigenes fiktives Beispiel, kein übernommenes Berichtsmuster und keine Sicherheitsbewertung eines realen Systems.

Das Beispiel macht die Grenze sichtbar: Ein bestätigter Zustand führt zu einer konkreten Aufgabe. Er beweist nicht gleichzeitig, dass ein Angriff stattgefunden hat oder dass nach einer Korrektur jede andere Gefahr beseitigt wäre. Wenn ein Bericht diese Ebenen vermischt, sollten Sie um eine präzisere Einordnung bitten.

07 / PRIORITÄTEN

Befunde nach Auswirkungen behandeln, nicht nach ihrer Anzahl.

Technische Schwere und geschäftlicher Zusammenhang brauchen eine gemeinsame Entscheidung.

Ein Bericht mit vielen Hinweisen ist nicht automatisch gründlicher als einer mit wenigen. Fragen Sie für wichtige Befunde nach der betroffenen Funktion, der möglichen Auswirkung und den Voraussetzungen. Eine unbestätigte Scanner-Meldung und eine bestätigte unnötige Administratorberechtigung dürfen nicht ohne Erklärung in derselben Sammelkategorie verschwinden.

Besprechen Sie die Reihenfolge mit der technischen Betreuung und der verantwortlichen Unternehmensseite. Die Betreuung kann mögliche Korrekturen und ihre Auswirkungen erläutern. Das Unternehmen erklärt, welche Abläufe und Daten besonders wichtig sind. Eine Maßnahme soll das Problem behandeln, ohne unnötig einen wichtigen Geschäftsvorgang zu unterbrechen. Falls eine akute Gefahr bestätigt ist, braucht es eine entsprechend direkte Abstimmung.

Trennen Sie die Zustände „bestätigt“, „noch zu klären“, „korrigiert“ und „nachgeprüft“. Eine Rechnung für eine Änderung ist noch kein Nachweis, dass der konkrete Befund behoben wurde. Ebenso ist „konnte nicht geprüft werden“ kein positives Ergebnis. Für jedes wichtige Thema sollte nachvollziehbar bleiben, welche Entscheidung getroffen wurde und welche Aufgabe noch offen ist.

08 / GRENZEN UND FOLGEARBEIT

Ein Check ist eine Grundlage für Entscheidungen, keine Garantie.

Neue Funktionen und geänderte Systeme können die Aussage einer früheren Prüfung begrenzen.

Die NCSC-Anleitung zu Penetrationstests betont deren begrenzten zeitlichen Aussagewert und die Bedeutung qualifizierter Prüfer. Sie beschreibt Prüfplanung, Berichte und Folgearbeit. Ein solcher Test ersetzt deshalb weder laufende Schutzmaßnahmen noch die erneute Beurteilung wesentlicher Änderungen.

Wenn nach der Prüfung ein anderer Formulardienst eingebunden oder ein Kundenbereich ergänzt wird, ist dieser Zustand möglicherweise nicht mehr durch die vorhandenen Nachweise beschrieben. Halten Sie daher die geprüfte Umgebung fest. Die Frage lautet nicht nur „wann wurde geprüft?“, sondern auch „welche Fassung und welche Funktionen waren enthalten?“

Die allgemeinen Schutzmaßnahmen erläutert Website-Sicherheit: Grundlagen. Zuständigkeiten und wiederkehrende Aufgaben behandelt Website-Betrieb nach dem Launch. Dieser Beitrag konzentriert sich dagegen auf eine einzelne Beauftragung und die Aussagekraft ihres Ergebnisses. Das verhindert, dass eine einmalige Prüfung unbeabsichtigt als laufende Betreuung verstanden wird.

09 / ZUSAMMENARBEIT

Vorbereitung selbst übernehmen und den passenden Prüfauftrag klären.

Ein überschaubarer Auftrag beginnt mit transparenten Fragen statt mit einem umfassenden Sicherheitsversprechen.

Sie können selbst den Anlass formulieren, die bekannten Systeme sammeln und vorhandene Zuständigkeiten zusammentragen. Auch bisherige Berichte und offene Rückfragen sind hilfreich, sofern sie sicher und nur an die vorgesehenen Personen weitergegeben werden. Diese Vorbereitung gibt dem Gespräch eine belastbare Grundlage; Sie müssen dafür keine eigenen Angriffstests durchführen.

Professionelle Begleitung hilft dabei, aus einer allgemeinen Sorge eine passende Aufgabe zu machen. Ein Webteam kann die eigene technische Umgebung erklären, offene Punkte einordnen und Korrekturen koordinieren. Für spezialisierte Untersuchungen ist die passende Qualifikation entscheidend. Umfang und Grenzen sollten deshalb gemeinsam feststehen, bevor technische Arbeit beginnt.

Ruhrstack beschreibt auf der Leistungsseite Sicherheit Checks für vereinbarte Bereiche, die Einordnung gefundener Risiken und abgestimmte Maßnahmen. Dort wird ausdrücklich zwischen diesen Leistungen und Penetrationstests, forensischen Untersuchungen sowie zertifizierten Audits unterschieden. Welche vorhandene Umgebung geprüft werden kann und welche zusätzliche Unterstützung nötig ist, wird für das konkrete Vorhaben geklärt.

Bitten Sie um einen Auftrag, dessen Ergebnis Sie später überprüfen können: benannte Bereiche, geeignete Nachweise, verständliche Befunde und klar verantwortete nächste Schritte. Das ist die praktische Grundlage für eine sinnvolle Sicherheitsentscheidung. Eine pauschale Aussage „Website geprüft“ wäre dafür zu wenig.

10 / QUELLEN

Quellen und redaktioneller Stand.

Die Quellen wurden am 8. Oktober 2026 geprüft. Auftragsvorlage und Beispielbefund sind eigene redaktionelle Arbeitshilfen. GOV.UK richtet sich an britische öffentliche Dienste; die aufgeführten Leitfäden belegen keine Zertifizierung von Ruhrstack.

  1. NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment, abgerufen am 8. Oktober 2026.
  2. OWASP: Application Security Verification Standard, abgerufen am 8. Oktober 2026.
  3. OWASP: Web Security Testing Guide 4.2, Einführung, abgerufen am 8. Oktober 2026.
  4. OWASP: Web Security Testing Guide 4.2, Berichte, abgerufen am 8. Oktober 2026.
  5. NCSC: Penetration testing, abgerufen am 8. Oktober 2026.
  6. GOV.UK: Vulnerability and penetration testing, abgerufen am 8. Oktober 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Welche Prüfung braucht Ihre Website?

Beschreiben Sie den Anlass und die bekannte Umgebung. Wir klären, welche Bereiche wir prüfen können und wo zusätzliche Unterstützung nötig ist. Bitte senden Sie dabei keine Passwörter.

Prüfumfang besprechen