Moderne Webapplikationen verwenden Inhalte aus einer Vielzahl Quellen: Schriften von Google, JavaScript und CSS aus verschiedenen CDNs, und viele weitere. Dies ist zwar an sich kein Problem, aber es wird zur Herausforderung, wenn man nicht die volle Kontrolle über die in der App eingebetteten Inhalte hat.

Nehmen wir an, Sie sind unterwegs mit der Mission, den besten Website-Baukasten der Welt zu erstellen. Um Ihren Benutzern ein Höchstmaß an Flexibilität bei der Gestaltung ihrer neuen Website zu bieten, erlauben Sie ihnen, Inhalte von Drittanbietern von jeder beliebigen Website aus einzufügen. Bei der Implementierung eines entsprechenden Embed-Widgets stellen Sie fest, dass Sie JavaScript-Quellen von Dritten untersagen wollen.

Nun könnten Sie den harten Weg gehen und versuchen, den eingebetteten Inhalt, den der Benutzer eingegeben hat, zu parsen und bestimmte Eingaben zu verbieten. Ein umständliches und fehleranfälliges Unterfangen. Hier setzt die Content Security Policy (CSP) an und hilft, die Ressourcen zu definieren, die auf der Website geladen werden dürfen.

CSP ist ein HTTP-Response-Header und kann alternativ als HTML-Meta-Element verwendet werden. Wir beginnen mit einem einfachen Beispiel und lassen nur JavaScript-Quellen von unserer Site zu; also nur diejenigen, die vom gleichen Ursprung wie die aktuelle Site stammen. Der Wert für den "Content-Security-Policy"-Header würde so aussehen: "script-src 'self';". Inhalte, die aus anderen Quellen stammen, werden vom Webbrowser des Benutzers nicht geladen.

Andere Richtlinien legen die erlaubten Quellen für Stile, Bilder, Schriftarten, Medien oder Frames fest. Die Quellen können mit wörtlichen Domänennamen, Platzhaltern, Nicht-Zeichen oder Hashes angegeben werden. Und es sind noch mehr Direktiven und Quellen verfügbar. Eine ziemlich nützliche Direktive erlaubt zum Beispiel die Angabe einer Berichts-URI, an die Verstöße gesendet werden.

Eine etwas spezielle Direktive ist "frame-ancestors". Sie legt die gültigen Quellen fest, aus denen eine Site eingebettet werden kann. Sie ist verwandt mit dem "X-Frame-Options" HTTP-Header, umgeht aber einige seiner Unzulänglichkeiten.

Wenn Sie Ihre Webanwendung sichern und die volle Kontrolle über die geladenen Ressourcen haben wollen, sollten Sie auf jeden Fall tiefer in die CSP-Dokumentation eintauchen. MDN bietet eine nützliche Einführung unter https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP und https://content-security-policy.com/ listet alle möglichen Direktiven und Quellen mit Erklärungen und Beispielen auf.