### Utilisation de la version de production minifiée et testée (source-map disponible)```html
<script type="text/javascript" src="dist/purify.min.js"></script>

Ou peut-être ceci, si vous aimez travailler avec Angular ou similaire :```js
import DOMPurify from 'dompurify';

const clean = DOMPurify.sanitize('<b>hello there</b>');

### Y a-t-il un risque de tir dans le pied ?

Eh bien, veuillez noter que si vous _d'abord_ assainissez le HTML puis le modifiez _ensuite_, vous risquez facilement **d'annuler les effets de l'assainissement**. Si vous transmettez le balisage assaini à une autre bibliothèque _après_ l'assainissement, assurez-vous que cette bibliothèque ne bricole pas le HTML de son côté. Consultez les [Objectifs de sécurité et modèle de menace](https://github.com/cure53/DOMPurify/wiki/Security-Goals-&-Threat-Model) pour des recettes d'utilisation sûres et les balises/attributs à examiner de plus près, ainsi que les [Classes d'attaques et historique des contournements](https://github.com/cure53/DOMPurify/wiki/Attack-Classes-&-Bypass-History) pour comprendre pourquoi le post-traitement et la modification du contexte du balisage compromettent l'assainissement.

### D'accord, ça a du sens, passons à la suite

Après avoir assaini votre balisage, vous pouvez également consulter la propriété `DOMPurify.removed` pour découvrir quels éléments et attributs ont été rejetés. Veuillez **ne pas utiliser** cette propriété pour prendre des décisions critiques en matière de sécurité. Ce n'est qu'un petit outil pour les esprits curieux.

### Exécuter DOMPurify côté serveur

DOMPurify fonctionne techniquement aussi côté serveur avec Node.js. Notre support s'efforce de suivre le [cycle de publication de Node.js](https://nodejs.org/en/about/previous-releases).

Exécuter DOMPurify côté serveur nécessite la présence d'un DOM, ce qui n'est probablement pas une surprise. En général, [jsdom](https://github.com/jsdom/jsdom) est l'outil de choix et nous **recommandons fortement** d'utiliser la dernière version de _jsdom_.

Pourquoi ? Parce que les anciennes versions de _jsdom_ sont connues pour être boguées d'une manière qui entraîne des XSS _même si_ DOMPurify fait tout correctement à 100 %. Il existe des **vecteurs d'attaque connus**, par exemple dans _jsdom v19.0.0_, qui sont corrigés dans _jsdom v20.0.0_ — et nous recommandons vraiment de maintenir _jsdom_ à jour pour cette raison.

Veuillez également noter que des outils comme [happy-dom](https://github.com/capricorn86/happy-dom) existent mais **ne sont pas considérés comme sûrs** à ce stade. Combiner DOMPurify avec _happy-dom_ n'est actuellement pas recommandé et conduira probablement à des XSS. Pour comprendre pourquoi le DOM côté serveur que vous choisissez fait partie de votre base de confiance informatique, consultez les [Classes d'attaques et historique des contournements](https://github.com/cure53/DOMPurify/wiki/Attack-Classes-&-Bypass-History).

À part cela, vous pouvez utiliser DOMPurify côté serveur sans problème. Probablement. Cela dépend vraiment de _jsdom_ ou de tout autre DOM que vous utilisez côté serveur. Si vous pouvez vivre avec cela, voici comment le faire fonctionner :```bash
npm install dompurify
npm install jsdom

Ou même ceci, si vous préférez travailler avec des imports :```js
import { JSDOM } from 'jsdom';
import DOMPurify from 'dompurify';

const window = new JSDOM('').window;
const purify = DOMPurify(window);
const clean = purify.sanitize('<b>hello there</b>');

Aucun contenu fourni.```js
import DOMPurify from 'isomorphic-dompurify';

const clean = DOMPurify.sanitize('<s>hello</s>');

