Sécurité

Ce livre blanc gratuit vous permet d’en savoir plus sur la sécurité du cœur de WordPress. Vous pouvez aussi le télécharger au format PDF.

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.

Présentation générale

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 34% 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 et administrateurs 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 utilisateurs 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 (SGC/CMS) libre et ouvert. C’est le CMS le plus utilisé dans le monde et il propulse plus de 34 des 10 millions de sites web les plus utilisés1, ce qui équivaut à 60% de parts de marché de tous les sites qui utilisent un CMS.

WordPress est distribué sous licence GPLv2 ou + (General Public License) ce qui procure quatre libertés fondamentales, et qui peuvent être considérées comme la « Déclaration des Droits » de WordPress.

  1. La liberté d’exécuter le programme, pour n’importe quel but.
  2. La liberté d’étudier comment fonctionne le programme, et de le changer pour qu’il fasse ce que vous souhaitez.
  3. La liberté de redistribuer.
  4. 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 de publication 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.

Le cycle de publication suit le modèle suivant 2 :

  • 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 des versions et versions de sécurité

Une version majeure de WordPress se repère aux deux premières séquences de chiffres. Par exemple, la 3.5 est une version majeure, tout comme le sont la 3.6, la 3.7, ou la 4.0. Il n’y a pas de « WordPress 3 » ou de « WordPress 4 » et chaque version majeure a sa propre numérotation, par exemple « WordPress 3.9 ».

Les versions majeures peuvent ajouter de nouvelles fonctionnalités pour l’utilisateur et des APIs pour les développeurs. Bien qu’usuellement dans le monde du logiciel, une « majeure » signifie que l’on peut briser la rétrocompatibilité, WordPress s’efforce de ne jamais casser la compatibilité ascendante. La rétrocompatibilité est l’une des philosophies les plus importantes du projet, le but étant de faciliter les mises à jour aussi bien pour les utilisateurs que pour les développeurs.

Une version mineure de WordPress se repère par la troisième séquence de chiffres. La version 3.5.1 est une version mineure, tout comme la 3.4.23. Une version mineure est réservée uniquement à la résolution de problèmes de sécurité ou de bogues critiques et bloquants. Étant donné que les nouvelles versions de WordPress sont publiées très fréquemment — le but est de publier une version majeure tous les 4 à 5 mois, et les versions mineures n’arrivent qu’en cas de besoin — il n’y a de nécessité que pour les versions majeures et mineures.

Compatibilité ascendante

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 constituée d’environ 50 experts incluant des développeurs en chef et des consultants en sécurité — environ la moitié sont des employés d’Automattic (société créatrice de WordPress.com, la première et plus grande plateforme d’hébergement WordPress), et l’autre moitié est constituée de travailleurs dans le domaine de la sécurité web. Cette équipe est en relation avec des chercheurs connus dans le domaine de la sécurité ainsi qu’avec des sociétés d’hébergements3.

L’équipe de sécurité WordPress collabore souvent avec d’autres équipes de sécurité pour résoudre les problèmes dans les dépendances communes, comme la résolution de la vulnérabilité dans l’analyseur PHP XML, utilisé par l’API XML-RPC livrée avec WordPress depuis sa version 3.9.24. Cette résolution de vulnérabilité a été le résultat des efforts joints entre les équipes de sécurité de WordPress et de Drupal.

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

L’équipe de sécurité de WordPress croit en la divulgation responsable (Responsible Disclosure) par le signalement immédiat de toutes vulnérabilités potentielles. Ces éventuelles vulnérabilités peuvent être signalées à l’équipe de sécurité directement via le WordPress HackerOne5. L’équipe de sécurité communique ensuite en interne via une chaine Slack privée, et travaille à huis clos, en utilisant une installation privées de Trac pour le suivi, le test et la résolution des bogues et 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.

Lors de la sortie immédiate d’une version de sécurité, une notification est publiée par l’équipe de sécurité sur le site des annonces de WordPress.org6, présentant cette version et détaillant les modifications. Le crédit pour la divulgation responsable d’une vulnérabilité est donné dans cette annonce pour encourager et renforcer le principe de divulgation responsable pour les prochaines versions.

Les administrateurs de 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 utilisateurs sont redirigés sur l'écran « À propos » de WordPress qui détaille l’ensemble des modifications. Si les administrateurs ont activé les mises à jour automatiques en tâche de fond, ils recevront un e-mail après que la mise à jour ait été faite.

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

Depuis la version 3.7, WordPress dispose de mises à jour automatiques en tâche de fond pour toutes les versions mineures7, comme la 3.7.1 et la 3.7.2. L’équipe de sécurité de WordPress peut identifier, régler, et lancer des améliorations de sécurité pour WordPress sans même que le propriétaire du site n’ait besoin de faire quoi que ce soit, et la version de sécurité s’installera seule.

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

