Sécurité

En savoir plus à propos de la sécurité du cœur de WordPress dans ce livre blanc. Vous pouvez aussi le télécharger au format PDF (version anglaise).

Vue d’ensemble

Ce document est une analyse et une explication du développement du cœur de WordPress et des processus de sécurité liés, ainsi qu’un examen de la sécurité inhérente du logiciel. Les décisionnaires qui souhaitent évaluer WordPress en tant que système de gestion de contenu ou de framework d’application web se doivent d’utiliser ce document dans leurs analyses et prises de décisions, autant que pour les développeurs qui doivent s’y référer pour se familiariser eux aussi aux composantes de la sécurité et des bonnes pratiques de ce logiciel.

Les informations dans ce document sont à jour pour la dernière version stable du logiciel, WordPress 4.7 au moment de la publication de ce document, mais devraient être considérées comme s’appliquant également aux autres versions récentes du logiciel, étant donné que la rétro-compatibilité est l’une des grandes priorités de l’équipe de développement. Les modifications et mesures de sécurité spécifiques seront ajoutées au fur et à mesure de leur ajout dans le cœur du logiciel, à chaque version. Il est hautement recommandé de toujours utiliser la dernière version stable de WordPress pour s’assurer d’avoir la version la plus sécurisée possible.

Synthèse

WordPress est un système open source de gestion de contenu dynamique qui est utilisé par des millions de sites web, d’applications web, et de blogs. À l’heure actuelle, il fait marcher plus de 43 % des 10 millions de sites web les plus visités sur Internet. La convivialité, l’extensibilité, et la communauté mature de développement font de WordPress un choix populaire et sûr pour les sites web de toutes tailles.

Depuis son lancement en 2003, WordPress a reçu des améliorations continues de son cœur pour parer et atténuer les menaces de sécurité, y compris les 10 risques de sécurité applicatifs web les plus critiques, telles qu’identifiées par The Open Web Application Security Project (OWASP), qui seront examinées dans ce document.

L’équipe de sécurité de WordPress, en collaboration avec l’équipe qui mène le développement du cœur de WordPress et avec le soutien de l’ensemble de la communauté WordPress, travaille à l’identification et à la résolution des problèmes de sécurité dans le cœur du logiciel actuellement disponible en téléchargement sur WordPress.org. Elle recommande et documente également les bonnes pratiques de sécurité pour les auteurs d’extensions et de thèmes.

Les développeurs/développeuses et administrateurs/administratrices de sites doivent prêter une attention toute particulière à l’utilisation correcte des API (interfaces de programmation) du cœur et de la configuration du serveur sous-jacent qui sont une source courante de vulnérabilités, tout en s’assurant que tous leurs comptes utilisent des mots de passe forts pour accéder à l’administration de WordPress.

Une vue d’ensemble de WordPress

WordPress est un système de gestion de contenus (CMS) libre et ouvert. C’est le CMS le plus utilisé dans le monde et il propulse plus de 43 % des 10 millions de sites web les plus utilisés¹, ce qui équivaut à 62 % de tous les sites qui utilisent un CMS.

WordPress est sous Licence Publique Générale (GPLv2 ou ultérieure) qui fournit quatre libertés fondamentales. Considérez cela comme la « Charte des droits de WordPress » :

La liberté d’exécuter le programme, pour n’importe quel but.
La liberté d’étudier comment fonctionne le programme, et de le changer pour qu’il fasse ce que vous souhaitez.
La liberté de redistribuer.
La liberté de distribuer à d’autres des copies de vos versions modifiées.

L’équipe de direction du cœur WordPress

Le projet WordPress est une méritocratie, conduit par une équipe de direction, et mené par son co-créateur et développeur principal, Matt Mullenweg. Cette équipe régit tous les aspects du projet, incluant le développement du cœur, WordPress.org, et les initiatives communautaires.

L’équipe principale des développeurs du cœur est constituée de Matt Mullenweg, de cinq développeurs en chef, et de plus d’une douzaine de développeurs qui ont un accès permanent à la publication de modifications. Ces développeurs ont l’autorité finale sur les décisions techniques, et guident les discussions architecturales et les travaux d’implémentation.

