Nom du plugin	Plugin API MStore de WordPress
Type de vulnérabilité	Référence d'objet directe non sécurisée (IDOR)
Numéro CVE	CVE-2026-3568
Urgence	Faible
Date de publication du CVE	2026-04-09
URL source	CVE-2026-3568

Référence d'objet direct non sécurisée (IDOR) dans le plugin API MStore (<= 4.18.3) — Ce que les propriétaires de sites WordPress doivent savoir et comment protéger leurs sites

Auteur: Équipe de sécurité WP-Firewall
Date: 2026-04-10
Mots clés: WordPress, Sécurité, Vulnérabilité, IDOR, API MStore, WAF, Réponse aux incidents

Résumé: Une vulnérabilité de Référence d'objet direct non sécurisée (IDOR) affectant le plugin API MStore (versions jusqu'à et y compris 4.18.3) permet à un utilisateur authentifié à faible privilège (abonné ou similaire) de mettre à jour des métadonnées utilisateur arbitraires sur un site WordPress. La vulnérabilité est assignée CVE-2026-3568 et a un score CVSS de 4.3 (Faible). Bien que classée comme de faible gravité, l'impact pratique dépend des clés de métadonnées utilisateur qui peuvent être modifiées — dans certains cas, l'exploitation peut permettre une élévation de privilèges, une manipulation de compte ou une falsification de session. Cet article explique comment la faille fonctionne, les risques dans le monde réel, les étapes de détection, les atténuations et les pratiques de renforcement recommandées — y compris les actions immédiates à entreprendre et comment WP-Firewall peut aider à protéger votre site.

---

Table des matières

• Qu'est-ce qu'un IDOR et pourquoi cela compte dans WordPress
• L'IDOR de l'API MStore : que s'est-il passé (niveau élevé)
• Analyse technique : comment la vulnérabilité est exploitable
• Impact pratique et scénarios d'attaque réalistes
• Comment détecter l'exploitation et les indicateurs de compromission
• Atténuations à court terme (lorsque vous ne pouvez pas mettre à jour immédiatement)
• Solutions à long terme et pratiques de codage sécurisé
• Renforcer votre site WordPress pour réduire les risques futurs
• Liste de contrôle de réponse aux incidents (étape par étape)
• Comment WP-Firewall peut aider à sécuriser votre site maintenant
• Sécurisez votre site avec WP-Firewall Basic (Gratuit)
• Annexe : exemples de règles WAF recommandées et extraits de code sûrs

---

Qu'est-ce qu'un IDOR et pourquoi cela compte dans WordPress

Une Référence d'objet direct non sécurisée (IDOR) se produit lorsqu'une application web expose des références à des objets internes (IDs, noms de fichiers, clés de base de données) et ne parvient pas à appliquer des contrôles d'accès suffisants avant de permettre des opérations sur ces objets. Dans WordPress, les “objets” incluent fréquemment des utilisateurs, des publications, des pièces jointes et des lignes de métadonnées utilisateur. Si un plugin expose un point de terminaison REST, un gestionnaire AJAX ou un formulaire qui accepte un identifiant utilisateur et effectue des mises à jour en utilisant cet identifiant sans vérifier que le demandeur est autorisé à opérer sur l'utilisateur cible, un attaquant peut manipuler l'identifiant et affecter les données d'autres utilisateurs.

Pourquoi cela compte pour la sécurité des sites WordPress :

• WordPress stocke des données de compte importantes dans les métadonnées utilisateur (par exemple, jetons de session, rôles/capacités stockés dans wp_capabilities, et indicateurs spécifiques au plugin). Si l'un de ces éléments peut être modifié par un attaquant, l'intégrité du site peut être compromise.
• Les plugins ajoutent souvent des routes REST personnalisées ou des gestionnaires AJAX. Si ces gestionnaires n'utilisent pas correctement les vérifications de capacité et les nonces de WordPress, ils deviennent un vecteur fréquent pour l'IDOR.
• Même une vulnérabilité classée “ Faible ” peut devenir un point de pivot pour un compromis plus important (par exemple, modifier un rôle pour obtenir un accès administrateur).

---

L'IDOR de l'API MStore : que s'est-il passé (niveau élevé)

