# Ce qu’expose la découverte oEmbed de WordPress quand l’URL provient d’un visiteur

> Un champ qui accepte une URL et en tire un aperçu enrichi déclenche, côté serveur, une requête vers une adresse choisie par le visiteur. Ce que ce mécanisme expose réellement.

- Auteur : WordPress Développement
- Publié le : 2021-09-08
- Mis à jour le : 2021-09-08
- Catégorie : Sécurité
- URL : https://www.wpmoderne.fr/securite/decouverte-oembed-wordpress-url-visiteur/

## L’essentiel

- La découverte oEmbed déclenche une requête HTTP côté serveur
- Une URL interne fournie par un visiteur peut être sondée à travers ce mécanisme
- wp_oembed_add_provider et les filtres dédiés permettent de restreindre les sources

Un champ de saisie qui accepte une adresse de vidéo ou de publication externe et en affiche automatiquement un aperçu enrichi repose, la plupart du temps, sur le protocole oEmbed. WordPress intègre nativement ce mécanisme depuis longtemps, à la fois pour son propre éditeur de contenu et pour toute extension qui souhaite proposer une expérience similaire à un visiteur.

## Le mécanisme oEmbed, vu du serveur

Quand une adresse est soumise, WordPress détermine d'abord si elle correspond à un fournisseur oEmbed connu, référencé via `wp_oembed_add_provider()` ou reconnu automatiquement par découverte de liens `<link>` dans le document HTML de la page cible. Dans ce second cas, appelé découverte, WordPress effectue lui-même, côté serveur, une requête HTTP vers l'URL fournie, afin d'y chercher les balises de découverte oEmbed, avant même de savoir si un aperçu enrichi existe réellement.

Cette requête serveur constitue le point d'attention central : le serveur exécute une requête HTTP sortante vers une adresse en grande partie déterminée par ce que le visiteur a saisi.

## Ce que cela expose quand l'URL est arbitraire

- Une adresse interne au réseau de l'hébergeur, invisible depuis l'extérieur, peut être sondée par ce biais si le mécanisme n'est pas restreint, révélant l'existence ou l'absence d'un service à cette adresse selon la réponse obtenue ou le délai observé.
- Le temps de réponse de la requête de découverte peut lui-même constituer une information exploitable, pour distinguer une adresse qui répond rapidement d'une adresse qui n'existe pas ou qui bloque la connexion.
- Un service interne mal protégé, accessible sans authentification depuis le réseau du serveur lui-même, pourrait recevoir une requête qu'il n'aurait jamais reçue d'un visiteur externe classique.

> L'essentiel à retenir : La découverte oEmbed déclenche une requête HTTP côté serveur ; Une URL interne fournie par un visiteur peut être sondée à travers ce mécanisme ; wp_oembed_add_provider et les filtres dédiés permettent de restreindre les sources

## Restreindre la découverte à des domaines de confiance

WordPress expose le filtre `oembed_remote_get_args` pour ajuster les paramètres de la requête sortante, et surtout la fonction `wp_oembed_add_provider()` pour déclarer explicitement les fournisseurs autorisés sans passer par la découverte automatique :

```
add_action('init', function () {
    wp_oembed_add_provider(
        '#https://(www\.)?plateforme-video-exemple\.fr/.*#i',
        'https://plateforme-video-exemple.fr/oembed',
        true
    );
});

// Empeche la decouverte automatique pour tout domaine non declare explicitement.
add_filter('oembed_providers', function (array $providers) {
    return $providers;
});
```

Une approche plus stricte consiste à filtrer la fonction `wp_oembed_get()` elle-même, ou à intercepter en amont toute URL soumise par un visiteur pour vérifier qu'elle appartient à une liste de domaines explicitement autorisés, avant même de la transmettre au mécanisme oEmbed natif.

## Où ce risque se manifeste le plus souvent

Un champ de commentaire enrichi qui transforme automatiquement une URL collée en aperçu, une extension de curation de contenu qui importe des liens externes proposés par des utilisateurs non authentifiés, ou un formulaire de suggestion de ressources sur un intranet, exposent tous ce même mécanisme à des adresses potentiellement internes ou sensibles, si aucune restriction de domaine n'est appliquée en amont de l'appel oEmbed.

> Un champ qui accepte une URL et déclenche une requête serveur mérite le même niveau de vigilance qu'un champ qui accepte du code : les deux transmettent au serveur une instruction partiellement choisie par le visiteur.

## Vérifier la configuration existante avant d'intervenir

Avant toute restriction, il vaut mieux lister les fournisseurs oEmbed déjà enregistrés nativement par WordPress, consultables via la variable globale `$wp_oembed` ou la classe `WP_oEmbed`, pour distinguer ce qui relève d'un usage légitime déjà couvert de ce qui reste ouvert à la découverte automatique par défaut. Une restriction appliquée sans cette vérification préalable risque de casser un usage existant du site, comme l'aperçu automatique d'une vidéo hébergée sur une plateforme grand public déjà utilisée dans les contenus publiés.

## En résumé

La découverte oEmbed rend un service réel pour l'expérience de contenu enrichi, mais elle transforme un simple champ de saisie d'URL en déclencheur de requête serveur vers une adresse en grande partie non maîtrisée. Restreindre les fournisseurs autorisés via `wp_oembed_add_provider()`, plutôt que de laisser la découverte automatique ouverte à n'importe quel domaine, referme cette porte sans supprimer la fonctionnalité pour les usages légitimes.