WordPress a de nombreux développeurs contributeurs. Certains d’entre eux sont d’anciens ou d’actuels « committers » (personnes habilités à modifier le code), d’autres sont de potentiels futurs « committers ». Ces développeurs sont des contributeurs dignes de confiance et expérimentés, qui ont gagné le respect de leurs pairs. En fonction des besoins, WordPress a aussi des « committers » invités, c’est-à-dire des développeurs a qui on a donné un accès au code de manière temporaire ou comme test, quelquefois juste pour une composante spécifique.

Les développeurs du cœur et les contributeurs principaux guident le développement de WordPress. À chaque version, des centaines de développeurs contribuent au code de WordPress. Ces contributeurs sont des volontaires qui contribuent au code du cœur d’une manière ou d’une autre.

Le cycle des versions de WordPress

Chaque cycle de publication de WordPress est dirigé par un ou plusieurs développeurs principaux. Un cycle de publication dure habituellement 4 mois à partir de la réunion initiale de lancement de cette version.

Un cycle de sortie suit le schéma suivant² :

Phase 1 : Élaborer et fixer les chefs d’équipes. Cela se fait dans le canal de discussion #core sur Slack. Le chef de projet de cette version discute des fonctionnalités pour la prochaine version de WordPress. Les contributeurs participent à cette discussion. Le chef de projet fixera les chefs d’équipes pour chaque fonctionnalité.
Phase 2 : Le travail de développement commence. Les chefs d’équipe rassemblent leurs membres et travaillent sur les fonctionnalités qui leur sont assignées. Des discussions régulières sont planifiées pour assurer que le développement avance correctement.
Phase 3 : Bêta. Des versions bêtas sont publiées, et il est demandé aux bêta-testeurs de signaler les bogues découverts. Aucune nouvelle modification du code impliquant un nouveau comportement ou une nouvelle fonctionnalité n’est prise en compte durant cette phase. Les auteurs d’extensions tierces et de thèmes sont encouragés à tester leur code en prévision des changements à venir.
Phase 4 : Version admissible (Release Candidate ou RC). Il y a ici un gel des chaînes qui doivent être traduites. Les développeurs de focalisent uniquement sur les régressions et bogues bloquants.
Phase 5 : Lancement. La version WordPress est publiée et rendue disponible dans l’administration de WordPress pour les mises à jour.

Numérotation et versions de sécurité

Une version majeure de WordPress est déterminée par les deux premières séquences. Par exemple, 3.5 est une version majeure, tout comme 3.6, 3.7 ou 4.0. Il n‘y a pas de « WordPress 3 » ou « WordPress 4 », et chaque version majeure est désignée par sa numérotation, p. ex. « WordPress 3.9 ».

Les versions majeures peuvent ajouter de nouvelles fonctionnalités pour les utilisateurs/utilisatrices et des API pour les développeurs/développeuses. Bien que dans le monde du logiciel, une version « majeure » signifie généralement que la compatibilité ascendante peut être rompue, WordPress s’efforce de ne jamais rompre la compatibilité ascendante. La compatibilité ascendante est l’une des philosophies les plus importantes du projet, dans le but de faciliter considérablement les mises à jour pour les utilisateurs/utilisatrices et les développeurs/développeuses.

Une version mineure de WordPress est définie par le troisième chiffre. La version 3.5.1 est une version mineure, tout comme la version 3.4.2³. Une version mineure est réservée pour corriger des failles de sécurité et ne traiter uniquement que les bogues critiques. Étant donné que les nouvelles versions de WordPress sont publiées très fréquemment – l‘objectif est de publier une version majeure tous les 4 à 5 mois, et les versions mineures sont publiées en fonction des besoins – il n‘y a besoin que de versions majeures et mineures.

Rétrocompatibilité des versions

Le projet WordPress s’engage fortement sur la compatibilité ascendante. Cet engagement fait que les thèmes, extensions, et le code personnalisé continuent de fonctionner quand le cœur de WordPress est mis à jour, ce qui encourage les propriétaires de sites à garder leur version de WordPress à jour avec les dernières publications de sécurité.

WordPress et la sécurité

L’équipe de sécurité de WordPress

L‘équipe de sécurité de WordPress est composée d‘une cinquantaine d‘experts, dont des développeurs/développeuses principaux et des chercheurs en sécurité — environ la moitié d‘entre eux sont des employés d‘Automattic (makers de WordPress.com, la première et la plus grande plateforme d‘hébergement WordPress sur le web), et un certain nombre travaillent dans le domaine de la sécurité sur le web. L‘équipe consulte des chercheurs en sécurité et des entreprises d‘hébergement réputés et dignes de confiance³.

