# trusted-types-eval, autoriser eval plus prudemment dans une CSP (/fr/blog/trusted-types-eval-csp)



Si vous avez besoin que `eval()` ou le constructeur `Function()` continuent de fonctionner sous une politique de sécurité du contenu (CSP), la réponse habituelle a longtemps été d'ajouter `'unsafe-eval'`. Ce mot-clé réactive la compilation de chaîne en code pour n'importe quelle chaîne, ce qui correspond exactement au comportement que la plupart des attaques par cross-site scripting (XSS) exploitent. Le mot-clé `'trusted-types-eval'` est le remplaçant plus sûr : il autorise `eval()` et `Function()` uniquement quand les Trusted Types sont appliqués et uniquement quand vous passez un objet `TrustedScript` au lieu d'une chaîne brute.

En résumé : si vous déployez les Trusted Types et qu'il vous reste un sink `eval` que vous ne pouvez pas encore retirer, utilisez `'trusted-types-eval'` dans `script-src` plutôt que `'unsafe-eval'`. Sur les navigateurs qui appliquent les Trusted Types, la compilation de code doit d'abord passer par une policy. Sur les navigateurs qui ne prennent pas en charge les Trusted Types, `eval` reste bloqué au lieu d'être totalement ouvert. La suite de cet article explique où se situe le mot-clé, comment il se comporte et comment le mettre en place.

Vous découvrez cette partie de la CSP ? [Comment construire une politique de sécurité du contenu solide](/fr/blog/how-to-build-a-strong-csp) couvre les bases, et [Pourquoi vous ne devriez jamais utiliser unsafe-inline dans une CSP](/fr/blog/unsafe-inline-csp) explique le problème connexe des scripts inline.

## Ce que la CSP bloque par défaut [#ce-que-la-csp-bloque-par-défaut]

Une politique de sécurité du contenu est un header de réponse HTTP qui indique au navigateur quels scripts il a le droit d'exécuter. Quand la politique définit [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src) (ou se rabat sur [`default-src`](/fr/docs/web-security/policies/content-security-policy/directives/default-src)), le navigateur bloque les fonctions qui transforment des chaînes en code exécuté :

* `eval()`
* `new Function()` et le constructeur `Function`
* la forme chaîne de `setTimeout()` et `setInterval()`

C'est intentionnel. Ces sinks de compilation de chaîne sont un chemin direct entre du texte injecté et du JavaScript exécuté, donc le header de sécurité les désactive tant que vous ne les réactivez pas explicitement.