L’Open Web Application Security Project (OWASP) est une communauté en ligne dédiée à la sécurité des applications web. Le top 10 OWASP8 se concentre sur l'identification des plus gros risques encourus par les applications pour un large éventail d’organisations. Les éléments sont sélectionnés et hiérarchisés en combinaison avec les estimations du consensus d’estimations d’exploitabilité, de détectabilité, et d’impact.

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 y a un jeu de fonctions et d’API disponibles sur WordPress afin d’accompagner les développeurs et développeuses à s’assurer qu’aucun code non autorisé ne puisse être injecté, et pour les aider à valider et sanitiser les données. Les bonnes pratiques et la documentation sont disponibles 9 pour montrer comment protéger, valider et sanitiser les données saisies et affichées en HTML, les URL, les en-têtes HTTP, et comment interagir avec la base de données et le système de fichiers. Les administrateurs peuvent aussi restreindre les types de fichiers pouvant ê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 utilisateur ainsi que des informations telles que l’identifiant utilisateur, 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 offre un éventail de fonctions qui aident à assurer que les données fournies par l’utilisateur sont sûres10. Les utilisateurs de confiance, c’est-à-dire les administrateurs et rédacteurs sur une installation de WordPress unique, et les administrateurs de site seulement dans WordPress multisite, peuvent publier un article ou une page en utilisant du code HTML ou JavaScript non filtrés. Les utilisateurs non fiables ou le contenu publié par les utilisateurs sont filtrés par défaut pour supprimer des entités dangereuses, en utilisant la bibliothèque KSES par le biais de la fonction wp_kses.

À titre d’exemple, l’équipe de développement 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 de thème, qui n’échappaient pas les données sortantes de la fonction dans le cadre d’une utilisation dans du code HTML. C’était ici un cas très rare où la compatibilité ascendante a été légèrement cassée : 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 fait souvent référence directe à un objet, comme aux identifiants numériques uniques des comptes d'utilisateurs ou à des contenus disponibles dans l’adresse Web ou les champs des formulaires. Bien que ces identificateurs divulguent des informations directes sur le système, le système très complet d’autorisations et de contrôle d’accès au système de WordPress empêche les requêtes 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 autorisé. Les réglages par défaut de WordPress sont évalués continuellement au niveau de l’équipe, et l’équipe de développement de WordPress fournit la documentation et les meilleures pratiques pour renforcer la sécurité pour la configuration d’un serveur hébergeant un site WordPress11.

A6 - Exposition des données sensibles

Les mots de passe des comptes d’utilisateur WordPress sont salés et hashés, sur la base du framework Portable PHP Password Hashing12. Le système d’autorisation de WordPress est utilisé pour contrôler l’accès à l’information privée telles que les données personnelles d’un de ces utilisateurs enregistrés, les adresses e-mails des commentateurs, le contenu publié en privé, etc. Dans WordPress 3.7, un indicateur de sûreté de mot de passe a été inclus dans le logiciel, donnant des informations supplémentaires aux utilisateurs en train de créer leurs mots de passe, leur conseillant en substance d’augmenter la complexité de ces derniers. WordPress a également un réglage optionnel pour exiger le protocole sécurisé HTTPS.

A7 - Missing Function Level Access Control

WordPress contrôle les autorisations et les droits appropriées 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 administratives, les menus et les pages sans authentification appropriée est étroitement intégré avec le système d’authentification pour empêcher l’accès des utilisateurs non autorisés.

A8 - Cross Site Request Forgery (CSRF)

WordPress utilise des jetons cryptographiques, appelés nonces13, pour valider l'intention des demandes d’action des utilisateurs autorisés à protéger contre les menaces potentielles de type CSRF. WordPress fournit une API pour la génération de ces jetons, pour créer et vérifier des jetons uniques et temporaires, aussi le jeton est limitée à un utilisateur spécifique, une action spécifique, un objet spécifique, et une période de temps spécifique, qui peut être ajouté à des formulaires et URL si nécessaire. 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 de développement de WordPress surveille de près les bibliothèques et framework que WordPress intègre dans ses fonctionnalités de base. Par le passé, l’équipe de développement a contribué à plusieurs composants tiers afin de les rendre plus surs, tels que la mise à jour pour corriger une vulnérabilité cross-site dans TinyMCE dans WordPress 3.5.214.

Si nécessaire, l’équipe de développement peut décider de forker ou de remplacer des composants externes critiques, comme lorsque la bibliothèque SWFUpload a été officiellement remplacée par Plupload dans la version 3.5.2, et qu’une fork sécurisé de SWFUpload a été mise à disposition par l’équipe de sécurité15 pour les extensions qui ont continué à utiliser SWFUpload à court terme.

A10 - Redirections et transferts non validés

Le contrôle d’accès interne de WordPress et le système d’authentification permettront de protéger les utilisateurs contre les tentatives de redirection vers des destinations non désirées, ou automatiques. Cette fonctionnalité est également disponible pour les développeurs d’extensions via une API, wp_safe_redirect()16.

Autres risques concernant la sécurité

Attaques sur les processus XXE (XML eXternal Entity)