L‘équipe de sécurité de WordPress collabore souvent avec d‘autres équipes de sécurité pour résoudre des problèmes dans des dépendances communes, comme la résolution de la vulnérabilité dans l‘analyseur XML de PHP, utilisé par l‘API XML-RPC fournie avec WordPress, dans WordPress 3.9.2.⁴. La résolution de cette vulnérabilité est le résultat d‘un effort conjoint des équipes de sécurité de WordPress et de Drupal.

Risques, processus et historique de la sécurité de WordPress

L‘équipe de sécurité de WordPress croit en la divulgation responsable en alertant immédiatement l‘équipe de sécurité de toute vulnérabilité potentielle. Les vulnérabilités potentielles peuvent être signalées à l‘équipe de sécurité via WordPress HackerOne⁵. L‘équipe de sécurité communique entre elle via un canal Slack privé, et travaille sur un Trac privé et cloisonné pour suivre, tester et corriger les bogues et les problèmes de sécurité.

Chaque rapport de sécurité fait l’objet d’un accusé en réception, puis l’équipe vérifie la vulnérabilité et détermine sa sévérité. Si elle est confirmée, l’équipe de sécurité prévoit alors un correctif pour résoudre le problème qui peut être validé pour une prochaine version de WordPress ou qui peut être poussé immédiatement en version de sécurité, selon la sévérité du problème.

Pour une version de sécurité immédiate, un avis est publié par l’équipe de sécurité sur le site WordPress.org News⁶ annonçant la version et détaillant les modifications. Le crédit pour la divulgation responsable d’une vulnérabilité est donné dans l’avis afin d’encourager et de renforcer le signalement responsable à l’avenir.

Les personnes administrant des sites WordPress reçoivent une notification de disponibilité d’une mise à jour sur le tableau de bord de leurs sites lors de la sortie d’une nouvelle version. Une fois la mise à jour appliquée, les gens sont redirigés sur l’écran « À propos » de WordPress qui détaille l’ensemble des modifications. Si les personnes administrant le site ont activé les mises à jour automatiques en tâche de fond, elles recevront un e-mail après que la mise à jour ait été faite.

Mises à jour automatiques en arrière-plan pour les sorties de sécurité

À partir de la version 3.7, WordPress a introduit des mises à jour automatiques en arrière-plan pour toutes les versions mineures⁷, telles que 3.7.1 et 3.7.2. L‘équipe de sécurité de WordPress peut identifier, corriger et déployer automatiquement des améliorations de sécurité pour WordPress sans que le propriétaire du site ait besoin de faire quoi que ce soit de son côté, et la mise à jour de sécurité s‘installera automatiquement.

Quand une mise à jour de sécurité est poussée pour la version stable courante de WordPress, l’équipe chargée du cœur WP poussera aussi des mises à jour de sécurité pour toutes les versions où les mises à jour en arrière-plan sont possibles (depuis WordPress 3.7), ainsi ces versions plus anciennes de WordPress pourront recevoir les améliorations de sécurité.

Les propriétaires de sites individuels peuvent opter pour le retrait des mises à jour automatiques en arrière-plan en modifiant simplement leur fichier de configuration, mais conserver cette fonctionnalité est fortement recommandé par l’équipe chargée du cœur WP, de même que l’utilisation de la dernière version stable de WordPress.

Le top 10 OWASP en 2013

Le projet Open Web Application Security Project (OWASP) est une communauté en ligne dédiée à la sécurité des applications web. La liste des 10 principales vulnérabilités d’OWASP⁸ vise à identifier les risques de sécurité des applications les plus graves pour un large éventail d‘organisations. Les 10 éléments sont sélectionnés et priorisés en combinaison avec des estimations consensuelles de l’exploitabilité, de la détectabilité et des impacts.

Les sections suivantes traitent des API, des ressources et des politiques que WordPress utilise pour renforcer le cœur du logiciel et les extensions et thèmes tiers contre ces risques potentiels.

A1 – Injection

Il existe un ensemble de fonctions et d’API disponibles dans WordPress pour aider les développeurs/développeuses à s’assurer qu’aucun code non autorisé ne peut être injecté et les aider à valider et à nettoyer les données. Des bonnes pratiques et de la documentation sont disponibles⁹ sur la manière d’utiliser ces API pour protéger, valider ou nettoyer les données en entrée et en sortie dans le HTML, les URL, les entêtes HTTP, et lors de l’interaction avec la base de données et le système de fichiers. Les administrateurs/administratrices peuvent également restreindre davantage les types de fichiers qui peuvent être téléversés via des filtres.

