curl -I https://exemple.test/wp-content/uploads/document-sensible.pdf — une commande aussi simple suffit à constater qu’un fichier statique hébergé sur un site WordPress ne renvoie, par défaut, strictement aucune indication sur qui a le droit de le charger. N’importe quel autre site peut intégrer ce fichier dans une balise <img>, un lecteur PDF embarqué, ou un script qui en récupère le contenu, sans qu’aucune limite ne s’y oppose.
L’en-tête Cross-Origin-Resource-Policy, pris en charge par les navigateurs modernes depuis plusieurs années, permet de restreindre précisément ce comportement, sans toucher au code PHP de WordPress ni à sa configuration applicative : le réglage se fait entièrement au niveau du serveur web qui sert les fichiers statiques.
Ce que résout cet en-tête, et ce qu’il ne résout pas
Cross-Origin-Resource-Policy contrôle qui peut charger une ressource statique donnée depuis un autre site : une image, un fichier PDF, une police, un script. Il ne remplace ni un contrôle d’accès applicatif (vérifier qu’un utilisateur est autorisé à voir un document avant de le servir), ni Subresource Integrity, qui vérifie l’intégrité d’un script chargé depuis un domaine externe et répond à un problème inverse et distinct.
Les trois valeurs possibles
| Valeur | Effet |
|---|---|
| same-origin | Seul le même schéma, domaine et port peuvent charger la ressource |
| same-site | Les sous-domaines d’un même domaine principal sont autorisés en plus |
| cross-origin | Tout site externe peut charger la ressource, comportement par défaut actuel |
Configurer l’en-tête sur Nginx
Pour un dossier de téléversements contenant des documents qui ne devraient jamais être intégrés directement par un autre site, l’ajout se fait dans le bloc de configuration correspondant :
location /wp-content/uploads/documents-prives/ {
add_header Cross-Origin-Resource-Policy same-origin always;
}
Le mot-clé always garantit que l’en-tête est envoyé même en cas de réponse d’erreur (404, 403), ce qui évite une incohérence où seules les réponses réussies seraient protégées.
Configurer l’en-tête sur Apache
Sur un serveur Apache, le module mod_headers permet le même réglage via un fichier .htaccess ciblé ou directement dans la configuration de l’hôte virtuel :
<FilesMatch "\.(pdf|docx|xlsx)$">
Header set Cross-Origin-Resource-Policy "same-origin"
</FilesMatch>
Vérifier que le réglage ne casse rien de légitime
Avant de généraliser la valeur same-origin à l’ensemble du dossier de téléversements, il faut vérifier qu’aucun usage légitime ne dépend d’un chargement cross-origin : un lecteur multimédia hébergé sur un sous-domaine distinct, une galerie affichée sur un site partenaire, un flux RSS consommé par un agrégateur externe qui charge directement les images. Une valeur same-site plutôt que same-origin couvre le cas des sous-domaines légitimes sans ouvrir l’accès à n’importe quel site tiers.
- Repérer les dossiers de téléversements qui contiennent des documents à usage strictement interne
- Appliquer d’abord la restriction en environnement de préproduction
- Vérifier dans la console réseau du navigateur qu’aucune ressource légitime n’est bloquée
- Déployer progressivement, dossier par dossier plutôt que sur l’ensemble du site en une seule fois
Le cas particulier des images utilisées par des partenaires
Un site qui fournit volontairement des images à des partenaires pour affichage sur leurs propres pages doit exclure ces dossiers spécifiques de toute restriction same-origin, ou utiliser cross-origin explicitement pour ces chemins précis afin de documenter ce choix plutôt que de le laisser par défaut sans intention affichée.
Un en-tête de sécurité qui casse un usage légitime sans prévenir finit presque toujours désactivé en urgence : mieux vaut le déployer progressivement, avec une vérification à chaque étape, qu’en une seule bascule générale.
En résumé
Cross-Origin-Resource-Policy referme une porte souvent restée ouverte par défaut : la possibilité, pour n’importe quel site tiers, de réutiliser directement les fichiers statiques hébergés sur un site WordPress. Ce réglage se fait entièrement côté serveur web, sans dépendance à une extension WordPress, et mérite d’être déployé progressivement pour les dossiers qui contiennent des ressources sensibles, en vérifiant à chaque étape qu’aucun usage légitime cross-origin n’est cassé au passage.