Voici un aperçu. Pour la taxonomie complète des classes d'attaques dont proviennent ces échantillons — mutation XSS, confusion d'espaces de noms, clobbering DOM, échappements rawtext, et plus encore — voir [Attack Classes & Bypass History](https://github.com/cure53/DOMPurify/wiki/Attack-Classes-&-Bypass-History).

## Qu'est-ce qui est pris en charge ?

DOMPurify prend actuellement en charge HTML5, SVG et MathML. Par défaut, DOMPurify autorise les CSS et les attributs de données personnalisés HTML. DOMPurify prend également en charge le Shadow DOM — et assainit les modèles DOM de manière récursive. DOMPurify vous permet aussi d'assainir du HTML pour une utilisation avec les API jQuery `$()` et `elm.html()` sans aucun problème connu. Pour l'ensemble exact des éléments et attributs autorisés par défaut, voir la page wiki [Default TAGs & ATTRIBUTEs allow-list & blocklist](https://github.com/cure53/DOMPurify/wiki/Default-TAGs-ATTRIBUTEs-allow-list-&-blocklist).

## Qu'en est-il des navigateurs hérités comme Internet Explorer ?

DOMPurify ne fait rien du tout. Il renvoie simplement exactement la chaîne que vous lui avez fournie. DOMPurify expose une propriété appelée `isSupported`, qui vous indique s'il sera capable de faire son travail, afin que vous puissiez élaborer votre propre plan de secours.

## Qu'en est-il de DOMPurify et des Trusted Types ?

Dans la version 1.0.9, la prise en charge de l'[API Trusted Types](https://github.com/w3c/webappsec-trusted-types) ([MDN](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API)) a été ajoutée à DOMPurify.
Dans la version 2.0.0, un indicateur de configuration a été ajouté pour contrôler le comportement de DOMPurify à cet égard.

Lorsque `DOMPurify.sanitize` est utilisé dans un environnement où l'API Trusted Types est disponible et que `RETURN_TRUSTED_TYPE` est défini sur `true`, il tente de renvoyer une valeur `TrustedHTML` au lieu d'une chaîne (le comportement des options de configuration `RETURN_DOM` et `RETURN_DOM_FRAGMENT` ne change pas).

Notez que pour créer une politique dans `trustedTypes` à l'aide de DOMPurify, `RETURN_TRUSTED_TYPE: false` est requis, car `createHTML` attend une chaîne normale, et non `TrustedHTML`. L'exemple ci-dessous illustre cela.```js
window.trustedTypes.createPolicy('default', {
  createHTML: (to_escape) =>
    DOMPurify.sanitize(to_escape, { RETURN_TRUSTED_TYPE: false }),
});

Ne **transmettez pas** votre propre politique d’encapsulage à DOMPurify comme `TRUSTED_TYPES_POLICY` (par exemple via `DOMPurify.setConfig({ TRUSTED_TYPES_POLICY: myPolicy })`) lorsque le `createHTML` de cette politique appelle déjà `DOMPurify.sanitize`. C’est circulaire par définition — l’assainissement appellerait la politique, qui assainit en appelant à nouveau DOMPurify — et DOMPurify lèvera une `TypeError` descriptive pour empêcher la récursion infinie. Votre propre politique doit appeler DOMPurify ; DOMPurify ne doit pas être configuré pour appeler votre politique.

Si vous souhaitez que ce modèle de politique `default` soit appliqué automatiquement à une page entière — afin que chaque puits HTML soit assaini, y compris le code hérité, les widgets tiers et les milliers d’affectations `innerHTML` difficiles à trouver ou à réécrire — jetez un œil à [DOMFortify](https://github.com/cure53/DOMFortify). Il installe exactement une telle politique Trusted Types `default` adossée à DOMPurify et refuse les puits de script (`eval`, `script.src`, …) sans appel. C’est volontairement un projet séparé : DOMPurify reste un assainisseur ciblé, et DOMFortify gère la couche d’application à l’échelle du document qui sort intentionnellement du périmètre de DOMPurify.

## Puis-je configurer DOMPurify ?

Oui. Les valeurs de configuration par défaut incluses sont déjà plutôt bonnes — mais vous pouvez bien sûr les remplacer. Consultez le dossier [`/demos`](https://github.com/cure53/DOMPurify/tree/main/demos) pour voir de nombreux exemples sur la façon de [personnaliser DOMPurify](https://github.com/cure53/DOMPurify/tree/main/demos#what-is-this).

Avant d’élargir la liste d’autorisation (`ADD_TAGS`, `ADD_ATTR`, `CUSTOM_ELEMENT_HANDLING`, …) ou d’assouplir une valeur par défaut, il vaut la peine de parcourir les [balises et attributs à considérer avec prudence](https://github.com/cure53/DOMPurify/wiki/Security-Goals-&-Threat-Model#dangerous-tags-and-attributes-think-twice-before-allow-listing) — certains sont dangereux de manière non évidente.

### Paramètres généraux```js
// strip {{ ... }}, ${ ... } and <% ... %> to make output safe for template systems
// be careful please, this mode is not recommended for production usage.
// allowing template parsing in user-controlled HTML is not advised at all.
// only use this mode if there is really no alternative.
const clean = DOMPurify.sanitize(dirty, { SAFE_FOR_TEMPLATES: true });

// change how e.g. comments containing risky HTML characters are treated.
// be very careful, this setting should only be set to `false` if you really only handle
// HTML and nothing else, no SVG, MathML or the like.
// Otherwise, changing from `true` to `false` will lead to XSS in this or some other way.
const clean = DOMPurify.sanitize(dirty, { SAFE_FOR_XML: false });