A2 – Authentification cassée et gestion des sessions

Le cœur du logiciel WordPress gère l’authentification et les comptes ainsi que des informations telles que l’identifiant, le nom et le mot de passe qui sont gérées à la fois côté serveur ou via les cookies d’authentification. Les mots de passe sont protégés en base de données avec des clés de salages et des techniques standardisées. Les sessions existantes sont détruites après déconnexion pour les versions de WordPress supérieures à 4.0.

A3 – Script de site à site (Cross-Site Scripting ou XSS).

WordPress propose une gamme de fonctions qui peuvent aider à garantir que les données fournies par quiconque sont sécurisées¹⁰. Les utilisateurs/utilisatrices de confiance, c’est-à-dire les administrateurs/administratrices et éditeurs/éditrices sur une seule installation de WordPress, et uniquement les admin réseau dans le cas de multisite WordPress, peuvent publier du code HTML ou JavaScript non filtré selon leurs besoins, par exemple à l’intérieur d’une publication ou d’une page. Les comptes non fiables et le contenu envoyé par les internautes sont filtrés par défaut pour retirer les entités dangereuses, en utilisant la bibliothèque KSES via la fonction wp_kses.

À titre d’exemple, l’équipe du cœur de WordPress a remarqué avant la sortie de WordPress 2.3 que la fonction the_search_query() était mal utilisée par la plupart des auteurs/autrices de thèmes, qui n’échappaient pas la sortie de la fonction pour une utilisation dans le HTML. Dans un cas très rare de légère rupture de compatibilité ascendante, la sortie de la fonction a été modifiée dans WordPress 2.3 pour être pré-échappée.

A4 – Référence d’objet direct non sécurisé

WordPress fournit souvent une référence d’objet directe, telle que des identifiants numériques uniques des comptes d’utilisateurs/utilisatrices ou du contenu disponibles dans l’URL ou les champs de formulaire. Bien que ces identifiants divulguent des informations directes sur le système, le système riche de droits et de contrôle d’accès de WordPress empêche les demandes non autorisées.

A5 – Mauvaise configuration de la sécurité

La majorité des opérations de configuration de sécurité de WordPress sont limitées à un seul administrateur/administratrice autorisé. Les réglages par défaut de WordPress sont continuellement évalués au niveau de l’équipe du cœur, et l’équipe du cœur de WordPress fournit de la documentation et des meilleures pratiques pour renforcer la sécurité de la configuration du serveur pour faire fonctionner un site WordPress¹¹.

A6 – Exposition des données sensibles

Les mots de passe des comptes WordPress sont salés et hashés en fonction du Portable PHP Password Hashing Framework¹². Le système de droits de WordPress est utilisé pour contrôler l‘accès aux informations privées telles que les informations personnelles identifiables (PII) des comptes enregistrés, les adresses e-mail des commentateurs et commentatrices, le contenu publié de manière privée, etc. Dans WordPress 3.7, un indicateur de force de mot de passe a été inclus dans le cœur du logiciel, fournissant des informations supplémentaires aux utilisateurs et utilisatrices définissant leurs mots de passe et des conseils pour augmenter leur force. WordPress dispose également d‘un réglage de configuration facultatif pour exiger le HTTPS.

A7 – Missing Function Level Access Control

WordPress contrôle les autorisations et les droits appropriés pour toute demande d’accès à une fonction de tout niveau avant que l’action ne soit exécutée. L’accès ou l’affichage d’URL d’administration, de menus et de pages sans authentification appropriée est étroitement intégré au système d’authentification afin d’empêcher l’accès aux personnes non autorisés.

A8 – Cross Site Request Forgery (CSRF)

WordPress utilise des jetons cryptographiques, appelés nonces¹³, pour valider l‘intention des demandes d‘action des utilisateurs et utilisatrices autorisé·es afin de se protéger contre les menaces CSRF potentielles. WordPress fournit une API pour la génération de ces jetons afin de créer et de vérifier des jetons uniques et temporaires, et le jeton est limité à un compte spécifique, une action spécifique, un objet spécifique et une période de temps spécifique, qui peuvent être ajoutés aux formulaires et aux URL selon les besoins. En outre, tous les nonces sont invalidés lors de la déconnexion.

A9 – Utilisation de composants présentant des vulnérabilités connues

