Was ein Security-Check prüft, und was nicht

Sie schicken uns die Adresse Ihrer Website. Wir lesen, was jeder Browser und die öffentlichen DNS-Einträge zeigen, und sehen uns fünf Bereiche an.

HTTPS und TLS samt Zertifikat. Unverschlüsselte Daten können Dritte abfangen, lesen und verändern, warnt MDN in seinem TLS-Leitfaden. HSTS weist den Browser an, die Seite nur noch über HTTPS aufzurufen, und lässt Zertifikatsfehler nicht mehr wegklicken. Für das max-age empfiehlt MDN mindestens sechs Monate, besser zwei Jahre. RFC 8996 hat TLS 1.0 und 1.1 im Jahr 2021 für veraltet erklärt. Nach einem Beschluss des CA/Browser Forum vom April 2025 sinkt die maximale Laufzeit von Zertifikaten zwischen März 2026 und März 2029 schrittweise von 398 auf 47 Tage. In diesem Tempo muss das Erneuern automatisch laufen.

Security-Header. Das sind Anweisungen, die Ihr Server mit jeder Seite mitschickt. Eine Content Security Policy legt fest, welche Skripte eine Seite laden darf, vor allem als Schutz gegen Cross-Site-Scripting, und ihre Direktive frame-ancestors schützt gegen Clickjacking. X-Content-Type-Options verbietet dem Browser, Dateitypen zu erraten. Referrer-Policy begrenzt, was andere Seiten darüber erfahren, woher ein Besuch kommt.

Software- und Plugin-Versionen, die jeder sehen kann. Ältere Versionen ohne aktuelle Sicherheitspatches können laut OWASP-Testleitfaden für bekannte, versionsspezifische Angriffe anfällig sein. Die Versionsnummer zu verstecken, behebt das nicht. Das Update schon.

Mail-Einträge. SPF listet die Server, die Mails für Ihre Domain verschicken dürfen. DMARC sagt Empfängern, was mit Mails passieren soll, die diese Prüfungen nicht bestehen. DKIM signiert jede Nachricht. Der Schlüssel liegt aber unter einem Selektor-Namen, den man kennen oder finden muss, deshalb sehen wir uns DKIM an, sofern auffindbar. Google verlangt seit 1. Februar 2024 von allen Absendern SPF oder DKIM, und DMARC von allen, die mehr als 5.000 Nachrichten am Tag an Gmail schicken.

Login-Seiten, die jeder erreicht. OWASP nennt /admin, wp-admin/ und /phpmyadmin/ als typische Adressen. Wir notieren, welche davon für jeden aufgehen. Login-Versuche unternehmen wir keine.

Wir starten nichts, was Ihre Seite bremsen oder stören könnte, und brauchen von Ihnen keinen Zugang, kein Passwort und kein Plugin. Innerhalb von 3 Werktagen bekommen Sie die 5 wichtigsten Befunde schriftlich, jeden mit dem, was er für Sie bedeutet und wie er sich beheben lässt. Ein Verkaufsgespräch gibt es nur, wenn Sie eines möchten.

1. Das HTTP Observatory aufrufen. Geben Sie Ihre Domain im HTTP Observatory von MDN ein. Es bewertet Header, Cookies und die Weiterleitung auf HTTPS und verlinkt zu jedem Problem eine Anleitung. Laut FAQ ist der Verlauf aller Prüfungen einer Domain öffentlich. Dieselbe FAQ sagt klar, dass das Werkzeug weder veraltete Software noch SQL-Injection noch verwundbare CMS-Plugins prüft. Ein A+ heißt also: Ihre Header passen. Über Zertifikat und Plugins sagt es nichts.

2. Die Mail-Einträge abfragen. Das funktioniert unter Windows, macOS und Linux:

nslookup -type=TXT example.at
nslookup -type=TXT _dmarc.example.at

In der ersten Antwort suchen Sie genau einen Eintrag, der mit v=spf1 beginnt. Einen zweiten verbietet RFC 7208. Am Ende steht idealerweise -all, dann gilt Mail von anderen Servern als nicht berechtigt, oder ~all, ein "softfail": wahrscheinlich nicht berechtigt. Der Eintrag darf insgesamt höchstens 10 DNS-Abfragen auslösen. Jedes include:, a, mx, ptr, exists und redirect= zählt mit, auch in den Einträgen, die Sie per include: einbinden. Bei mehr lautet das Ergebnis "permerror".

