# wp_kses_post contre un filtre wp_kses personnalisé : nettoyer sans mutiler

> wp_kses_post suffit pour la plupart des contenus riches d'une extension, mais un jeu de balises personnalisé devient nécessaire dès qu'un besoin sort du contenu éditorial classique.

- Auteur : WordPress Développement
- Publié le : 2021-12-15
- Mis à jour le : 2021-12-15
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/wp-kses-post-contre-filtre-wp-kses-personnalise/

## L’essentiel

- wp_kses_post autorise le jeu de balises des articles standards
- Un jeu personnalisé se construit avec wp_kses() et un tableau explicite
- Trop restreindre casse le contenu, trop élargir rouvre une faille XSS

« kses signifie "keep sensible editing style" et permet de filtrer le HTML entrant selon une liste blanche de balises et d'attributs autorisés », précise la documentation du Codex à propos de cette famille de fonctions de sanitisation, l'une des plus anciennes du cœur de WordPress mais toujours aussi centrale.

Pour un développeur d'extension qui doit accepter du contenu riche - un champ de description longue, un commentaire enrichi, un contenu importé depuis une source externe - la question se pose systématiquement : la fonction générique `wp_kses_post()` suffit-elle, ou faut-il construire un filtre sur mesure avec `wp_kses()` directement ?

## Ce que fait wp_kses_post par défaut

```
$contenu_nettoye = wp_kses_post( $contenu_brut );
```

Cette fonction applique la même liste de balises et d'attributs autorisés que celle utilisée pour le contenu des articles standards : les balises de mise en forme courantes (`p`, `strong`, `em`, `a`, `ul`, `li`...), avec leurs attributs habituels, mais sans balises de script ni d'iframe, et sans attributs d'événements comme `onclick`.

## Quand ce standard devient insuffisant

Un champ de description longue dans une extension de catalogue produit peut légitimement avoir besoin d'accepter des balises que `wp_kses_post()` autorise déjà ; le problème survient surtout dans le sens inverse : un besoin de restreindre davantage, par exemple pour un champ qui ne doit contenir que du texte enrichi minimal, sans même les liens.

> L'essentiel à retenir : wp_kses_post autorise le jeu de balises des articles standards ; Un jeu personnalisé se construit avec wp_kses() et un tableau explicite ; Trop restreindre casse le contenu, trop élargir rouvre une faille XSS

## Construire un jeu de balises personnalisé

```
$balises_autorisees = array(
    'strong' => array(),
    'em'     => array(),
    'br'     => array(),
);

$contenu_nettoye = wp_kses( $contenu_brut, $balises_autorisees );
```

Ce tableau associatif définit précisément les balises acceptées et, pour chacune, les attributs autorisés. Une balise `a` qui doit conserver un attribut `href` et `title`, mais rien d'autre, s'écrit ainsi :

```
$balises_autorisees['a'] = array(
    'href'  => true,
    'title' => true,
);
```

### Le piège de la sur-restriction

Un jeu de balises trop restreint mutile silencieusement un contenu légitime : un rédacteur qui insère une liste à puces dans un champ où seules `strong` et `em` sont autorisées se retrouve avec ses balises `ul` et `li` supprimées, sans message d'erreur explicite, puisque `wp_kses()` retire simplement ce qu'elle ne reconnaît pas plutôt que de rejeter la saisie.

### Le piège de la sur-permissivité

À l'inverse, ajouter des balises « au cas où » sans réflexion, notamment des attributs qui acceptent des URL ou du contenu exécutable, rouvre potentiellement une faille de script intersite. Un attribut comme `style`, par exemple, peut permettre certaines attaques via des propriétés CSS spécifiques et mérite d'être exclu sauf besoin réellement justifié.

| Situation | Fonction recommandée |
| --- | --- |
| Contenu éditorial classique | wp_kses_post() |
| Champ restreint à quelques balises | wp_kses() avec tableau personnalisé |
| Texte simple sans mise en forme | sanitize_text_field() |
| Zone de texte multiligne sans HTML | sanitize_textarea_field() |

## Un filtre réutilisable plutôt qu'un tableau dupliqué

```
function wpm_balises_description_courte() {
    return array(
        'strong' => array(),
        'em'     => array(),
    );
}

function wpm_nettoyer_description( $contenu ) {
    return wp_kses( $contenu, wpm_balises_description_courte() );
}
```

Centraliser le tableau de balises dans une fonction dédiée évite de le dupliquer à chaque endroit où le nettoyage est appliqué, et facilite son ajustement futur si un nouveau besoin de mise en forme apparaît.

> La règle qui guide ce choix : ne jamais autoriser une balise ou un attribut sans savoir précisément pourquoi il est nécessaire pour ce champ précis, pas pour un usage hypothétique futur.

## En résumé

`wp_kses_post()` couvre correctement l'immense majorité des besoins de contenu éditorial dans une extension, et il est préférable de s'y tenir tant que le besoin ne sort pas de ce cadre standard. Un jeu personnalisé via `wp_kses()` ne se justifie que pour un champ dont le périmètre de mise en forme diffère réellement de celui d'un article, et mérite d'être construit avec la même rigueur qu'une règle de sécurité, ni trop large ni trop stricte.