Une vulnérabilité a été découverte dans le plugin MStore API affectant les versions <= 4.18.3 qui permettait aux utilisateurs authentifiés avec de faibles privilèges — tels que les abonnés — de mettre à jour des enregistrements de méta-utilisateur arbitraires via un point de terminaison de plugin exposé. Le problème a été attribué au CVE-2026-3568 et corrigé dans la version 4.18.4.

Faits clés :

• Classe de vulnérabilité : Référence d'objet direct non sécurisée (IDOR) — contrôle d'accès défaillant.
• Plugin affecté : MStore API (<= 4.18.3).
• CVE : CVE-2026-3568.
• Corrigé dans : 4.18.4 (les propriétaires de sites doivent mettre à jour immédiatement).
• CVSS : 4.3 (Faible), mais l'impact pratique peut être plus élevé selon les clés méta qui sont modifiables.

En un coup d'œil : un point de terminaison dans le plugin acceptait un identifiant d'utilisateur et une clé/valeur méta sans appliquer de vérifications de permission strictes, permettant à un compte à faibles privilèges de modifier la méta pour des utilisateurs arbitraires.

---

Analyse technique : comment la vulnérabilité est exploitable

Cette section explique les mécanismes typiques de la vulnérabilité de manière accessible. Les détails d'implémentation du plugin original sont spécifiques, mais le schéma général est commun :

1. Le plugin enregistre un point de terminaison REST (ou un gestionnaire AJAX) comme :
   • POST /wp-json/mstore-api/v1/update_user_meta
   • ou un point de terminaison admin-ajax appelé via admin-ajax.php?action=mstore_update_meta
2. Le gestionnaire accepte des paramètres tels que :
   • ID de l'utilisateur (l'utilisateur cible)
   • meta_clé (quelle pièce de méta mettre à jour)
   • valeur_méta (nouvelle valeur à écrire)
3. Le gestionnaire appelle update_user_meta($user_id, $meta_key, $meta_value) sans :
   • Vérifier que l'utilisateur actuel est autorisé à mettre à jour l'utilisateur cible (par exemple, current_user_can('edit_user', $user_id)).
   • Restreindre les clés méta qui peuvent être modifiées.
   • Valider ou assainir les entrées de manière appropriée.
   • Utiliser un nonce ou un rappel de permission approprié pour une route REST.
4. En raison de ces vérifications manquantes, un attaquant avec un compte à faible privilège peut créer une requête spécifiant l'ID d'un autre utilisateur et des clés et valeurs méta arbitraires pour modifier les métadonnées de cet utilisateur.

Pourquoi c'est dangereux

• WordPress stocke les informations de rôle dans les métadonnées utilisateur (wp_capabilities). Si la clé méta peut être modifiée, un attaquant pourrait s'accorder (ou à un autre compte) des privilèges plus élevés.
• Les métadonnées liées à la session ou à l'authentification peuvent être utilisées pour perturber ou détourner des sessions dans certaines configurations.
• Les métadonnées spécifiques aux plugins ou aux thèmes pourraient contrôler l'accès aux fonctionnalités — les mettre à jour peut contourner les restrictions.
• À grande échelle, des attaquants automatisés pourraient énumérer les ID d'utilisateur et tenter de manipuler des valeurs clés sur de nombreux sites.

Avertissement important : La possibilité pour un attaquant d'escalader complètement les privilèges dépend des clés méta qui sont modifiables via le point de terminaison vulnérable. Sur de nombreux sites, changer directement les tableaux de capacités sérialisés (wp_capabilities) ne connectera pas automatiquement l'utilisateur ou ne rafraîchira pas les capacités mises en cache à moins que les sessions ne soient gérées de manière permissive — mais le risque est réel et doit être pris au sérieux.

---

Impact pratique et scénarios d'attaque réalistes

Voici des exemples concrets de ce qu'un acteur malveillant pourrait tenter après avoir exploité cet IDOR :

• Escalade de privilèges :
  • Modifier le wp_capabilities méta pour un utilisateur afin d'inclure des capacités plus élevées (par exemple, faire d'un abonné un administrateur).
  • Si le site met en cache les capacités ou utilise des données de session côté serveur qui sont rechargées lors de la prochaine requête, l'escalade peut prendre effet immédiatement.
