Eine Note ist schnell gelesen und schnell missverstanden. Der kostenlose Website-Sicherheitscheck von TOMORIS fasst sieben Prüfbereiche zu einer Gesamtnote von A+ bis F zusammen: Security-Header, SSL/TLS, E-Mail-Sicherheit, DNS, Cookies, eingebundene Inhalte und security.txt. Dieser Beitrag erklärt, wie die Note entsteht, was sie belegt, wo ihre Grenzen liegen und welche Lücken sie am stärksten nach unten ziehen.
Wie die Gesamtnote entsteht
Jeder der sieben Bereiche ist ein eigener Check mit eigener Note. Innerhalb eines Bereichs hat jede Einzelprüfung ein Gewicht: Bestanden bringt die vollen Punkte, ein Hinweis die Hälfte, ein kritischer Befund keine. Reine Informationen zählen nicht mit. Daraus entsteht je Bereich ein Wert von 0 bis 100.
Die Gesamtnote mittelt diese Werte, gewichtet nach ihrer Wirkung für Besucher und Unternehmen:
- Security-Header: 25 Prozent
- SSL/TLS: 20 Prozent
- E-Mail-Sicherheit: 20 Prozent
- DNS-Sicherheit, Cookies und eingebundene Inhalte: je 10 Prozent
- security.txt: 5 Prozent
Aus dem gewichteten Wert wird die Note: ab 95 Punkten A+, ab 85 A, ab 70 B, ab 55 C, ab 40 D, ab 25 E, darunter F.
Drei Regeln, die über die Punkte hinausgehen
- Kritische Befunde begrenzen die Note. Ein kritischer Fehlschlag in einem der sechs Kernbereiche, etwa ein ungültiges Zertifikat oder ein fehlender DMARC-Eintrag, begrenzt die Gesamtnote auf C, auch wenn die Punkte für mehr reichen würden. Ausgenommen ist security.txt: Ihr Fehlen allein soll keine Website auf C drücken.
- A+ gibt es nur ohne Fehlschlag. Ist irgendwo ein Befund nicht bestanden, ist A die beste erreichbare Note.
- Was nicht prüfbar war, zählt nicht. Antwortet ein Bereich nicht rechtzeitig, steht er als „nicht geprüft“ im Bericht und fällt aus der Wertung. Eine gute Note mit Lücken in der Abdeckung sagt deshalb weniger als eine vollständige.
Was die Note aussagt und was nicht
Die Note beschreibt, wie Ihre Website und Ihre Domain von außen konfiguriert sind, gemessen zu einem bestimmten Zeitpunkt. Geprüft wird passiv, also ohne Angriffe und ohne Last: die Antwort-Header der geprüften Seite, Zertifikat und TLS-Protokolle, die DNS-Einträge für Domain und E-Mail, die Cookies beim ersten Besuch, die auf der Seite eingebundenen Inhalte und die Datei security.txt.
Diese Punkte sind gut messbar und wirken direkt. Ein Browser, der eine Content-Security-Policy erhält, blockiert eingeschleuste Skripte. Ein Mailserver, der Ihren DMARC-Eintrag kennt, kann E-Mails mit gefälschtem Absender ablehnen.
Nicht abgedeckt sind dagegen:
- Schwachstellen in der Anwendung selbst, etwa in Formularen, Logins oder Erweiterungen eines CMS
- der Patchstand von Server, CMS und Plugins
- interne Systeme, Benutzerkonten, Berechtigungen und Backups
- Prozesse wie Notfallplanung, Meldewege und Schulungen
Der Check ersetzt deshalb keinen Penetrationstest und keine Beratung. Eine Note A heißt: Die von außen sichtbare Grundkonfiguration ist sauber. Eine Note C oder D heißt: Es gibt konkrete, meist schnell behebbare Lücken, die Angreifern und Betrügern die Arbeit erleichtern.
Fünf Lücken, die die Note besonders stark drücken
Wie stark ein Befund wirkt, folgt aus Gewichtung und Regeln. Diese fünf haben den größten Hebel.
1. Kein DMARC-Eintrag für die Domain
DMARC sagt empfangenden Mailservern, was mit E-Mails geschehen soll, die Ihre Domain im Absender tragen, aber weder SPF noch DKIM passend bestehen (RFC 9989). Fehlt der Eintrag, ist das im Bereich E-Mail-Sicherheit ein kritischer Befund und begrenzt die Gesamtnote auf C, selbst wenn die Website vorbildlich konfiguriert ist. Auch Domains, die gar keine E-Mails versenden, brauchen einen Eintrag: Mit v=DMARC1; p=reject erklären Sie jede E-Mail mit dieser Absenderdomain für unecht.
Die Einrichtung Schritt für Schritt zeigt der Leitfaden E-Mail-Sicherheit: SPF, DKIM und DMARC in fünf Schritten, für Microsoft 365 der Beitrag SPF, DKIM und DMARC in Exchange Online.
2. Keine Content-Security-Policy und kein HSTS
Das sind die beiden schwersten Einzelprüfungen im Header-Bereich, der wiederum am stärksten zählt. Ohne Content-Security-Policy (CSP) darf jedes eingeschleuste Skript im Browser Ihrer Besucher laufen; die CSP ist der wichtigste Schutz gegen Cross-Site-Scripting. Ohne HSTS (Strict-Transport-Security, RFC 6797) kann der erste Aufruf über unverschlüsseltes HTTP abgefangen und umgeleitet werden. Empfohlen ist eine Laufzeit von einem Jahr, also max-age=31536000.
Eine CSP führen Sie am besten zuerst im Modus Report-Only ein, werten die Meldungen aus und setzen sie dann durch. Der CSP-Generator und der Security-Header-Generator liefern fertige Konfigurationen für nginx, Apache, IIS und weitere Plattformen. Der Security-Header-Spickzettel fasst die empfohlenen Werte zusammen.
3. Probleme mit Zertifikat und TLS
Ein abgelaufenes, nicht vertrauenswürdiges oder nicht zur Domain passendes Zertifikat ist kritisch: Browser zeigen dann eine Warnung statt Ihrer Website. Daneben zählt, welche Protokolle der Server spricht. TLS 1.0 und 1.1 sind seit RFC 8996 aus dem Jahr 2021 offiziell veraltet; der Check erwartet, dass sie abgeschaltet sind. Unter den Protokollprüfungen wiegt TLS 1.3 am schwersten. Bewertet wird nach der Technischen Richtlinie BSI TR-02102-2 und den Empfehlungen von Mozilla. Die Einzelheiten zeigt der SSL/TLS-Check.
4. Cookies ohne Schutzattribute
Cookies gehören mit Secure gesetzt, damit sie nur über HTTPS übertragen werden, Sitzungs-Cookies zusätzlich mit HttpOnly, damit Skripte sie nicht auslesen können. Ein Cookie mit SameSite=None ohne Secure verwerfen Browser ganz. Fehlen diese Attribute bei Sitzungs-Cookies, wertet der Cookie-Check das als kritisch. Er zeigt außerdem, ob der Server bekannte Analyse- oder Werbe-Cookies schon beim ersten Aufruf setzt, also bevor Besucher einwilligen konnten. Solche Cookies sind in Österreich nur mit Einwilligung zulässig (§ 165 Abs. 3 TKG 2021).
5. Aktiver Mixed Content und fremde Skripte ohne Integritätsprüfung
Lädt eine HTTPS-Seite Skripte, Stylesheets oder Frames über unverschlüsseltes HTTP, hebelt das den Schutz der ganzen Seite aus. Browser blockieren solche Inhalte, und die Seite funktioniert dann oft nicht mehr richtig. Für Skripte von fremden Servern empfiehlt sich zusätzlich Subresource Integrity: Ein Prüfwert im Attribut integrity stellt sicher, dass der Browser nur genau die erwartete Datei ausführt. Beides prüft der Mixed-Content- und SRI-Check.
Von der Note zum Maßnahmenplan
- Kritische Befunde zuerst. Sie begrenzen die Note und stehen meist für die größten Risiken.
- Nach Gewicht priorisieren. E-Mail-Schutz und Header bringen die meisten Punkte, security.txt die wenigsten. Die Datei ist aber in wenigen Minuten angelegt (RFC 9116); der security.txt-Check erstellt sie direkt im Browser.
- Änderungen einzeln einführen. CSP und DMARC zuerst beobachten (Report-Only beziehungsweise
p=none), dann durchsetzen. - Nach jeder Änderung erneut prüfen. Die Note ist eine Momentaufnahme: Zertifikate laufen ab, neue Plugins bringen neue Skripte.
- Zuständigkeiten klären. DNS, Webserver und E-Mail-Versand können bei drei verschiedenen Dienstleistern liegen. Halten Sie fest, wer welchen Eintrag pflegt.
Häufige Fragen
Ist eine Note B schlecht?
Nein. B bedeutet 70 bis 84 Punkte ohne kritischen Fehlschlag in einem Kernbereich: eine solide Basis mit Lücken, die sich gezielt schließen lassen. Der Bericht nennt die Befunde je Bereich, mit Erklärung und Beispielkonfiguration.
Warum steht meine Website auf C, obwohl die Punkte für B reichen?
Dann gibt es mindestens einen kritischen Befund in einem Kernbereich, zum Beispiel einen fehlenden DMARC-Eintrag oder ein Problem mit dem Zertifikat. Der Bericht führt ihn unter „Kritische Befunde“.
Wird meine Website dabei angegriffen?
Nein. Der Check ruft die Seite ab, wie es ein Besucher tut, und fragt öffentliche DNS-Einträge ab. Er sendet keine Angriffe und erzeugt keine Last. Ein Konto brauchen Sie nicht.
Wenn Sie die Befunde gemeinsam durchgehen oder umsetzen lassen möchten, helfen Ihnen die TOMORIS EXPERTS für Cyber Security.
Quellen
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), Mai 2026
- RFC 6797: HTTP Strict Transport Security (HSTS)
- W3C: Content Security Policy Level 3
- RFC 8996: Deprecating TLS 1.0 and TLS 1.1
- BSI TR-02102-2: Kryptographische Verfahren, Verwendung von TLS
- Mozilla: SSL Configuration Generator
- MDN: Set-Cookie
- OWASP Session Management Cheat Sheet
- § 165 TKG 2021 im RIS
- W3C: Mixed Content
- W3C: Subresource Integrity
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt)