Was Sondar prüft

Prüft Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options und verwandte Kopfzeilen auf fehlende oder schwache Direktiven.

Diese Header sind die erste Verteidigungslinie des Browsers gegen XSS, Clickjacking und MIME-Sniffing. Fehlen sie, greifen Angriffe, die der Browser sonst selbst abwehren würde.

Kontrolliert Gültigkeit und Laufzeit des Zertifikats, die angebotenen Protokollversionen und die Verschlüsselungskonfiguration Ihrer HTTPS-Verbindung.

Ein abgelaufenes Zertifikat oder veraltete Protokolle wie TLS 1.0 untergraben genau die Verschlüsselung, auf die sich Ihre Besucher verlassen — und lösen im Browser Warnungen aus, die Vertrauen kosten.

Liest die öffentlichen DNS-Einträge Ihrer Domain und prüft den E-Mail-Absenderschutz: SPF, DMARC und DKIM-Hinweise sowie CAA-Einträge.

Ohne SPF und DMARC kann jede beliebige Person E-Mails im Namen Ihrer Domain versenden. Das ist der häufigste Hebel für Phishing gegen Ihre Kunden — und schadet Ihrer Zustellbarkeit.

Sucht gezielt nach versehentlich öffentlichen Pfaden: .env, .git/, Backups, Datenbank-Dumps und Konfigurationsdateien.

Eine öffentlich erreichbare .env enthält oft Datenbank-Passwörter und API-Schlüssel im Klartext. Ein offenes .git/-Verzeichnis gibt Ihren gesamten Quellcode preis.

Prüft die vom Server gesetzten Cookies auf die Schutz-Attribute Secure, HttpOnly und SameSite.

Ohne HttpOnly kann ein XSS-Angriff das Session-Cookie auslesen und das Konto übernehmen. Ohne Secure wandert es auch über unverschlüsselte Verbindungen.

Bewertet nicht nur, OB eine Content-Security-Policy da ist, sondern wie gut: unsafe-inline/eval, Wildcards, fehlendes object-src/base-uri/frame-ancestors.

Eine CSP zu haben heisst nicht, geschützt zu sein — viele Policies sind so lasch, dass sie den XSS-Schutz praktisch aufheben.

Geht über die Basis hinaus: TLS-1.3-Unterstützung, Forward Secrecy, AEAD- statt CBC-Cipher, Schlüsselstärke des Zertifikats.

Eine veraltete Verschlüsselungskonfiguration lässt sich unterwegs schwächen oder aufzeichnen — auch mit gültigem Zertifikat.

Erkennt eingesetzte Software (Server, CMS, Frameworks, JS-Bibliotheken) und deren Version und gleicht sie gegen bekannte veraltete Stände ab.

Veraltete Komponenten sind der häufigste Einbruchsweg — für bekannte Lücken existiert oft fertiger Angriffscode.

Prüft eingebundene Fremd-Skripte auf Subresource Integrity (SRI) und die Seite auf Mixed Content (HTTP-Ressourcen auf HTTPS).

Wird ein Fremd-Anbieter kompromittiert, läuft dessen Schadcode ohne SRI direkt auf Ihrer Seite — ein Supply-Chain-Angriff.

Sucht ausführliche Fehler/Stacktraces, verräterische Versions-Header, interne IP-Adressen und mögliche Personendaten im Klartext.

Solche Details verraten Angreifern die interne Struktur — offen liegende Personendaten sind zudem nach revDSG heikel.

Prüft, ob die Domain per CNAME auf einen Cloud-Dienst zeigt, der dort nichts mehr betreibt (verwaister Eintrag).

Wer den freien Namen beim Anbieter registriert, kann beliebigen Inhalt unter Ihrer Domain ausliefern — inklusive gültigem Zertifikat.

Erkennt offen einsehbare Verzeichnisindizes („Index of /") an typischen Pfaden.

Eine offene Liste zeigt Dateinamen und Struktur, die nicht öffentlich sein sollten — oft inklusive Backups.

Fragt ab, welche HTTP-Methoden der Server erlaubt, und warnt vor gefährlichen (PUT/DELETE/TRACE) — ohne sie auszuführen.

Eine offene PUT-Methode kann bedeuten, dass sich Dateien auf den Server schreiben lassen — bis hin zur Übernahme.

Ergänzt die Cookie-Prüfung um __Host-/__Secure-Prefixes und einen zu weit gefassten Domain-Scope.

Ein zu weit gefasstes Cookie kann von einer kompromittierten Subdomain gelesen oder gesetzt werden.

Liest Ihre Cross-Origin-Regeln aus und meldet, wenn sie zu grosszügig gesetzt sind und fremden Seiten Zugriff auf Ihre Daten erlauben.

Eine zu offene CORS-Regel lässt beliebige fremde Websites im Namen eingeloggter Besucher Ihre API abfragen und deren Daten auslesen — ohne dass die Betroffenen etwas merken.

Wertet robots.txt und sitemap.xml aus: veröffentlichte Verwaltungs- oder Staging-Bereiche, Einträge auf http:// statt https://, tote Adressen — und was ein Disallow-Eintrag ungewollt verrät.

Beide Dateien sind die Landkarte Ihrer Website. Sie sollen existieren — nur verraten sie manchmal mehr als gewollt. Ein Disallow-Eintrag hält höfliche Suchmaschinen fern, aber niemanden sonst: für einen Angreifer ist er ein Wegweiser.

Weist SQL-Injection nach — über Datenbank-Fehlermeldungen und differenzielle Antworten. Nur Nachweis, kein Datenabzug.

Über eine SQL-Injection lassen sich Kundendaten, Passwörter und Bestellungen auslesen — der folgenreichste Web-Fehler überhaupt.

Sendet einen eindeutigen, harmlosen Marker in Parametern und Formularfeldern und prüft, ob er ungefiltert in der Antwort landet.

Landet Nutzereingabe ungefiltert im HTML, kann eine Angreiferin darüber Schadcode im Browser Ihrer Besucher ausführen — Sessions übernehmen, Eingaben mitlesen, die Seite umschreiben.

Prüft Weiterleitungsparameter darauf, ob sie sich auf ein beliebiges fremdes Ziel umlenken lassen.

Ein offener Redirect auf Ihrer Domain lässt Phishing-Links echt aussehen: Das Opfer sieht Ihre vertraute Adresse, landet aber auf der Seite der Angreiferin. Ein klassischer Vertrauensmissbrauch.

Prüft, ob Eingaben unverändert in CSV- oder Excel-Exporte gelangen und dort zu ausführbaren Formeln werden können.

Öffnet jemand den Export in Excel, führt eine eingeschleuste Formel Befehle auf dem Rechner der auswertenden Person aus — ein Angriff, der gerade Ihre eigenen Mitarbeitenden trifft.

Prüft Kontakt- und Anmeldeformulare darauf, ob sich über Eingabefelder zusätzliche E-Mail-Header einschleusen lassen.

Gelingt das, wird Ihr Kontaktformular zur Spam-Schleuder: Angreiferinnen versenden über Ihren Server Mails an Dritte — auf Kosten Ihrer Domain-Reputation und Zustellbarkeit.