• Prise de contrôle de compte ou création de porte dérobée :
  • Injecter des méta que un plugin ou thème personnalisé utilise pour accorder l'accès à des fonctionnalités administratives cachées.
  • Modifier les méta spécifiques au plugin pour activer des fonctionnalités à distance ou changer les URL de webhook.
• Persistance et furtivité :
  • Définir des indicateurs de méta-plugin qui mettent sur liste blanche les IP des attaquants ou désactivent certaines vérifications de sécurité.
  • Ajouter des métadonnées ayant l'apparence inoffensive qui seront ensuite utilisées comme déclencheur de porte dérobée.
• Exploitation de masse :
  • Un compte à faible privilège avec des requêtes automatisées peut tenter l'exploitation contre plusieurs identifiants d'utilisateur pour attaquer rapidement de nombreux sites.

Comme scénario d'exemple :

1. L'attaquant enregistre un compte de site (ou utilise des comptes d'abonnés achetés).
2. Ils émettent des requêtes HTTP vers le point de terminaison vulnérable avec user_id=1 (le principal administrateur) et meta_key=wp_capabilities, meta_value={"administrator":true}.
3. En fonction de la mise en cache et de la gestion des sessions du site, le site pourrait maintenant traiter un compte comme un administrateur — ou un attaquant utilise une technique secondaire pour activer ce rôle.
4. Avec un accès administrateur, l'attaquant peut créer des portes dérobées, créer de nouveaux utilisateurs administrateurs, installer des plugins malveillants ou exfiltrer des données.

Toutes les tentatives d'exploitation ne donnent pas accès à l'administrateur, mais même la modification de méta inférieure peut conduire à l'exécution de code ou à l'exposition de données en fonction de la configuration du site.

---

Comment détecter l'exploitation et les indicateurs de compromission (IoCs)

Si vous répondez à cette vulnérabilité ou vérifiez si votre site a été affecté, voici des étapes de détection pratiques et des IoCs :

Journaux du serveur et modèles de requêtes :

• Recherchez des requêtes POST vers des points de terminaison REST ou des URL admin-ajax associées au plugin (recherchez dans les journaux d'accès “mstore” ou pour des requêtes contenant des paramètres suspects comme ID de l'utilisateur et meta_clé).
• Des requêtes répétées du même compte à faible privilège vers des points de terminaison usermeta-update.
• Requêtes POST inattendues provenant de comptes d'abonnés authentifiés.

Indicateurs de base de données :

• Changements inattendus dans les entrées usermeta (en particulier wp_capabilities, wp_user_level, clés spécifiques au plugin).
• Nouvelles valeurs méta au niveau administrateur ou valeurs modifiées datées à des moments corrélant avec des demandes suspectes.

Indicateurs au niveau de WordPress :

• Nouveaux comptes administrateurs que vous n'avez pas créés.
• Changements dans les rôles d'utilisateur existants (vérifiez la liste des utilisateurs pour des administrateurs inattendus).
• Changements de paramètres de plugin inexpliqués.

Exemple de requête MySQL pour trouver des changements récents à wp_usermeta (ajustez pour votre préfixe de table et votre colonne de timestamp si vous utilisez un journal transactionnel) :

SELECT user_id, meta_key, meta_value;

