Kopfzeilen und Einbettung
Sicherheitskopfzeilen auf jeder Seite und Datei, eine wirksame Content-Security-Policy, geprüfte Fremdskripte (SRI) und klare Regeln für andere Domains (CORS).
10 Prüfpunkte
Schutz-Kopfzeilen fehlen
Mit ein paar Einstellungen am Server schützt man Besucher vor eingeschleusten Inhalten und unverschlüsselten Verbindungen.
Was zu tun ist: Ihr Hoster setzt die genannten Kopfzeilen am Webserver. Das erledigt eine Einstellung am Server.
Die Schutz-Kopfzeilen gelten nur auf der Startseite
Schutz wirkt nur dort, wo er gesetzt ist. Unterseiten, Dateien und die Fehlerseite bleiben ungeschützt.
Was zu tun ist: Ihr Hoster setzt die Kopfzeilen am Server für alle Antworten, statt sie in der Seitenvorlage zu hinterlegen.
Skripte und Dateien laufen ohne die Schutz-Kopfzeile
Die Startseite untersagt dem Browser, Dateitypen zu raten. Skripte und Stildateien kommen ohne diese Vorgabe; dort greift der Schutz nicht.
Was zu tun ist: Ihr Hoster setzt die Kopfzeile am Server für alle Antworten, nicht in der Seitenvorlage.
Die Schutzregel gegen fremde Skripte ist wirkungslos
Die Regel erlaubt Skripte aus beliebiger Quelle. Eingeschleuster Code läuft damit wie eigener, zum Beispiel um Eingaben abzugreifen.
Was zu tun ist: Ihre Agentur benennt die erlaubten Quellen einzeln und gibt eigene Skripte gezielt frei.
Die Schutzregel läuft seit langem nur im Probebetrieb
Im Probebetrieb meldet die Regel nur, was sie sperren würde, und lässt alles durch. Die Meldungen liest niemand, der Schutz greift nie.
Was zu tun ist: Ihre Agentur wertet die Meldungen aus, behebt die Treffer und stellt die Regel scharf.
Die Website sperrt eine eingebettete Funktion
Die Schutzregel der Website erlaubt die Adresse eines eingebetteten Formulars oder Fensters nicht. Besucher sehen eine leere Fläche oder können das Formular nicht absenden.
Was zu tun ist: Ihre Agentur nimmt die Adresse in die Schutzregel auf und ruft die Seite danach im Browser auf.
Die Freigabe für fremde Websites widerspricht sich
Der Server gibt jede fremde Website frei und erlaubt dazu Anmeldedaten. Browser lassen das nicht gelten: Anwendungen auf anderen Domains scheitern, sobald sie mit Anmeldung fragen, und ohne Anmeldung kann jede Seite die Antwort lesen.
Was zu tun ist: Ihre Agentur trägt nur die Adressen ein, die wirklich zugreifen dürfen, und erlaubt Anmeldedaten nur für diese.
Der Server erlaubt jeder anfragenden Seite den Zugriff
Der Server übernimmt jede fremde Herkunft, die anfragt, als erlaubt, samt Anmeldedaten. Die Freigabe wirkt wie eine Sperre, greift aber für jede fremde Seite.
Was zu tun ist: Ihre Agentur prüft die Herkunft gegen eine feste Liste erlaubter Adressen, statt sie ungeprüft zu übernehmen.
Fremde Dateien laden ohne Echtheitsprüfung
Skripte und Gestaltungsdateien von fremden Servern wirken auf Ihrer Seite wie eigene. Ändert jemand die Datei beim Anbieter, bekommen Ihre Besucher die geänderte Fassung.
Was zu tun ist: Ihre Agentur hinterlegt für jede fremde Datei eine Prüfsumme oder liefert die Datei vom eigenen Server aus.
Dateien kommen mit falscher Typangabe
Der Browser muss raten, was er bekommt. Neuere Browser blockieren solche Dateien, die Seite verliert Funktionen; Angreifer nutzen das Raten aus.
Was zu tun ist: Ihr Hoster trägt am Server den richtigen Dateityp je Endung ein und untersagt dem Browser das Raten.
