La documentation officielle sur les rôles et capacités décrit map_meta_cap comme le filtre chargé de transformer une capacité « méta », comme edit_post, en une ou plusieurs capacités primitives réellement vérifiées par WordPress. C’est ce mécanisme, discret et rarement manipulé directement, qui peut transformer une intention de restriction en accès complet à l’éditeur Elementor.
Le scénario se produit généralement sur des sites où plusieurs rôles éditoriaux coexistent : rédacteurs, contributeurs, et un rôle personnalisé censé n’éditer que certains types de contenu avec Elementor. La faille n’est presque jamais volontaire, elle vient d’un filtre écrit pour résoudre un problème précis qui, sans le vouloir, en ouvre un autre bien plus large.
Ce qu’on voit : un rôle limité qui peut tout modifier
Le signal d’alerte remonte souvent par hasard : un utilisateur affecté à un rôle restreint parvient à ouvrir l’éditeur Elementor sur des pages qui ne lui appartiennent pas, alors que l’interface d’administration WordPress classique lui refuse pourtant l’accès à ces mêmes contenus depuis la liste des pages. L’incohérence entre les deux interfaces est justement l’indice qui doit alerter.
Elementor s’appuie sur les capacités standards de WordPress pour décider qui peut ouvrir son éditeur sur un contenu donné, en particulier la capacité edit_post évaluée pour l’article ou la page concernée. Si cette capacité méta est mal filtrée en amont, Elementor hérite du problème sans qu’aucune ligne de son propre code ne soit en cause.
Pourquoi c’est un problème : un filtre trop large sur map_meta_cap
Le cas typique ressemble à ce filtre, écrit pour autoriser un rôle personnalisé à éditer un type de contenu précis, mais sans vérifier l’auteur du contenu concerné :
add_filter( 'map_meta_cap', function( $caps, $cap, $user_id, $args ) {
if ( 'edit_post' === $cap ) {
return array( 'edit_posts' );
}
return $caps;
}, 10, 4 );
Ce filtre remplace systématiquement la vérification fine (« cet utilisateur peut-il éditer précisément cet article ? ») par une vérification générique (« cet utilisateur a-t-il la capacité globale edit_posts ? »), sans jamais regarder l’article passé dans $args. Résultat : n’importe quel utilisateur disposant de edit_posts peut désormais ouvrir Elementor sur n’importe quel contenu, y compris ceux d’autres auteurs.
La méthode de diagnostic
Avant de soupçonner Elementor lui-même, la vérification consiste à isoler les filtres actifs sur map_meta_cap et user_has_cap, en particulier ceux ajoutés par des extensions de gestion de rôles ou par du code maison ancien, parfois écrit plusieurs années auparavant et oublié depuis. Un test simple, avec un compte réellement affecté au rôle suspect (jamais un compte administrateur), suffit à confirmer ou infirmer le problème :
- Se connecter avec un compte du rôle concerné, jamais avec un compte administrateur, qui contournerait la vérification.
- Tenter d’ouvrir l’éditeur Elementor sur un contenu appartenant à un autre auteur.
- Si l’accès est accordé, vérifier les filtres actifs sur
map_meta_capvia un plugin de débogage de hooks ou une recherche dans le code du thème et des extensions.
Quoi faire : filtrer la capacité, pas la remplacer
La correction consiste à conserver la logique fine de vérification plutôt que de la court-circuiter. Un filtre correctement écrit vérifie l’auteur réel de l’article avant de décider d’accorder ou non la capacité :
add_filter( 'map_meta_cap', function( $caps, $cap, $user_id, $args ) {
if ( 'edit_post' === $cap && isset( $args[0] ) ) {
$post = get_post( $args[0] );
if ( $post && (int) $post->post_author === (int) $user_id ) {
return array( 'edit_posts' );
}
}
return $caps;
}, 10, 4 );
Cette version restreint l’octroi de la capacité au seul cas où l’utilisateur est bien l’auteur du contenu, ce qui rétablit le comportement attendu sans retirer au rôle personnalisé la capacité d’éditer ses propres pages avec Elementor.
Un filtre sur les capacités qui ne regarde jamais l’objet concerné n’est pas une restriction, c’est une porte laissée entrouverte pour tout le monde.
Une vérification à intégrer à la recette
Sur un site comportant plusieurs rôles éditoriaux et l’éditeur Elementor ouvert à des non-administrateurs, ce test devrait figurer systématiquement dans la checklist de recette avant mise en production : connexion avec chaque rôle non-administrateur, tentative d’édition d’un contenu appartenant à un autre auteur, vérification du refus attendu.
En résumé
Une capacité personnalisée mal filtrée via map_meta_cap peut ouvrir l’éditeur Elementor bien au-delà de ce qui était prévu, sans qu’aucune faille ne vienne d’Elementor lui-même. La vigilance se porte sur les filtres de capacités du thème et des extensions, testés avec de vrais comptes du rôle concerné, jamais avec un compte administrateur qui masquerait le problème.
