Security Scan

Was der Security-Scan prüft — und was nicht

Geprüft werden die Sicherheitsangaben, die ein Server von sich aus mitschickt: ob HTTPS erzwungen wird, wie das Zertifikat aussieht, ob HSTS, Content-Security-Policy, X-Frame-Options und die übrigen Schutzkopfzeilen gesetzt sind. Dazu ein kleiner Satz Ports, die auf einem Webserver nichts zu suchen haben.

Ein Befund heißt nicht automatisch „angreifbar“. Eine fehlende Content-Security-Policy ist kein Loch, sondern eine fehlende Absicherung — sie macht andere Fehler gefährlicher, als sie sein müssten. Lies die Liste als Reihenfolge, nicht als Alarm.

Fehlt ein Header oder trägt er einen Wert, der nichts bewirkt, steht die Reihenfolge zum Nachziehen in Security-Header einrichten — mit Startwerten, fertiger Konfiguration für Apache, nginx und Netlify und dem Hinweis, welcher Header beim falschen Wert die eigene Seite aussperrt.

Dieser Scan ist ausschließlich beobachtend. Er ruft öffentliche Adressen ab und liest, was zurückkommt; er schickt keine Angriffslasten, testet nicht auf SQL-Injection oder XSS und verändert auf dem Ziel nichts. Das ist Absicht: aktive Tests gegen eine fremde Domain, deren Besitz niemand nachgewiesen hat, wären ein Angriff über unsere Infrastruktur. Wer echte Penetrationstests braucht, braucht einen Eigentumsnachweis — und ein anderes Werkzeug.