Wie du einen Website-Sicherheitsbericht liest — ohne zu erschrecken | Scanthra

Scanthra · 7 Min Lesezeit · Aktualisiert Mai 2026

Mai 2026
TL;DR: Ein Website-Sicherheitsbericht ist im Grunde eine priorisierte To-do-Liste. Lies ihn in dieser Reihenfolge: Schweregrad (wie schlimm), Trefferquote (wie sicher), Lösung (ein Absatz für einen Entwickler), Compliance-Tags (welche Behörde das interessiert). Fang mit allem an, was KRITISCH oder HOCH ist und eine Trefferquote ≥ 80 % aufweist. Ignoriere nichts, aber du musst auch nicht alles diese Woche beheben.

Warum diese Berichte auf den ersten Blick beängstigend wirken

Die meisten Sicherheitsberichte wurden ursprünglich von Penetrationstestern für andere Penetrationstester geschrieben. Sie benutzen Begriffe wie „Vector", „vulnerable Subdomain-Takeover", „missing HSTS preload", als ob das jeder beim Morgenkaffee liest. Wenn du Inhaber einer kleinen Website bist und gerade ein PDF voller roter Kästen geöffnet hast, ist die natürliche Reaktion: Panik, gefolgt vom Schließen des Tabs.

Mach das nicht. Fast jeder moderne Bericht — auch der von Scanthra — ist unter seiner Oberfläche gleich aufgebaut. Wenn du weißt, wo du schauen musst, kannst du ihn in etwa zehn Minuten lesen.

Die vier Dinge, die jedes gefundene Problem dir sagt

1. Schweregrad — wie schlimm ist es theoretisch?

Der Schweregrad beschreibt den schlimmstmöglichen Schaden, wenn das Problem real ist und jemand es ausnutzt. Es gibt fast immer fünf Stufen:

2. Trefferquote — wie sicher sind wir uns?

Passive Scanner betrachten deine Website von außen, so wie ein Besucher es tun würde. Sie können nicht immer zu 100 % sicher sein, dass ein gefundenes Problem real ist. Die Trefferquote ist eine Zahl, meist 0–100 %, die angibt, wie sicher das Tool bei der Erkennung selbst ist — unabhängig davon, wie schwerwiegend das Problem wäre.

Scanthra verwendet ein 2D-Modell: Jedes Problem hat sowohl einen Schweregrad als auch eine Trefferquote. Wir zeigen nur Probleme mit einer Trefferquote ≥ 50 %. Alles darunter landet im Bereich Beobachtungen, wo wir sagen „wir haben das bemerkt, sind aber nicht sicher, hier ist der Grund" — anstatt falschen Alarm zu schlagen.

Empfohlene Lesereihenfolge:

  1. HOCH oder KRITISCH bei ≥ 80 % Trefferquote — hier beginnen.
  2. MITTEL bei ≥ 80 % Trefferquote — in einen Sprint einplanen.
  3. HOCH oder KRITISCH bei 50–80 % Trefferquote — erst prüfen, dann beheben.
  4. Alles andere — in ein Wartungsfenster bündeln.

3. Die Lösung — ein Absatz auf Deutsch

Jedes nennenswerte Problem enthält einen kurzen Absatz „So behebst du das", auf den ein Entwickler direkt reagieren kann. In Scanthra-Berichten steht dieser unter Selbst beheben: meist ein oder zwei Sätze, manchmal ein kopierbarer Konfigurationsausschnitt. Wenn du die Website nicht selbst betreibst, ist das der Teil, den du an die zuständige Person weiterschickst — deinen Webentwickler, deine Agentur oder den Hosting-Support.

Du musst die Lösung nicht verstehen. Du musst sie nur weitergeben und fragen: „Kannst du das machen, und wann?"

4. Compliance-Tags — wen interessiert das noch außer dir?

Gefundene Probleme tragen oft Tags wie GDPR:Art32, NIS2:Art21, OWASP:A05. Das sind Abkürzungen, die sagen: „Das ist nicht nur unsere Meinung; Behörde/Standard X erwartet, dass du das regelst." Die drei, die du am häufigsten siehst:

Was ist mit Fehlalarmen?

Kein passiver Scanner ist perfekt. Manchmal markiert ein Tool etwas, das bei deinem spezifischen Setup eigentlich kein Problem ist. Beispiele:

Im Zweifelsfall: trotzdem beheben. Fast jeder Fehlalarm ist günstig zu beseitigen, und damit wird er auch beim nächsten Scan kein Rauschen mehr erzeugen. Ausnahmen sind Fälle, bei denen die Behebung echte Arbeit bedeutet — dort lohnt es sich, den Entwickler zuerst bestätigen zu lassen, bevor du Stunden investierst.

Wie du einen Bericht mit einem Entwickler teilst

Wenn du das PDF weiterleitest, reichen drei Sätze:

„Hi — wir haben einen Sicherheitsscan durchgeführt. Könntest du dir die HOCH- und KRITISCH-Befunde ab Seite 4 ansehen und mir sagen, welche du in diesem Sprint beheben kannst und welche mehr Analyse brauchen? Alles NIEDRIG kann ich erstmal hintenanstellen."

Das reicht. Der Entwickler braucht keine Übersetzung des Berichts; er braucht die Erlaubnis, zu priorisieren.

Wie ein „sauberer" Bericht aussieht

Spoiler: Beim ersten Scan hat niemand null gefundene Probleme. Eine typische kleine WordPress-Website landet bei etwa 8–15 Problemen, meist MITTEL-Level-Header und Cookie-Hygiene. Ein vernünftiges Ziel für „sauber" ist:

Alles darüber hinaus ist Gold-Plating — nützlich, aber nicht entscheidend für das Vertrauen deiner Kunden.

Wie Scanthra seine Berichte schreibt

Wir halten die Sprache bewusst einfach. Jedes Problem hat eine Zeile Geschäftliche Auswirkung („wenn ausgenutzt, könnte ein Angreifer Kunden-E-Mails lesen, was ein DSGVO-Verstoß wäre"), einen Absatz Selbst beheben und eine Compliance-Übersicht am Anfang, damit du auf einen Blick siehst, welche Behörden das interessiert. Wenn ein Problem grenzwertig ist, verschieben wir es in die Beobachtungen, anstatt dich zu erschrecken. Ziel ist ein Bericht, den du im Zug nach Hause lesen und am nächsten Morgen handeln kannst — kein 60-seitiges PDF, das du unter „beängstigend, irgendwann" ablegst.

Möchtest du wissen, ob deine Website dieses Problem hat?

Scanthra führt eine freundliche, passive Prüfung durch und schickt dir per E-Mail einen verständlichen PDF-Bericht.

Site kostenlos scannen

Verwandte Anleitungen