L‘équipe du cœur de WordPress surveille de près les quelques bibliothèques et frameworks inclus avec lesquels WordPress s‘intègre pour les fonctionnalités de base. Dans le passé, l‘équipe du cœur a contribué à plusieurs composants tiers pour les rendre plus sûrs, comme la mise à jour pour corriger une vulnérabilité intersite dans TinyMCE dans WordPress 3.5.2¹⁴.

Si nécessaire, l’équipe du cœur peut décider de bifurquer ou de remplacer des composants externes critiques, comme cela a été fait lorsque la bibliothèque SWFUpload a été officiellement remplacée par la bibliothèque Plupload dans la version 3.5.2, et une version sécurisée de SWFUpload a été mise à disposition par l’équipe de sécurité¹⁵ pour les extensions qui continuaient à utiliser SWFUpload à court terme.

A10 – Redirections et transferts non validés

Le système interne de contrôle d‘accès et d‘authentification de WordPress protège contre les tentatives de diriger les internautes vers des destinations non désirées ou des redirections automatiques. Cette fonctionnalité est également mise à la disposition des développeurs/développeuses d‘extensions via une API, wp_safe_redirect()¹⁶.

Autres risques concernant la sécurité

Attaques sur les processus XXE (XML eXternal Entity)

Lors du traitement de XML, WordPress désactive le chargement d’entités XML personnalisées pour prévenir les attaques d’entités externes et d’expansion d’entités. Au-delà de la fonctionnalité du cœur de PHP, WordPress ne fournit pas d’API de traitement XML sécurisée supplémentaire pour les auteurs/autrices des extensions.

Attaques SSRF (Server Side Request Forgery)

Les requêtes HTTP sur WordPress sont filtrées pour éviter tout retour de données et d’adresses IP privées. De plus, l’accès n’est autorisé que sur certains ports HTTP standards.

Sécurité des extensions et thèmes WordPress

Le thème par défaut

WordPress requiert qu’un thème soit activé pour afficher le contenu visible sur l’interface publique. Le thème par défaut livré avec le cœur de WordPress (actuellement « Twenty Twenty-Three ») a été rigoureusement examiné et testé pour des raisons de sécurité par l’équipe de développeurs/développeuses de thèmes ainsi que par l’équipe de développement du cœur.

Le thème par défaut peut servir comme point de départ pour le développement d’un thème personnalisé et les développeurs de site peuvent créer un thème enfant incluant une certaine personnalisation mais qui s’appuie sur le thème par défaut pour la plupart des fonctionnalités et la sécurité. Le thème par défaut peut être facilement supprimé par un administrateur s’il ne s’avère pas nécessaire.

Dépôts de thèmes et d‘extensions de WordPress.org

Il y a environ +50 000 extensions et +5 000 thèmes listés sur le site WordPress.org. Ces thèmes et extensions sont envoyées pour intégrations et sont examinées manuellement par des bénévoles avant d‘être mis à disposition sur le dépôt.

L‘inclusion d‘extensions et de thèmes dans le dépôt ne garantit pas qu‘ils sont exempts de vulnérabilités en matière de sécurité. Des lignes directrices sont fournies aux auteurs/autrices d‘extensions pour qu‘ils les consultent avant l‘envoi pour inclusion dans le dépôt.¹⁷, et une documentation complète sur la façon de développer un thème WordPress¹⁸ est fournie sur le site WordPress.org.

Chaque extension ou thème est susceptible d’être amélioré par son auteur/autrice. Tous les correctifs qui en découlent ou tout développement de fonctionnalité peuvent être téléversés sur le dépôt et mis à la disposition des utilisateurs et utilisatrices ayant installé cette extension ou ce thème, avec une description de ce changement. Les administrateurs et administratrices du site sont informés des extensions qui doivent être mises à jour via le tableau de bord de leur interface d’administration.

Quand l’équipe sécurité de WordPress découvre une vulnérabilité dans une extension, elle contacte son auteur·e pour qu’ils travaillent ensemble afin de la corriger et de publier une version sécurisée. Si l’auteur de l’extension ne répond pas ou lorsque la faille de sécurité est grave, l’extension/le thème est retiré du répertoire public et, dans certains cas, corrigé et mis à jour par l’équipe de sécurité.

L’équipe de validation des thèmes (Theme Review Team)