Les deux façons de les réactiver présentent des risques très différents. La première, [`'unsafe-eval'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords), réactive la compilation de chaîne pour chaque chaîne sans aucun contrôle ; voyez [unsafe-eval et comment le supprimer](/fr/blog/unsafe-eval-csp). La seconde, `'trusted-types-eval'`, fait l'objet de cet article.

## Ce que fait trusted-types-eval [#ce-que-fait-trusted-types-eval]

`'trusted-types-eval'` est un mot-clé source de `script-src`. Ce n'est pas une valeur de `require-trusted-types-for` ni une valeur de `trusted-types`. Il se place dans la liste de `script-src` à côté de mots-clés comme `'unsafe-eval'` et `'wasm-unsafe-eval'`.

La comparaison tient en deux points :

* `'unsafe-eval'` réactive `eval()` et `Function()` pour n'importe quelle chaîne. Risque élevé, et il fonctionne de la même manière, que les Trusted Types existent ou non.
* `'trusted-types-eval'` les réactive uniquement quand les Trusted Types sont appliqués aux scripts, et uniquement quand vous passez un `TrustedScript` produit par l'une de vos policies, pas une simple chaîne.

La différence pratique apparaît sur les navigateurs qui ne prennent pas en charge les Trusted Types. Avec `'unsafe-eval'`, ces navigateurs exécutent n'importe quelle chaîne que vous passez à `eval()`, donc, sans Trusted Types, il n'y a aucune protection. Avec `'trusted-types-eval'`, rien n'y autorise eval, donc le sink reste bloqué. Vous avez l'eval dont vous avez besoin là où les Trusted Types sont appliqués, et un comportement par défaut sûr partout ailleurs.

Un point à ne pas confondre : `'trusted-types-eval'` à lui seul n'active pas les Trusted Types. Il ne fait que régir les sinks eval et `Function` dans un contexte où l'application est déjà en place. L'application vient toujours de [`require-trusted-types-for`](/fr/docs/web-security/policies/content-security-policy/directives/require-trusted-types-for).

## Comment appliquer les Trusted Types pour eval [#comment-appliquer-les-trusted-types-pour-eval]

Deux directives activent les Trusted Types ; [comment activer les Trusted Types](/fr/blog/enable-trusted-types) détaille le déploiement de bout en bout. La directive [`require-trusted-types-for`](/fr/docs/web-security/policies/content-security-policy/directives/require-trusted-types-for) n'accepte que la valeur `'script'` et demande au navigateur d'appliquer les Trusted Types aux sinks d'injection DOM et aux sinks de compilation de chaîne (`eval`, `Function`) :

```http
Content-Security-Policy: require-trusted-types-for 'script'
```

La directive [`trusted-types`](/fr/docs/web-security/policies/content-security-policy/directives/trusted-types) contrôle quels noms de policy vous avez le droit de créer. Elle accepte un ou plusieurs noms de policy, plus des mots-clés optionnels comme `'allow-duplicates'` (et `'none'` pour interdire toutes les policies, ou `*` pour autoriser n'importe quel nom unique) :

```http
Content-Security-Policy: trusted-types myPolicy 'allow-duplicates'
```

Pour autoriser `eval()` uniquement quand les Trusted Types sont appliqués, combinez les trois dans une seule politique. Une directive par ligne pour la lisibilité :

```diff
Content-Security-Policy:
-  script-src 'self' 'unsafe-eval';
+  script-src 'self' 'trusted-types-eval';
  require-trusted-types-for 'script';
  trusted-types myPolicy
```

Avec cette politique en place, appeler `eval()` avec une simple chaîne lève une `EvalError`, même si `'trusted-types-eval'` est présent. Vous devez d'abord compiler un `TrustedScript` via l'une de vos policies enregistrées.

## Un exemple concret [#un-exemple-concret]

Enregistrez une policy Trusted Types qui définit `createScript`, puis passez sa sortie à `eval()` :

```javascript
// Register a policy that vets the string before it becomes code.
const policy = window.trustedTypes.createPolicy('myPolicy', {
  createScript: (input) => {
    // Validate or transform input here. Returning it as-is is not safe;
    // a policy is only as good as the checks you put in it.
    return input;
  },
});

// A plain string is rejected under enforcement.
eval('a = "hello"'); // throws EvalError

// A TrustedScript from the policy is accepted.
const trusted = policy.createScript('a = "hello"');
eval(trusted); // runs
```

La chaîne doit toujours passer par `createScript`, ce qui vous donne un seul endroit pour la valider ou l'assainir. C'est tout l'intérêt de l'approche, et aussi sa limite : la policy peut toujours être mal écrite, donc les Trusted Types ne rendent pas le code sûr à eux seuls. Ils garantissent que chaque chaîne compilée est passée par un point de contrôle que vous maîtrisez.

Un raccourci mérite d'être connu. Une policy enregistrée avec le nom réservé `"default"` exécute son `createScript` sur toute chaîne simple passée à un sink eval, ce qui réautorise `eval()` avec des chaînes simples sur toute la page. N'y recourez qu'en connaissance de cause, car il ramène la surface vers le comportement de `'unsafe-eval'`.

## Quand les violations sont reportées [#quand-les-violations-sont-reportées]

Les violations Trusted Types n'introduisent pas de nouveau type de report. Elles arrivent comme des reports de violation CSP standard, le même payload que vous recevez déjà pour tout script bloqué, livré à l'endpoint de reporting vers lequel pointe votre politique. Les valeurs exactes de `effectiveDirective` et `sample` émises pour un blocage Trusted Types spécifique à eval ne se confirment vraiment qu'avec une capture en direct ; la forme générale du report (`documentURL`, `blockedURL`, `effectiveDirective`, `sample`) est le [corps de violation CSP standard](/fr/blog/csp-violation-report-fields).

Envoyez ces reports quelque part où vous pouvez les lire. Ajoutez un endpoint de reporting à votre politique :

```http
Content-Security-Policy:
  script-src 'self' 'trusted-types-eval';
  require-trusted-types-for 'script';
  trusted-types myPolicy;
  report-to csp-endpoint
```

```http
Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
```

Sur un vrai site, déployer les Trusted Types passe presque toujours par une première phase en Report-Only : on observe quels sinks se déclenchent, puis on les corrige avant d'appliquer. CentralCSP ingère ces reports et les regroupe pour que vous voyiez quelles pages dépendent encore d'eval et quelles policies sont créées. Avant de déployer une politique, vous pouvez y chercher les mots-clés eval et d'autres risques avec l'[évaluateur CSP](/tools/csp-evaluator) gratuit.

## Faut-il l'utiliser du tout ? [#faut-il-lutiliser-du-tout-]

`'trusted-types-eval'` est un mot-clé plus sûr que `'unsafe-eval'`, mais la politique la plus sûre n'a ni l'un ni l'autre. Exécuter du code à partir de chaînes reste risqué, et une seule erreur dans une policy peut encore laisser passer une injection.

Un ordre de préférence raisonnable :

1. Retirez l'eval. Remplacez la compilation dynamique de chaîne par `JSON.parse`, une table de correspondance, ou du code ordinaire partout où vous le pouvez.
2. Autorisez précisément les scripts que vous connaissez. Utilisez un [nonce ou un hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) dans `script-src` pour autoriser les scripts auxquels vous faites confiance, plutôt que d'ouvrir eval.
3. Si vous avez réellement besoin d'eval pour l'instant, utilisez `'trusted-types-eval'` avec `require-trusted-types-for 'script'` et une policy stricte, et traitez-le comme une étape temporaire pendant que vous retirez la dépendance.

## Prise en charge par les navigateurs aujourd'hui [#prise-en-charge-par-les-navigateurs-aujourdhui]

Les directives `require-trusted-types-for` et `trusted-types` sont récemment devenues disponibles dans les versions actuelles de Chrome, Firefox et Safari. Chromium implémente les Trusted Types depuis des années, et Firefox les a ajoutés plus récemment.

Le mot-clé `'trusted-types-eval'` est plus récent, et il est lui aussi arrivé dans les versions actuelles de Chrome, Firefox et Safari, comme ajout normalisé à la grammaire `script-src` de CSP Level 3. Comme le mot-clé se dégrade en toute sécurité, le déployer sur un navigateur qui ne le reconnaît pas encore laisse eval bloqué, ce qui est le comportement souhaité.

Si vous introduisez les Trusted Types dans une application existante, commencez en Report-Only, routez les reports vers un endroit où vous pouvez les lire, et resserrez à partir de là. [Démarrer avec le reporting CSP](/fr/blog/get-started-csp-reporting) détaille la configuration du reporting, et vous pouvez [démarrer gratuitement](/register) pour voir vos reports Trusted Types et eval regroupés sur du trafic réel.

## Articles liés [#articles-liés]

* [Pourquoi ne jamais utiliser unsafe-inline dans une CSP](/fr/blog/unsafe-inline-csp)
* [Construire une CSP solide, étape par étape](/fr/blog/how-to-build-a-strong-csp)