# Content-Security-Policy ora utilizza 'strict-dynamic'

**URL:** https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172
**Category:** Announcements
**Created:** [7 Marzo 2024, 3:24pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172 "2024-03-07T15:24:39Z")
**Posts on this page:** 14
**Page:** 1

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [7 Marzo 2024, 3:24pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/1 "2024-03-07T15:24:39Z")

</div>

Da `v3.3.0.beta1`, Discourse implementa una Content Security Policy (CSP) ‘strict-dynamic’. Questo eliminerà la necessità di configurazioni CSP manuali e migliorerà notevolmente la compatibilità con strumenti esterni come tag manager e pubblicità.

In qualità di amministratore del sito, **non è necessario fare nulla**. La modifica avrà effetto automaticamente e gli script esterni che stai utilizzando continueranno a funzionare.

Non sono richieste modifiche per i temi. Un piccolo numero di plugin \[1\] potrebbe necessitare di una piccola modifica per la compatibilità con questa modifica (ad esempio, [1](https://github.com/discourse/discourse-client-performance/commit/31b6a21f26), [2](https://github.com/paviliondev/discourse-multilingual/commit/7ab8a6bb2c)).

I forum che in precedenza avevano disabilitato la CSP per compatibilità con script esterni dovrebbero ora essere in grado di riattivarla senza problemi o sforzi di configurazione.

Per i dettagli tecnici, consulta questo argomento:

> [@(Superseded) Experimenting with a 'strict-dynamic' Content Security Policy (CSP)](https://meta.discourse.org/t/experimenting-with-a-strict-dynamic-content-security-policy-csp/295603):
>
> We’re experimenting with a new ‘strict-dynamic’ CSP, which should make it much easier to integrate themes, plugins and external scripts with Discourse in a secure way. You can try out the new mode by enabling the ‘content security policy strict dynamic’ site setting. Please let us know if you have any feedback! We hope to make this the default in the near future, and will make an #announcements topic as we get closer to that goal. For more information, see below: scroll Background [Back in …](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243)

Per ora, è ancora possibile tornare al vecchio sistema disabilitando l’impostazione del sito ‘content security policy strict dynamic’. Se hai qualche motivo per farlo, faccelo sapere!

* * *

Da `v3.3.0.beta3`, abbiamo reso la parola chiave ‘strict-dynamic’ una parte obbligatoria della nostra CSP. L’impostazione del sito ‘content security policy strict dynamic’ è stata rimossa e l’impostazione del sito ‘content security policy script src’ è stata aggiornata per memorizzare solo valori validi.

Per gli amministratori, dovresti essere in grado di trovare il valore precedente dell’impostazione del sito ‘content security policy script src’ dai log delle azioni dello staff del tuo sito (`https://<URL_DEL_TUO_SITO>/admin/logs/staff_action_logs?filters=%7B%22action_name%22%3A%22change_site_setting%22%2C%22action_id%22%3A3%2C%22subject%22%3A%22content_security_policy_script_src%22%7D` - Sostituisci `<URL_DEL_TUO_SITO>` con l’URL di base del tuo sito).

* * *

1. tecnicamente: quelli che introducono elementi `<script>` tramite `register_html_builder` o un template `erb`

---

<div class="post-metadata">

### Author: ![haozi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/haozi/32/381818_2.png) [@haozi](https://meta.discourse.org/u/haozi)
#### Post date: [13 Maggio 2024, 3:53am UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/2 "2024-05-13T03:53:27Z")

</div>

Come posso configurare `'unsafe-eval'` dopo questa modifica come prima?

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [13 Maggio 2024, 8:55am UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/3 "2024-05-13T08:55:00Z")

</div>

Nessuna modifica lì: puoi ancora aggiungere ‘unsafe eval’ ( **con le virgolette** ) all’impostazione del sito `content security script src`.

---

<div class="post-metadata">

### Author: ![haozi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/haozi/32/381818_2.png) [@haozi](https://meta.discourse.org/u/haozi)
#### Post date: [13 Maggio 2024, 1:20pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/4 "2024-05-13T13:20:32Z")

</div>

Ho visto che la descrizione dell’impostazione `content security script src` afferma che l’abilitazione di `content_security_policy_strict_dynamic` ignorerà questa impostazione, quindi sono venuto qui per consultare.

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [13 Maggio 2024, 1:22pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/5 "2024-05-13T13:22:23Z")

</div>

La descrizione dice

> Le origini host verranno ignorate quando content\_security\_policy\_strict\_dynamic è abilitato.

La parte importante lì è “origini host”. ‘unsafe-inline’ non è un’origine host, quindi è ancora supportato.

Detto questo, sono totalmente d’accordo che questo sia confuso. Dato il successo del rollout di strict-dynamic, abbiamo in programma di rimuovere il vecchio sistema. Una volta fatto ciò, potremo rimuovere automaticamente tutte le origini host dall’elenco e le cose saranno molto più semplici per gli amministratori. 🚀

---

<div class="post-metadata">

### Author: ![haozi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/haozi/32/381818_2.png) [@haozi](https://meta.discourse.org/u/haozi)
#### Post date: [13 Maggio 2024, 1:23pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/6 "2024-05-13T13:23:40Z")

</div>

OK, grazie per il chiarimento.

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [20 Agosto 2024, 12:05pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/7 "2024-08-20T12:05:29Z")

</div>

David,

Solo alcune precisazioni.

Questo nuovo sistema presumibilmente funziona bene con:

- script inline
- sorgenti di script complete ospitate localmente

Ma che dire del caso in cui gli script remoti sono stati richiamati con “loadScript” e l’URL remoto completo?

Correggimi se sbaglio, ma non credo ci sia un modo carino per gestire quel caso?

Quindi, significa che per quei casi dobbiamo invece fare affidamento su:

- spostare tale invocazione in uno script inline OPPURE
- scaricare l’intera sorgente come risorsa del tema?

Per il primo caso di script inline, immagino non ci sia modo di garantire che lo script venga caricato prima di utilizzarne gli elementi? (Come potresti fare all’interno di un .then dopo un loadScript)

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [20 Agosto 2024, 12:26pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/8 "2024-08-20T12:26:52Z")

</div>

strict-dynamic dovrebbe funzionare con script remoti caricati tramite `loadScript`. Infatti, questo è stato il motivo principale del passaggio: non abbiamo più bisogno di elencare in anticipo ogni singolo URL di script esterno. Ciò è particolarmente utile per chi gestisce annunci pubblicitari, che spesso utilizzano una grande quantità di script remoti.

Stai riscontrando errori con loadScript?

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [20 Agosto 2024, 12:32pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/9 "2024-08-20T12:32:09Z")

</div>

Stavo riscontrando alcuni errori, ma potrebbe non essere per questo motivo. Vediamo se riesco a trovare un esempio.

Mi stavo principalmente preparando per un aggiornamento stabile che so comporta loadScript e script remoti.

Puoi assecondarmi e spiegarmi come gli script remoti che vengono richiamati casualmente nel codice con loadScript finiscono per essere “autorizzati” dalla CSP in modalità dinamica? Sta succedendo qualcosa di magico?

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [20 Agosto 2024, 12:39pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/10 "2024-08-20T12:39:50Z")

</div>

> [@merefield](#):
>
> Sta succedendo qualcosa di magico?

Sì!

MDN ha una [bella spiegazione](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#strict-dynamic) ed esempi.

> L’espressione sorgente `'strict-dynamic'` specifica che la fiducia data esplicitamente a uno script presente nel markup, accompagnandolo con un nonce o un hash, verrà propagata a tutti gli script caricati da quello script radice.

Quindi, finché lo script originale è attendibile (tramite un nonce), il browser consente di caricare qualsiasi altro script senza restrizioni. E poi, poiché tali script sono attendibili, possono caricarne altri!

* * *

C’è un’unica avvertenza, ovvero che gli script non possono essere “inseriti dal parser”. Questo impedisce che strict-dynamic venga sfruttato per attacchi XSS.

Quindi, ad esempio, questo verrebbe “inserito dal parser” e verrebbe bloccato:

```js
document.head.appendChild("<script src='https://example.com/xss-attempt.js' />");

```

Ma la costruzione dell’elemento script programmaticamente non comporta l’analisi HTML, è molto meno probabile che sia un vettore XSS, e quindi è consentito:

```js
const script = document.createElement("script");
script.src = "https://example.com/script.js"
document.head.appendChild(script);

```

^^ questo è essenzialmente come funziona `loadScript()`

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [20 Agosto 2024, 12:49pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/11 "2024-08-20T12:49:33Z")

</div>

Ottimo link.

OK, quasi fatto, grazie!

Quindi il nonce è incluso anche nei tag script renderizzati da loadScript?

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [20 Agosto 2024, 12:59pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/12 "2024-08-20T12:59:10Z")

</div>

No, il nonce è incluso solo nel tag dello script originale renderizzato da Rails (ad esempio, script core, plugin o tema).

Ciò significa che il codice core/plugin/tema è considerato attendibile e può inserire qualsiasi altro script. Non è necessario alcun nonce: il browser sa quale script ha eseguito l’inserimento e sa magicamente che può essere considerato attendibile.

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [20 Agosto 2024, 1:00pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/13 "2024-08-20T13:00:34Z")

</div>

David, ancora grazie per il tuo tempo!

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [2 Settembre 2024, 10:45am UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/14 "2024-09-02T10:45:39Z")

</div>

6 post sono stati divisi in un nuovo argomento: [Errore CSP durante l’aggiunta di uno script tramite un componente del tema](https://meta.discourse.org/t/csp-error-when-adding-a-script-via-a-theme-component/324482)