L‘équipe de revue des thèmes (Theme Review) est un groupe de volontaires, dirigé par des membres importants et établis de la communauté WordPress, qui révise et approuve les thèmes envoyés pour être inclus dans le répertoire officiel des thèmes WordPress. L‘équipe de revue des thèmes (Theme Review) maintient les directives officielles de revue des thèmes.¹⁹, les données du test unitaire des thèmes²⁰, et l‘extension Theme Check²¹, et tente d‘engager et d‘éduquer la communauté des développeurs/développeuses de thèmes WordPress en ce qui concerne les meilleures pratiques de développement. L‘inclusion dans le groupe est modérée par les committeurs/committeuses du cœur de l‘équipe de développement de WordPress.

Le rôle du fournisseur d’hébergement dans la sécurisation de WordPress

WordPress peut être installé sur une multitude de plates-formes. Bien que le logiciel du noyau de WordPress fournisse de nombreuses dispositions pour exploiter une application Web sécurisée, qui ont été couvertes dans ce document, la configuration du système d’exploitation et du serveur Web sous-jacent hébergeant le logiciel est tout aussi importante pour préserver la sécurité des applications WordPress.

Une note à propos de WordPress.com et de la sécurité de WordPress

WordPress.com est la plus grande installation WordPress au monde et est détenue et gérée par Automattic, Inc., fondée par Matt Mullenweg, le co-créateur du projet WordPress. WordPress.com utilise le logiciel cœur de WordPress et possède ses propres processus de sécurité, risques et solutions²². Ce document concerne la sécurité liée au logiciel WordPress open source téléchargeable et auto-hébergé disponible sur WordPress.org et installable sur n’importe quel serveur dans le monde.

Annexe

API du cœur WordPress

L‘interface de programmation d‘application (API) principale de WordPress est composée de plusieurs API individuelles²³, chacune couvrant les fonctions impliquées dans l‘utilisation d‘un ensemble de fonctionnalités données. Ensemble, elles forment l‘interface du projet qui permet aux extensions et aux thèmes d‘interagir, de modifier et d‘étendre de manière sécurisée la fonctionnalité principale du cœur de WordPress.

Avec chaque API WordPress, des bonnes pratiques standardisées sont fournies pour interagir et étendre le cœur du logiciel WordPress. Les API suivantes sont les plus importantes pour renforcer la sécurité de WordPress :

API Database

L’API de la base de données²⁴, ajoutée dans WordPress 0.71, fournit la méthode correcte pour accéder aux données sous forme de valeurs nommées qui sont stockées dans la couche de base de données.

API Filesystem

L‘API Filesystem²⁵, ajoutée dans WordPress 2.6²⁶, a été créée à l‘origine pour la fonction de mise à jour automatique de WordPress. L‘API du système de fichiers fait abstraction de la fonctionnalité nécessaire pour lire et écrire des fichiers locaux dans le système de fichiers de manière sécurisée, sur une variété de types d‘hébergeurs.

Il le fait à travers la classe WP_Filesystem_Base et plusieurs sous-classes qui implémentent différentes façons de se connecter au système de fichiers local, en fonction du support individuel de l‘hébergeur. Tout thème ou extension qui a besoin d‘écrire des fichiers localement doit le faire en utilisant la famille de classes WP_Filesystem.

HTTP API

L‘API HTTP²⁷, ajoutée dans WordPress 2.7²⁸ et étendue dans WordPress 2.8, standardise les requêtes HTTP pour WordPress. L‘API gère les cookies, l‘encodage et le décodage gzip, le décodage de chunk (si HTTP 1.1), et diverses autres implémentations du protocole HTTP. L‘API normalise les requêtes, teste chaque méthode avant l‘envoi et, en fonction de la configuration de votre serveur, utilise la méthode appropriée pour effectuer la requête.

Les API Permissions & Current User

Les API Permissions & Current User sont un ensemble de fonctions aidant à vérifier les droits de l’utilisateur ou de l’utilisatrice courante à effectuer toute tâche ou opération demandée, et qui permettent de protéger les personnes non autorisés à accéder ou déclencher des fonctions qui ne sont pas dans leurs prérogatives.

Licence appliquable aux contenus des livres blancs

Le texte de ce document (à l‘exception du logo WordPress ou de la marque déposée) est sous licence CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. Vous pouvez copier, modifier, distribuer et exécuter l‘œuvre, même à des fins commerciales, sans demander d‘autorisation.

Remerciement spécial à Drupal security white paper, qui a fournit une inspiration.