Die zweite Antwort sollte mit v=DMARC1 beginnen. p=none verlangt von Empfängern nichts. Das ist ein guter Anfang, und Google akzeptiert es auch bei großen Versendern. Mit p=quarantine gelten durchgefallene Mails als verdächtig. Mit p=reject gelten sie als unzulässige Nutzung Ihrer Domain, und Empfänger können sie schon bei der Zustellung abweisen. Empfiehlt eine Anleitung noch pct=, folgt sie dem älteren RFC 7489. RFC 9989 vom Mai 2026 löst ihn ab, streicht pct und führt dafür einen Testmodus t=y ein.

Für DKIM schicken Sie eine Mail an ein zweites Postfach und öffnen dort die vollständigen Kopfzeilen. In Gmail heißt das "Original anzeigen" im Menü der Nachricht und zeigt auch gleich, ob DKIM bestanden hat. Die Zeile DKIM-Signature nennt einen Selektor (s=) und eine Domain (d=). Bei s=mail und d=example.at fragen Sie nslookup -type=TXT mail._domainkey.example.at ab. Die Antwort sollte p= und danach einen langen Schlüssel enthalten. Ein leeres p= heißt: Der Schlüssel wurde widerrufen.

3. Die eigene Admin-Seite im privaten Fenster öffnen. Rufen Sie https://www.example.at/wp-admin/ auf, oder die Adresse, unter der Ihr Backend liegt. Lädt das Login-Formular für jeden, folgen Sie dem WordPress-Handbuch zur Härtung: Zwei-Faktor-Anmeldung einschalten und Core und Plugins aktuell halten, denn ältere WordPress-Versionen bekommen keine Sicherheitsupdates mehr. Braucht nur Ihr Team das Backend, setzen Sie wie im Handbuch empfohlen ein zusätzliches Passwort auf Serverebene vor /wp-admin/. Lassen Sie dabei wp-admin/admin-ajax.php frei, denn laut Handbuch kann eine Sperre des ganzen Ordners Funktionen stören, die diese Datei nutzen. Oder Sie lassen Ihren Hoster nur die IP-Adresse Ihres Büros zulassen. Genau das prüft auch OWASP.

Der Security-Check geht über das hinaus, was jeder sehen kann: Web-Apps, Server und Konten. Dafür brauchen wir zuerst Ihre schriftliche Freigabe. Ein unterschriebener Umfang nennt die Systeme, die wir prüfen dürfen, und Sie bestätigen, dass sie Ihnen gehören. Ohne beides fangen wir nicht an. Daten, die Sie uns geben, bleiben unter einer Datenschutzvereinbarung.

Dann prüfen wir, was offen erreichbar ist, was veraltet ist und wo Zugriffe weiter gefasst sind als nötig. Beim letzten Punkt setzt auch die WKO an. Unter ihren Basismaßnahmen steht: Das Unternehmen "hat Zugriffe auf Dateien und Programme auf das erforderliche Ausmaß reduziert".

Auf der Seite zum Security-Check sehen Sie einen Beispielbericht: HTTPS und TLS 1.3 OK, Security-Header 4 von 6, WordPress-Core aktuell, 2 Plugins veraltet, 2FA für Admin-Zugänge aktiv, Wiederherstellung der Backups getestet. Das ist ein Beispiel, kein echtes Kundenergebnis.

• Alle Domains, die Sie nutzen, auch die Mail-Domain, falls sie von der Website abweicht.
• Ihre Server und wo sie laufen: Hoster, Hosting-Panel, wer den Login hat.
• Web-Apps und Plugins samt Versionen. Die WKO-Basismaßnahmen nennen ein aktuelles Verzeichnis der Geräte und Anwendungen, die OWASP Top 10:2025 eine laufende Inventur aller Komponenten-Versionen.
• Wer worauf Admin-Zugriff hat, auch ehemalige Mitarbeiter:innen und Agenturen.
• Datum und Ergebnis der letzten Wiederherstellung, nicht nur des letzten Backups. Das deutsche BSI rät, Backups "regelmäßig auf Funktionalität, Konsistenz und Aktualität" zu testen.
• Frühere Berichte oder Befunde. Das britische NCSC rät, eine aktuelle Schwachstellenbewertung schon bei der Festlegung des Umfangs zu teilen.
• Die Person, die den Umfang unterschreiben darf.

