Website-Check
Sicherheit
Die Prüfung stellt fest, was Ihr Server von sich aus preisgibt oder erlaubt — sie nutzt nichts davon aus. Der Unterschied zwischen „die Tür steht offen" und „ich gehe hinein" ist die Grenze, die dieses Werkzeug nicht überschreitet. Genau deshalb läuft der Scan ohne Wartungsfenster und ohne Haftungsdiskussion. Was dieser Blick von außen nicht sieht — Aktualisierungen, Sicherungen, Konten, Rechte, Protokolle —, prüft die IT-Prüfung mit Zugang.
Was geprüft wird
52 Einzelprüfungen, gemeinsam mit dem Datenschutz in einem Lauf
-
Zugangsdaten im ausgelieferten Code
AWS-Schlüssel, private Schlüssel, Stripe-Live-Keys, GitHub- und Slack-Token, Datenbankpasswörter — alles, was versehentlich im Frontend landet. In der Praxis der häufigste echte Fund. Im Bericht steht jeder Treffer maskiert.
-
Transportverschlüsselung
HTTPS erreichbar, Weiterleitung von HTTP, Zertifikatslaufzeit und -gültigkeit, veraltete TLS-Versionen, gemischte Inhalte auf verschlüsselten Seiten.
-
Sicherheitsheader
HSTS, Content-Security-Policy einschließlich der Bewertung von unsafe-inline und Report-Only, X-Content-Type-Options, Referrer-Policy, Clickjacking-Schutz, Permissions-Policy — dazu die Cookie-Attribute Secure, HttpOnly und SameSite.
-
CORS-Fehlkonfiguration
Spiegelt der Server jeden anfragenden Ursprung zurück und erlaubt zugleich Cookies, kann jede fremde Seite im Browser eines angemeldeten Besuchers dessen Daten mitlesen. Eine Zeile Konfiguration, große Wirkung.
-
Fehlerseiten mit Stacktrace
Erkannt über den Aufruf eines erfundenen Pfades: Python, PHP, Java, .NET, Django, Laravel, Symfony, Rails und Node verraten in der Standardkonfiguration Pfade, Versionen und Programmstruktur.
-
Bekannte Schwachstellen und Versionspreisgabe
Erkannte Bibliotheksversionen werden gegen OSV.dev abgeglichen und lokal zwischengespeichert. Dazu: Versionsangaben in Headern und im generator-Tag, veraltete JavaScript-Bibliotheken, erkennbare WordPress-Plugins.
-
HTTP-Methoden
TRACE aktiviert, schreibende Methoden angeboten, wo nur gelesen werden sollte.
-
E-Mail- und DNS-Konfiguration
SPF einschließlich eines zu lax gesetzten ~all, DMARC, CAA und DNSSEC. Dazu verwaiste CNAME-Einträge als Risiko der Subdomain-Übernahme und eine robots.txt, die als Wegweiser zu nicht-öffentlichen Bereichen dient.
Nur mit ausdrücklicher Freigabe im Auftrag
Diese Prüfungen rufen 29 feste Pfade ab — mehr nicht, und nichts davon wird ausgenutzt. Weil es eine aktive Prüfung ist, steht sie ausdrücklich im Auftragstext und nicht im Kleingedruckten. Ohne die Freigabe läuft ausschließlich, was auch ein normaler Besucher auslöst.
- erreichbare /.git/ und /.env, /.htpasswd, /.vscode/sftp.json
- Datenbank-Abzüge, Logdateien und Backup-Dateien im Webverzeichnis
- /phpinfo.php und vergleichbare Diagnoseseiten
- WordPress-Benutzerliste, offene Datenbankverwaltung (phpMyAdmin, Adminer)
- Verzeichnisauflistung
Normen und Grundlagen
- OSV.dev als Quelle für Schwachstellen erkannter Bibliotheksversionen
- Abgleich von Sicherheitsheadern und TLS-Konfiguration gegen den heute üblichen Stand
- Risikowert als gewichtete Summe — ausdrücklich kein CVSS. Er taugt zum Vergleich zwischen Läufen derselben Domain, nicht als absolute Aussage
Was im Report steht
Jeder Lauf erzeugt zwei Dateien: einen eigenständigen HTML-Bericht für Sie und eine JSON-Datei als maschinenlesbare Grundlage. Der HTML-Bericht lädt keine einzige Ressource von fremden Servern — ein Datenschutzbericht, der beim Öffnen selbst Schriften nachlädt, wäre schwer zu erklären. Jeder Befund nennt Fundstelle, Beleg und konkrete Abhilfe.
Wo die Prüfung an ihre Grenze kommt
Geprüft wird die Startseite. Bereiche hinter einer Anmeldung sieht das Werkzeug nicht. Und es ist kein Penetrationstest: kein Fuzzing, keine eingeschleusten Eingaben, keine Anmeldeversuche, keine Lasttests, kein Ausnutzen gefundener Schwächen. Das braucht einen eigenen Vertrag samt Haftungsregelung. Was der Lauf findet, ist belastbar; was er nicht findet, ist kein Freispruch.
Häufige Fragen
Was Interessenten vor der Beauftragung am häufigsten wissen wollen.
Ist eine automatisierte Sicherheitsprüfung dasselbe wie ein Penetrationstest?
Nein. Eine automatisierte Prüfung arbeitet regelbasiert und wiederholbar: sie findet bekannte Schwachstellen, Fehlkonfigurationen und veraltete Komponenten zuverlässig und kann das täglich tun. Ein Penetrationstest ist die manuelle Arbeit eines Menschen, der Logikfehler, Rechteprobleme und verkettete Angriffe findet, auf die kein Regelwerk kommt. Beides ergänzt sich: die Automatisierung hält den Grundzustand sauber, damit der Penetrationstest nicht Zeit mit dem Offensichtlichen verbringt.
Brauchen Sie Zugangsdaten oder müssen wir Software installieren?
Nein. Die Prüfung läuft von außen gegen die öffentlich erreichbare Seite — es genügt die Domain und die schriftliche Freigabe. Kein Agent auf Ihren Servern, kein Zugriff auf den Quellcode, keine Zugangsdaten. Die Kehrseite steht ehrlich im Bericht: Was hinter einer Anmeldung liegt, sieht das Werkzeug damit auch nicht.
Stört die Prüfung den laufenden Betrieb?
Nein. Die Prüfung liest und misst, sie greift nicht an: keine ausgeführten Exploits, keine Lasttests, keine schreibenden Zugriffe. Die Anfragerate wird gedrosselt und lässt sich auf Ihre Umgebung abstimmen, und der Lauf kann in ein Zeitfenster gelegt werden. Falls Ihr Schutzsystem den Prüfer trotzdem blockiert, ist auch das ein verwertbares Ergebnis — dann wird die Prüfquelle freigegeben, damit der Lauf die Anwendung und nicht die Firewall misst.
Wie oft sollte eine Sicherheitsprüfung laufen?
So oft, wie sich die Seite ändert. Ein Zertifikat läuft ab, eine Bibliothek bekommt eine neue Schwachstelle, ein Deployment setzt einen Header zurück — das passiert zwischen zwei jährlichen Audits. In der Praxis bewährt sich ein monatlicher Lauf als Grundtakt, ergänzt um einen Lauf nach jedem größeren Release. Ein automatischer Vergleich zweier Läufe ist in Arbeit, heute stellen wir die Veränderung beim Durchsehen der Berichte fest.
Wovon hängt der Aufwand ab?
Vom Umfang und davon, welche der drei Profile Sie brauchen. Sicherheit und Datenschutz laufen gemeinsam, Auffindbarkeit und Barrierefreiheit jeweils für sich; die erweiterte Barrierefreiheitsstufe braucht vier Browserdurchläufe statt einem. Dazu kommt die Zahl der Domains. Der Aufwand steckt im Aufsetzen und in der Durchsicht der Berichte, nicht im Rechenlauf — genau deshalb ist regelmäßiges Prüfen überhaupt wirtschaftlich.