### 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 se tirer dans le pied ?

Eh bien, veuillez noter que si vous _d'abord_ assainissez le HTML puis le modifiez _ensuite_, vous pourriez facilement **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 modifie pas le HTML de son côté. Consultez le [Security Goals & Threat Model](https://github.com/cure53/DOMPurify/wiki/Security-Goals-&-Threat-Model) pour des recettes d'utilisation sûre et pour les balises/attributs à doublement réfléchir, et [Attack Classes & Bypass History](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 jeter un œil à la propriété `DOMPurify.removed` et 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

Techniquement, DOMPurify fonctionne également 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 sur le 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 vivement** d'utiliser la dernière version de _jsdom_.

Pourquoi ? Parce que les anciennes versions de _jsdom_ sont connues pour avoir des bogues qui entraînent des XSS _même si_ DOMPurify fait tout 100 % correctement. Il existe des **vecteurs d'attaque connus** dans, par exemple, _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** à l'heure actuelle. 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 [Attack Classes & Bypass History](https://github.com/cure53/DOMPurify/wiki/Attack-Classes-&-Bypass-History).

À part cela, vous pouvez utiliser DOMPurify sur le serveur. 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 les 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>');

The input content is empty — no text was provided to translate. Please supply the chunk content.```js
import DOMPurify from 'isomorphic-dompurify';

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

Ce n'est là qu'un aperçu. Pour la taxonomie complète des classes d'attaques d'où proviennent ces échantillons - mutation XSS, confusion d'espaces de noms, DOM clobbering, évasions 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 le CSS et les attributs de données personnalisés HTML. DOMPurify prend également en charge le Shadow DOM - et assainit récursivement les modèles DOM. DOMPurify vous permet également d'assainir le HTML pour qu'il soit utilisé avec l'API jQuery `$()` et `elm.html()` sans aucun problème connu. Pour la liste exacte 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 anciens navigateurs 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 mettre au point 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 drapeau 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, pas `TrustedHTML`. L'exemple ci-dessous le montre.```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` que vous ne pouvez pas facilement trouver ou réécrire - jetez un œil à [DOMFortify](https://github.com/cure53/DOMFortify). Il installe exactement une telle politique `default` de Trusted Types adossée à DOMPurify et refuse catégoriquement les puits de script (`eval`, `script.src`, ...). C'est un projet délibérément séparé : DOMPurify reste un assainisseur ciblé, et DOMFortify gère la couche d'application à l'échelle du document qui est intentionnellement hors 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 une série d'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 deux fois](https://github.com/cure53/DOMPurify/wiki/Security-Goals-&-Threat-Model#dangerous-tags-and-attributes-think-twice-before-allow-listing) - certains sont dangereux de manières non évidentes.

### 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 });