# map_meta_cap et une capacité qui déverrouille Elementor par erreur > Un rôle censé être limité à ses propres pages peut hériter d'un accès complet à l'éditeur Elementor si une capacité personnalisée n'est pas filtrée avec soin. - Auteur : Clément Hadrot - Publié le : 2025-04-19 - Mis à jour le : 2025-04-19 - Catégorie : Elementor - URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/map-meta-cap-capacite-deverrouille-elementor/ ## L’essentiel - Une capacité personnalisée mal filtrée ouvre l'éditeur à tout le monde - map_meta_cap transforme une capacité méta en capacités primitives - Toujours tester avec un compte du rôle concerné, pas en admin 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 ); ``` > L'essentiel à retenir : Une capacité personnalisée mal filtrée ouvre l'éditeur à tout le monde ; map_meta_cap transforme une capacité méta en capacités primitives ; Toujours tester avec un compte du rôle concerné, pas en admin 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_cap` via 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.