(Si vous avez des sauvegardes de base de données, comparez une sauvegarde antérieure à la vulnérabilité avec l'état actuel pour voir ce qui a changé.)

Indicateurs du système de fichiers :

• Nouveaux fichiers dans wp-content/uploads ou répertoires de plugins créés par des actions au niveau administrateur.
• Fichiers de plugin ou de thème modifiés autour du moment de l'exploitation suspectée.

Conseils de surveillance et de journalisation :

• Activez la journalisation détaillée des requêtes pour les chemins admin/API pendant une courte période si possible.
• Activez la journalisation des audits (des plugins existent à cet effet) pour voir qui a changé quoi et quand.
• Si vous utilisez une journalisation centralisée (ELK, Splunk), recherchez des motifs comme “update_user_meta” étant invoqué à distance.

---

Actions immédiates (atténuations à court terme)

Si vous découvrez que votre site exécute une version affectée de MStore API (<=4.18.3), suivez ces étapes immédiates, dans l'ordre :

1. Mettez à jour le plugin vers 4.18.4 ou une version ultérieure (le correctif publié). C'est la solution définitive.
2. Si vous ne pouvez pas effectuer la mise à jour immédiatement :
   • Désactivez temporairement le plugin jusqu'à ce que vous puissiez appliquer la version corrigée.
   • Si la désactivation n'est pas possible, bloquez l'accès aux points de terminaison vulnérables au niveau du serveur web (nginx/Apache) ou au niveau du WAF.
3. Réinitialiser les identifiants et les sessions :
   • Forcer la réinitialisation du mot de passe pour les comptes administrateurs (ou tous les comptes si vous soupçonnez un abus généralisé).
   • Invalider les sessions des utilisateurs (par exemple, changer le sel d'authentification ou utiliser un plugin qui force la déconnexion de toutes les sessions).
4. Auditer les rôles des utilisateurs et les métadonnées des utilisateurs :
   • Vérifiez que wp_capabilities et wp_user_level les entrées sont correctes.
   • Révoquer tout compte administrateur nouvellement créé que vous n'avez pas autorisé.
5. Scanner à la recherche de webshells et de fichiers malveillants :
   • Effectuez une analyse complète du site à la recherche de logiciels malveillants et une vérification de l'intégrité des fichiers.
6. Examiner les journaux pour une activité suspecte et les collecter pour un examen judiciaire.
7. Envisager de restaurer à partir d'une sauvegarde propre si vous confirmez une intrusion et ne pouvez pas remédier complètement.

Atténuations WAF à court terme (si la mise à jour n'est pas possible immédiatement) :

• Bloquer les requêtes POST/PUT vers la route REST du plugin ou l'action admin-ajax.
• Restreindre les requêtes vers ces points de terminaison aux IP de confiance (pas idéal pour les API publiques, mais utile comme atténuation temporaire).
• Rejeter les requêtes qui définissent ou incluent des paramètres liés aux métadonnées provenant de comptes à faibles privilèges.

---

Solutions à long terme et pratiques de codage sécurisé

Pour les auteurs et développeurs de plugins, éviter les problèmes IDOR en suivant ces règles :

1. Toujours appliquer des vérifications de permission :

   register_rest_route( 'mstore-api/v1', '/update_user_meta', array(;
   

   Au lieu de cela, dans le rappel, vérifiez :

   if ( ! current_user_can( 'edit_user', $user_id ) ) {
   

2. Restreindre les clés de métadonnées qui peuvent être écrites :

   $allowed_meta_keys = array( 'phone_number', 'shipping_address' );
   

3. Assainir et valider l'entrée :
   • Utiliser assainir_champ_texte(), wp_verify_nonce(), et une désinfection appropriée au type.
   • Évitez d'écrire directement des tableaux sérialisés reçus du client.
4. Évitez d'utiliser des identifiants d'utilisateur fournis par l'utilisateur sans vérifications :
   • Si une action ne doit affecter que l'utilisateur actuellement authentifié, n'acceptez pas un ID de l'utilisateur paramètre du tout.
5. Utilisez des nonces ou d'autres jetons anti-CSRF pour les points de terminaison AJAX et permission_callback pour REST.
6. Enregistrez les actions administratives :
   • Conservez une trace d'audit pour tous les changements de rôles d'utilisateur et de champs méta clés.

Si vous maintenez un plugin, effectuez des revues de code en mettant l'accent sur le contrôle d'accès, et effectuez un scan automatisé pour détecter des modèles dangereux (appels de mettre_à_jour_meta_utilisateur , vérifications de capacité manquantes, etc.).

---

Renforcer votre site WordPress pour réduire les risques futurs

Au-delà du patchage de ce plugin spécifique, appliquez ces mesures pour réduire l'exposition dans votre pile WordPress :

• Gardez le cœur de WordPress, les thèmes et les plugins à jour selon un calendrier régulier.
• Limitez les comptes administratifs et évitez d'utiliser le nom d'utilisateur par défaut “admin”.
• Mettez en œuvre une authentification à deux facteurs (2FA) pour tout compte avec des privilèges élevés.
• Appliquez des politiques de mot de passe fortes et envisagez l'expiration des mots de passe pour les administrateurs.
• Utilisez un WAF géré qui peut appliquer des correctifs virtuels / ensembles de règles pour bloquer les tentatives d'exploitation même avant qu'une mise à jour ne soit appliquée.
• Désactivez ou protégez les points de terminaison REST et admin-ajax qui ne sont pas nécessaires pour un accès public.
• Examinez régulièrement les autorisations des plugins et supprimez les plugins inutilisés.
• Mettez en œuvre des restrictions de rôle et de capacité : utilisez des rôles personnalisés avec précaution et évitez les capacités élevées par utilisateur lorsque cela n'est pas nécessaire.
• Activez la journalisation et configurez des alertes pour les événements administratifs suspects (nouveaux utilisateurs administrateurs, changements de capacités, activations de plugins).

---

Liste de contrôle de réponse aux incidents (étape par étape)

Si vous soupçonnez que votre site a été ciblé par cette vulnérabilité :

1. Mettez le site en mode maintenance (si nécessaire) pour arrêter les modifications en cours.
2. Mettez à jour le plugin MStore API vers 4.18.4 (ou désactivez-le) immédiatement.
3. Créez un instantané d'analyse judiciaire :
   • Exportez les journaux, le dump de la base de données et les listes de fichiers pour analyse.
4. Les secrets de la rotation :
   • Changez tous les mots de passe des utilisateurs administrateurs.
   • Réinitialisez les clés API, les jetons OAuth et les webhooks utilisés par les plugins.
5. Forcez la déconnexion des sessions :
   • Utilisez un plugin ou une méthode programmatique pour invalider les sessions existantes pour tous les utilisateurs, ou au moins pour les comptes administrateurs.
6. Scannez à la recherche de logiciels malveillants et de webshells, en vous concentrant sur les répertoires wp-content, wp-includes et uploads.
7. Audit wp_usermeta pour des modifications suspectes.
8. Supprimez les utilisateurs administrateurs non autorisés et restaurez les rôles corrects pour tous les comptes modifiés.
9. Si un accès administratif a été obtenu, vérifiez les installations de plugins/thèmes non autorisées et les portes dérobées.
10. Restaurez à partir d'une sauvegarde propre si une récupération complète est nécessaire et que vous ne pouvez pas garantir l'intégrité du système autrement.
11. Redéployez avec des mesures de renforcement en place : mots de passe forts, 2FA, plugins mis à jour et règles WAF.
12. Signalez l'incident à tous les partenaires/parties prenantes et documentez les étapes de remédiation.

---

Comment WP-Firewall peut aider à sécuriser votre site maintenant

Chez WP-Firewall, nous recommandons une approche de défense en profondeur. Notre plateforme est conçue pour les propriétaires de sites WordPress qui ont besoin d'une protection rapide et efficace contre les vulnérabilités des plugins comme l'IDOR de l'API MStore.

Ce que WP-Firewall fournit et qui aide dans ce scénario :

• WAF géré : des règles qui peuvent être déployées rapidement pour bloquer les modèles d'exploitation connus et les requêtes REST/AJAX qui ciblent les points de terminaison de plugins vulnérables.
• Patching virtuel : atténuation temporaire qui bloque le modèle d'exploitation à la périphérie même avant que vous puissiez mettre à jour un plugin (utile lorsque la mise à jour immédiate ou le test n'est pas possible).
• Scanner de logiciels malveillants : trouve rapidement des fichiers suspects et des indicateurs de compromission afin que vous puissiez déterminer si un attaquant a escaladé.
• Surveillance des rôles et des activités : journaux et alertes pour les changements de rôle utilisateur et les mises à jour méta suspectes.
• Analyse automatisée des risques OWASP Top 10 : réduit la probabilité de manquer des points de terminaison de plugin non sécurisés.
• Flux de travail d'auto-atténuation pour les modèles d'exploitation courants — vous permettant de répondre plus rapidement avec moins d'étapes techniques.

Nous construisons nos protections en tenant compte des incidents du monde réel. Si vous gérez plusieurs sites, les règles gérées de WP-Firewall et le patching virtuel vous permettent de les protéger tous rapidement pendant que vous testez et déployez des mises à jour de plugins.

---

Sécurisez votre site avec WP-Firewall Basic (Gratuit)

Protégez votre site dès maintenant — Commencez avec WP-Firewall Basic (Gratuit)

Si vous souhaitez une protection de base immédiate pendant que vous évaluez et corrigez les plugins, WP-Firewall Basic est une excellente première étape. Le plan Basic (Gratuit) offre :

• Protection essentielle : pare-feu géré, bande passante illimitée, WAF, scanner de logiciels malveillants et atténuation des 10 principaux risques OWASP.

Il est conçu pour vous fournir une protection immédiate et continue contre les menaces WordPress typiques — y compris le patching virtuel qui peut bloquer les tentatives d'exploitation contre les points de terminaison de plugin exposés. Si vous avez besoin de fonctionnalités supplémentaires comme la suppression automatique de logiciels malveillants, le contrôle de liste noire/blanche IP, ou des rapports de sécurité mensuels, nos plans payants permettent des mises à niveau sans douleur.

Commencez rapidement en vous inscrivant à WP-Firewall Basic (Gratuit) : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Nous recommandons d'activer le plan gratuit immédiatement puis d'appliquer la mise à jour du plugin. La combinaison de patching virtuel + correction de la cause profonde vous donne la meilleure protection à court et à long terme.)

---

Annexe : exemples de règles WAF recommandées et extraits de code sûrs

A. Exemples de règles de blocage WAF (conceptuel ; adaptez à votre moteur WAF)

• Bloquer les requêtes vers une route REST vulnérable provenant d'utilisateurs authentifiés à faible privilège :

  Règle : Si le chemin de la requête correspond ^/wp-json/mstore-api/v1/update_user_meta et que la méthode de requête est POST et que la requête n'inclut pas un en-tête ou un jeton valide émis par le site OU que le rôle authentifié est abonné => bloquer.

• Bloquer le modèle d'exploitation admin-ajax :

  Règle : Si POST à /wp-admin/admin-ajax.php avec action=mstore_update_meta et meta_clé paramètre présent et que le rôle utilisateur est abonné => bloquer.

• Remarque : Les règles WAF précises dépendent de votre syntaxe WAF et de la possibilité d'inspecter le rôle authentifié dans les en-têtes. Si le rôle n'est pas disponible pour le WAF, bloquez ou limitez les combinaisons de paramètres suspectes et forcez reCAPTCHA / challenge.

B. Exemple : Vérification des autorisations sécurisées pour la route REST dans WordPress

function mstore_register_routes() {

C. Exemple : Plugin mu rapide pour désactiver une route REST de plugin spécifique jusqu'à ce que vous puissiez mettre à jour

<?php;

Il s'agit d'une atténuation temporaire — retirez le plugin mu uniquement après avoir mis à jour vers une version de plugin sécurisée.

---

Derniers mots de l'équipe de sécurité de WP-Firewall

Les vulnérabilités comme IDOR sont courantes lorsque les plugins exposent des identifiants d'objet et ne font pas respecter des permissions strictes. L'IDOR de l'API MStore (CVE-2026-3568) rappelle que même les classifications de faible gravité peuvent représenter un risque significatif dans certains environnements. La remédiation la plus sûre et la plus rapide est de mettre à jour vers la version corrigée (4.18.4) dès que possible.

Si vous gérez plusieurs sites WordPress ou hébergez des sites pour des clients, envisagez une approche en couches : maintenez les logiciels à jour, utilisez le renforcement des sessions et des rôles, et disposez d'un WAF de niveau périphérique qui peut appliquer des correctifs virtuels et bloquer les modèles d'exploitation. Le plan de base (gratuit) de WP-Firewall est conçu pour vous fournir rapidement ces protections essentielles pendant que vous planifiez et appliquez des corrections à long terme.

Prenez la mesure immédiate : vérifiez vos versions de plugin, mettez à jour l'API MStore vers 4.18.4 ou une version ultérieure, et activez la protection qui bloquera les tentatives d'exploitation pendant que vous effectuez des audits et des récupérations. Si vous souhaitez un point de départ facile, WP-Firewall Basic peut être actif en quelques minutes : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Si vous avez besoin d'aide pour examiner les journaux, élaborer des règles WAF pour votre environnement ou effectuer un examen forensic complet après une activité suspecte, notre équipe de sécurité est disponible pour vous aider.

Soyez prudent,
Équipe de sécurité WP-Firewall

---

Références et ressources (pour les administrateurs)

• CVE-2026-3568 (IDOR de l'API MStore) — vérifiez dans les listes CVE pour plus de détails.
• Documentation des développeurs WordPress : register_rest_route(), current_user_can(), nonces, vérifications de capacité.
• La documentation de WP-Firewall et les guides de démarrage rapide sont disponibles après inscription.