Lors de l’exécution du XML, WordPress désactive le chargement des entités XML personnalisées afin d’éviter les attaques External Entity et Entity Expansion. À part les fonctionnalités PHP du cœur, WordPress ne fournit pas d’autre API d’exécution sécurisée du XML pour les auteur·es d’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 nécessite un thème pour pouvoir rendre le contenu visible sur l’interface publique. Le thème par défaut fourni avec le noyau WordPress (actuellement « Twenty Nineteen ») a été passé en revue et testé en profondeur au niveau sécurité à la fois par l’équipe des développeurs du thème et par l’équipe de développement du noyau.

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 des thèmes et extensions WordPress.org

Il y a approximativement 50 000+ extensions et 5 000+ thèmes listés sur le site WordPress.org. Ces thèmes et extensions sont d’abord soumis en vue d’être ajoutés et sont manuellement passés en revue par des volontaires avant d’être mis à disposition sur le dépôt.

L’ajout d’extensions et de thèmes dans le répertoire ne garantit pas qu’ils soient exempts de failles de sécurité. Les auteurs d’extension doivent consulter les lignes de conduite qui leur sont fournies avant toute soumission en vue d’un ajout au dépôt17, et une vaste documentation axée sur le développement18 de thème WordPress est disponible sur le site WordPress.org.

Chaque extension ou thème est susceptible d’être amélioré par son créateur. 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 ayant installé cette extension ou ce thème, avec une description de ce changement. Les administrateurs 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 validation des thèmes (Theme Review Team) est un groupe de bénévoles conduit par des membres-clés et estimés de la communauté, qui vérifient et valident les thèmes proposés pour être disponibles sur le répertoire officiel de thèmes. Cette équipe maintient les guidelines officielles de Validation des thèmes19, les données de tests unitaires20, l’extension Theme Check21 et essaye d’encourager la communauté de développeur·ses de thèmes WordPress à suivre les bonnes pratiques de développement. L’inclusion dans ce groupe est modérée par les Core committers 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, qui est la plus grosse installation de WordPress au Monde, est possédé et géré par la société Automattic, fondée par Matt Mullenweg, le co-créateur du projet WordPress. WordPress.com, qui fonctionne avec le noyau du logiciel WordPress, possède ses propres processus, risques et solutions de sécurité22. Ce document fait référence à la sécurité du logiciel open source WordPress, téléchargeable, auto-hébergé par WordPress.org et installable sur n’importe quel serveur dans le Monde.

Annexe

API du cœur WordPress

L’API (Application Programming Interface) du noyau WordPress contient plusieurs API23 individuelles. Chacune d’entre elle couvre un champ d’action bien particulier. Ensemble, elles forment l’interface qui permet aux extensions et thèmes d’altérer, étendre et interagir avec les fonctionnalités du cœur de manière sécurisée.

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

Ajoutée dans WordPress 0.71, l’API Database24 fournit la bonne méthode pour accéder aux données en tant que valeurs nominatives stockées dans la couche d’abstraction de la base de données.

API Filesystem

Ajoutée dans WordPress 2.626, l’API Filesystem25 a été créée tout spécialement pour WordPress, qui possède sa propre fonctionnalité de mise à jour. L’API Filesystem extrait la fonctionnalité de lecture et d’écriture de fichiers locaux au système de fichiers pour réaliser les mises à jour en sécurité, avec un grand nombre d’hébergeurs.

Cela se passe par le biais de la classe WP_Filesystem_Base et de plusieurs sous-classes qui comprennent différentes façon de se connecter au système de fichiers local, suivant ce que supporte l’hébergeur. Tout thème ou extension ayant besoin d’écrire localement sur des fichiers doit utiliser la famille de classes WP_Filesystem.

HTTP API

Ajoutée dans WordPress 2.728 puis étendue dans WordPress 2.8, l’API HTTP27 standardise les requêtes HTTP de WordPress. Cette API gère les Cookies, l’encodage et décodage GZIP, le décodage de Chunk (pour HTTP 1.1), et plusieurs autres implémentations du protocole HTTP. L’API standardise les requêtes, teste chaque méthode avant envoi et, suivi votre configuration serveur, utilise la méthode appropriée pour effectuer chaque requête.

Les API Permissions & Current User

Les API Permissions & Current User29 sont un ensemble de fonctions aidant à vérifier les droits de l’utilisateur courant à effectuer toute tâche ou opération demandée, et qui permettent de protéger les utilisateurs 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 (hormis le logo WordPress ou la marque commerciale associée) est sous licence CC0 1.0 universal (CC0 1.0) Transfert dans le Domaine Public. Vous pouvez copier, modifier, distribuer et représenter l’œuvre, même à des fins commerciales, sans avoir besoin de demander l’autorisation.

Un remerciement tout spécial au Livre blanc sur la sécurité de Drupal, qui nous a inspiré.

Lectures supplémentaires

Rédigé par Sara Rosso

Contributions de Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Version 1.0 mars 2015

Notes de pied de page