Die Befunde kommen nach Risiko gereiht, in klarer Sprache, mit den Maßnahmen, die wir zuerst setzen würden. Das NCSC erwartet für jeden Befund eine Einstufung des Schweregrads. Laut OWASP soll ein Bericht der Geschäftsführung zeigen, wo wesentliche Risiken liegen, und hohe und mittlere Risiken lassen sich vorrangig beheben.

Nicht jeder ernste Befund ist schwer zu beheben. MDN bewertet jeden seiner Sicherheitsleitfäden nach Wirkung und Aufwand. Eine Auswahl, in der von MDN empfohlenen Reihenfolge:

Die ersten vier Zeilen bringen am meisten für den geringsten Aufwand. Eine CSP dauert länger, weil darin jedes Skript und jede Einbindung der Seite erlaubt sein muss. Eine fehlende Referrer-Policy wiegt weniger schwer, als es aussieht: Ohne eigene Angabe verwenden Browser ohnehin strict-origin-when-cross-origin. SPF und DMARC sind meist Änderungen im DNS. Ein veraltetes Plugin ohne Update ist eine größere Entscheidung: ersetzen, reparieren lassen oder das Risiko bewusst tragen.

Das NCSC sagt es deutlich: Risikobewertung und die Entscheidung über Korrekturen liegen in Ihrer Verantwortung. Sie entscheiden auch, wer was behebt: Sie selbst, Ihre Agentur oder wir.

Kein Zertifikat. Wir stellen keine Gütesiegel, akkreditierten Zertifikate oder Compliance-Bestätigungen aus, und Projekte zu ISO-Normen oder NIS2 übernehmen wir nicht.

Keine Garantie. Das NCSC vergleicht einen Penetrationstest mit einer Wirtschaftsprüfung, also einer Prüfung von außen, ob Ihre eigenen Abläufe greifen. Ein solcher Test kann laut NCSC nur bestätigen, dass Ihre Systeme am Tag des Tests nicht für bekannte Probleme anfällig waren. OWASP ergänzt, ein Penetrationstest finde nur eine kleine, repräsentative Auswahl aller möglichen Risiken. Was für einen Penetrationstest gilt, gilt für jede Prüfung.

Kein Ersatz fürs Patchen. Ein Check findet das veraltete Plugin, schließen kann die Lücke nur das Update. Der achte Tipp des BSI für Unternehmen lautet "Patchen, patchen, patchen!". Was das für eine WordPress-Seite heißt, zeigt unser Leitfaden zum Ende von PHP 8.2.

Starten Sie mit dem kostenlosen Website-Check: Website-Adresse schicken und binnen 3 Werktagen die 5 wichtigsten Befunde bekommen. Für Web-Apps, Server und Konten mit unterschriebenem Umfang fragen Sie den Security-Check an. Die Härtung schließt, was ein Check findet: Update- und Patch-Routinen, TLS und Security-Header, Zugriffe nach dem Minimalprinzip, Zwei-Faktor-Logins, Backups, die mindestens einmal wiederhergestellt wurden, und Monitoring. Mit Wartung testen wir Updates zuerst auf einer Kopie, Ihre Seite meldet Fehler an unser eigenes Error-Monitoring (GlitchTip), und Sie bekommen regelmäßig einen schriftlichen Bericht.

Ist schon etwas passiert, lesen Sie Hilfe nach einem Vorfall. Nichts löschen und kein altes Backup einspielen, solange die Lücke offen ist. Ist es dringend, rufen Sie uns unter +43 7235 233 85 an. Wir heben Montag bis Freitag von 8:00 bis 15:00 Uhr ab, Samstag und Sonntag von 9:00 bis 12:00 Uhr. Sonst schreiben Sie uns über das Kontaktformular, wir antworten meist innerhalb eines Werktags.