Content-Security-Policy Schritt für Schritt

Eine Content-Security-Policy ist die wirksamste einzelne Maßnahme gegen eingeschleuste Skripte. Sie sagt dem Browser, aus welchen Quellen eine Seite Skripte, Stile, Bilder und Verbindungen laden darf — alles andere wird nicht ausgeführt. Der Nutzen ist groß, das Risiko beim Einführen ebenfalls: Eine zu eng gefasste Regel bricht die Seite, und zwar erst beim Nutzer.

##Was verhindert eine CSP?

Wenn es einem Angreifer gelingt, fremdes Skript in eine Seite einzuschleusen, führt der Browser es aus — mit den Rechten der Seite. Eine wirksame CSP führt es nicht aus, weil seine Quelle nicht in der Erlaubnisliste steht. Das gilt auch dann, wenn die Eingabeprüfung an anderer Stelle versagt: Die CSP ist die zweite Verteidigungslinie und die einzige, die im Browser selbst greift.

##Warum wird sie selten in einem Schritt eingeführt?

Eine Seite besteht selten nur aus eigenem Code. Analysewerkzeuge, Karten, Chat-Widgets, Zahlungsanbieter und Schriftdienste laden eigene Skripte und Stile. Wer die CSP scharf schaltet, ohne diese Quellen zu kennen, sperrt sie aus — und merkt es oft erst, wenn die Kasse nicht mehr funktioniert.

##Wie sehen die drei Stufen aus?

Stufe eins: Report-Only mit einer konservativen Richtlinie ausliefern und die Meldungen sammeln. Stufe zwei: die gemeldeten Quellen ergänzen, bis nur noch echte Fehler auftauchen — das sind die Fälle, die man wirklich beheben muss. Stufe drei: denselben Wert als durchsetzenden Header senden.

• ›default-src 'self' — der Ausgangspunkt; alles, was nicht ausdrücklich erlaubt ist, fällt darunter.
• ›script-src — die wichtigste Direktive; hier entscheidet sich, ob die CSP wirkt.
• ›style-src, img-src, font-src — je nach eingesetzten Diensten.
• ›connect-src — wohin die Seite Daten senden darf; wird bei Formularen und Analysen oft vergessen.
• ›frame-ancestors 'none' — verhindert, dass die Seite in einem fremden Rahmen erscheint.
• ›base-uri und form-action einschränken — sie schließen Wege, die sonst offen bleiben.

##Warum ist 'unsafe-inline' der Stolperstein?

Sobald 'unsafe-inline' im script-src steht, ist die Wirkung praktisch aufgehoben — jedes eingeschleuste Inline-Skript läuft dann wieder. Der saubere Weg sind Nonces: Ein zufälliger Wert pro Anfrage wird gleichzeitig in den Header und in die eigenen Inline-Skripte geschrieben. Fremdes Skript kennt das Nonce nicht und wird nicht ausgeführt.

Das setzt voraus, dass die Seite bei jeder Anfrage serverseitig gerendert wird, oder dass konsequent auf Inline-Skripte verzichtet wird. Beides ist eine Architekturentscheidung, und sie fällt leichter, wenn sie früh fällt: Nachträglich ein Nonce in eine gewachsene Seite zu ziehen, ist deutlich aufwendiger als es von Anfang an mitzuführen.

##Was leistet eine CSP nicht?

Eine CSP ersetzt keine Eingabeprüfung, keinen aktuellen Server und keine Sorgfalt im Umgang mit Zugangsdaten. Sie verhindert, dass eingeschleuster Code läuft — sie verhindert nicht, dass er eingeschleust wird. Und sie schützt nicht vor Angriffen, die auf dem Server stattfinden, etwa über eine unsichere Abhängigkeit. Sie ist eine Schicht, keine Lösung.

##In welcher Reihenfolge führen Sie sie ein?

Führen Sie die CSP nicht während eines Projekts ein, sondern danach und in einem eigenen Schritt mit eigenem Zeitfenster. Melden Sie die Verstöße an einen Endpunkt, den Sie tatsächlich auswerten — ein Berichtsziel, das niemand liest, ist kein Monitoring, sondern Rauschen. Und halten Sie die Richtlinie kurz: Eine CSP mit zwanzig Ausnahmen ist schwer zu pflegen und wird beim nächsten Umbau still aufgeweicht.