Generador de Content Security Policy (CSP)

Com crear una política

1. Tria un punt de partida a Comença amb una plantilla: Estricta (nonce + strict-dynamic), Lloc estàtic molt restringit, Lloc web típic o Típic + Google Analytics / Ads. L’editor s’obre amb la plantilla del lloc web típic.
2. Ajusta les Directives. Cada camp admet fonts separades per espais; si el deixes buit, la directiva s’omet.
3. Amb Afegeix ràpidament pots afegir una paraula clau a la Directiva triada: 'self', 'none', 'unsafe-inline', 'strict-dynamic', https:, data:… Afegeix un nonce hi insereix un nonce aleatori de 128 bits.
4. Per permetre un script en línia concret sense 'unsafe-inline', enganxa’l (o l’HTML que l’envolta) a Calcula el hash d’un script o estil en línia i fes clic a Calcula el SHA-256 i afegeix.
5. Marca upgrade-insecure-requests si encara tens URL antigues amb http://, i si vols, indica una URL del punt de recepció d’informes (opcional).
6. Copia la Capçalera HTTP, la Capçalera Report-Only (prova sense bloquejar) o l’Etiqueta HTML . La Revisió d’aquesta política s’actualitza mentre escrius.

Per auditar una política que ja tens, enganxa-la a Avalua una política existent i fes clic a Avalua la política; Carrega a l’editor la copia als camps.

Tot funciona al teu navegador: la política que escrius o enganxes no s’envia a cap servidor.

Què fa una Content Security Policy

Una CSP indica al navegador de quins orígens pot carregar una pàgina scripts, estils, imatges, tipus de lletra, marcs i connexions. La seva funció principal és limitar els atacs de cross-site scripting (XSS): encara que un atacant injecti codi a la teva pàgina, una bona política impedeix que l’script injectat s’executi. També controla qui pot incrustar la teva pàgina (frame-ancestors), on es poden enviar els formularis (form-action) i a què pot apuntar <base> (base-uri).

Les directives de càrrega, com img-src o font-src, recorren a default-src quan falten. En canvi, base-uri, form-action i frame-ancestors no ho fan, i per això la revisió te les demana explícitament.

Nonces, hashes i strict-dynamic

Permetre servidors concrets (script-src https://cdn.example.com) sembla segur, però sovint es pot eludir: els dominis grans allotgen punts finals JSONP i biblioteques antigues que un atacant pot reutilitzar. L’enfocament que recomanen els equips de seguretat dels navegadors és una CSP estricta: cada <script> legítim porta un nonce que el servidor genera a cada resposta, o bé es permet pel seu hash, i 'strict-dynamic' deixa que aquests scripts de confiança carreguin els que necessiten. En aquest esquema, https: i 'unsafe-inline' només són una reserva per a navegadors molt antics; els moderns les ignoren.

Un nonce només funciona si canvia a cada resposta i és impredictible. El que insereix Afegeix un nonce és només un exemple: el teu servidor o framework n’ha de generar un de propi. Un hash cobreix els bytes exactes del codi en línia, de manera que si reformates l’script, en necessites un de nou.

Capçalera, Report-Only i etiqueta meta

Sempre que puguis, envia la política com a capçalera de resposta HTTP. Desplega-la primer com a Content-Security-Policy-Report-Only: els navegadors informen de les violacions (a la consola i, si n’has definit un, al teu punt de recepció) sense bloquejar res, i així pots arreglar les pàgines abans d’aplicar-la. Els paràmetres d’informes afegeixen report-uri per als navegadors antics i report-to amb una capçalera Reporting-Endpoints.

La versió amb <meta http-equiv> va bé en allotjaments estàtics, però els navegadors hi ignoren frame-ancestors, report-uri, report-to i sandbox, i no existeix cap etiqueta meta Report-Only. L’eina treu aquestes directives de l’etiqueta i t’ho indica.