Meilleures pratiques de sécurité pour les développeurs de plugins et de thèmes WordPress
Publié: 2020-12-09En tant que développeur WordPress, vous devez prendre de nombreuses décisions sur ce sur quoi travailler. Votre principal intérêt et votre priorité sont de créer un thème ou un plug-in étonnant, et les mesures de sécurité passent souvent au second plan lorsque vous prenez le volant pour travailler sur le code. À quand remonte la dernière fois où vous vous êtes assis et avez examiné votre propre code pour des problèmes de sécurité ? Non, je ne le pensais pas
Ces conseils sont basés sur mon expérience de développement de plugins chez CleverPlugins et d'aide à d'innombrables clients pour remettre leurs sites Web en ligne après avoir été piratés. Développer un plugin de sécurité comme WP Security Ninja ne m'a pas rendu moins paranoïaque à propos du code des autres.
La raison la plus courante des sites Web piratés est toujours la mauvaise gestion des mots de passe, mais cela ne devrait pas être une excuse pour utiliser certains des moyens simples de protéger votre code.
Lorsque vous développez un plugin ou un thème, vous voulez qu'il devienne populaire et qu'il soit installé sur autant de sites Web que possible. Plus votre succès est grand, plus les gens risquent d'essayer d'abuser de votre travail pour pirater les sites Web de vos utilisateurs.
En raison de la popularité de WordPress, il est devenu l'une des cibles les plus courantes pour les pirates. Si une vulnérabilité est détectée dans un plugin ou un thème, cela peut signifier que des milliers, voire des centaines de milliers de sites Web sont ouverts aux abus.
Malheureusement, il arrive régulièrement qu'une vulnérabilité apparaisse dans un produit bien connu, il vaut donc la peine de prendre quelques mesures de sécurité de base pour protéger votre code pour vos utilisateurs.
Qu'en est-il de l'équipe de révision de WordPress.org ?
Vous pourriez penser que l'équipe qui examine les plugins et les thèmes avant de les publier sur le référentiel officiel vérifie toutes sortes de problèmes de sécurité, mais l'équipe est minuscule et ne se compose que de quelques personnes. La file d'attente de plugins et de thèmes à vérifier ne cesse de croître, de sorte que le temps dont ils disposent pour les examiner est limité.
Cependant, s'ils trouvent quelque chose, ils peuvent automatiquement fermer votre plugin jusqu'à ce que vous le corrigiez ou vous avertir par e-mail que vous devez corriger une vulnérabilité avant un certain délai.
Le fait est qu'une fois que votre plugin ou thème est répertorié dans le référentiel, vous pouvez envoyer des mises à jour via le référentiel sans filtrage supplémentaire, de sorte qu'une vulnérabilité peut facilement se faufiler à tout moment et passer inaperçue pendant presque n'importe quelle période de temps.
Fondamentalement, le renforcement des mesures de sécurité de votre plugin dépend de vous, alors examinons quelques moyens de protéger votre produit WordPress et de vous éviter de nombreux maux de tête et potentiellement un impact négatif sur votre marque.
Voici ce que vous pouvez faire pour développer en toute sécurité votre plugin ou thème WordPress.
1. Pensez à la sécurité sous tous les angles !
Vous ne savez jamais qui pourrait utiliser votre plugin ou votre thème et quel niveau de compréhension ils ont de la sécurité, le cas échéant.
Vous ne savez jamais qui pourrait utiliser votre plugin ou votre thème et quel niveau de compréhension ils ont de la sécurité, le cas échéant.Tweet
Les administrateurs, les éditeurs ou les utilisateurs réguliers de tout site Web client peuvent ne pas utiliser de mots de passe sécurisés et leurs comptes peuvent être piratés. Si votre produit n'est pas sécurisé, ces comptes pourraient être abusés pour obtenir un accès supplémentaire afin d'installer un code malveillant sur le site Web de votre client.
Vous ne devez pas vous attendre à ce que les administrateurs de serveur qui ont configuré le serveur sur lequel le site Web s'exécute en sachent suffisamment sur la façon de protéger votre site Web des autres sites sur le même serveur. Si le site Web est hébergé par un grand fournisseur, vous pouvez vous attendre à ce que le site Web soit correctement "séparé", mais vous ne savez pas où votre produit sera installé.
Cela vous semble-t-il paranoïaque ? Peut-être. Mais, si et quand votre plugin ou thème devient super populaire, vous serez heureux d'avoir adopté une approche paranoïaque de la sécurité.
Si et quand votre plugin ou thème devient super populaire, vous serez heureux d'avoir adopté une approche paranoïaque de la sécurité.Tweet
2. Empêcher les attaques XSS – Cross-Site Scripting
Celui-ci devient de plus en plus important à mesure que WordPress devient un projet plus axé sur le front-end avec Gutenberg et ReactJS.
L'une des erreurs les plus courantes des développeurs WordPress est d'oublier de valider et de désinfecter leur code, ce qui le laisse ouvert aux attaques XSS. Il existe quelques variantes de XSS, mais en général, une attaque XSS se produit lorsqu'un pirate est autorisé à injecter du code dans le serveur, puis à le faire exécuter dans le navigateur d'un visiteur.
Imaginez que vous avez un champ de saisie. Par souci de simplicité, disons qu'il s'agit d'un champ de commentaire où les utilisateurs ou les visiteurs peuvent soumettre un commentaire à un message.
Un pirate tentera de soumettre un commentaire avec "<script>alert('XSS');</script>" .
Maintenant, ce n'est qu'un exemple de base qui affiche une alerte sur l'écran de l'utilisateur et rien d'autre. Un véritable pirate informatique utilisera le champ de commentaire pour injecter du code qui charge le code de son site qui peut voler des informations du navigateur du visiteur et bien plus encore.
Nous pouvons empêcher que cela ne se produise en validant, en assainissant et en s'échappant.
La validation consiste à vérifier les données soumises avant de faire quoi que ce soit, comme les stocker dans la base de données. Chaque fois que des données sont soumises, vous pouvez les vérifier et vous assurer qu'elles sont acceptables. S'il s'agit d'un champ de quantité, vous attendez un nombre. S'il ne s'agit pas d'un nombre, vous pouvez renvoyer un message d'erreur à l'utilisateur.
La désinfection des données consiste à traiter les informations soumises et à s'assurer qu'elles ne contiennent rien que nous ne souhaitons pas stocker, comme la suppression de tout caractère indésirable. WordPress a plusieurs fonctions intégrées pour vous aider. Plus d'informations sur la désinfection dans un instant.
L'échappement empêche tout code malveillant de s'exécuter réellement dans votre navigateur. Supposons que vous ayez déjà injecté du code malveillant dans votre site Web, ou qu'un autre plugin ou thème permette aux pirates d'insérer du code dans les données que vous utilisez - échapper les données à l'écran avant de les afficher empêchera qu'elles ne posent problème.
Regardons le même exemple simple que nous avons utilisé avant "<script>alert('XSS');</script>"
Si nous ne faisons rien avec ce code, le navigateur pensera qu'il s'agit de code HTML. Le détail important ici est les caractères < > qui sont utilisés pour définir les balises HTML. En les échappant, nous transformons < en < et > dans > Le navigateur comprend maintenant qu'il ne s'agit pas de code HTML réel et qu'il devrait simplement afficher un signe inférieur à et supérieur à la place.
En validant, assainissant et échappant toutes les données qui entrent et sortent de votre application, vous protégez vos utilisateurs contre l'une des méthodes d'attaque les plus courantes.
3. Attention aux injections SQL
Comme son nom l'indique, un attaquant peut utiliser des injections SQL pour que votre site Web traite une requête SQL modifiée et l'utilise pour accéder à votre base de données.
Selon les données que vous stockez sur votre site Web, la fuite des données de votre site Web à la suite d'une attaque par injection SQL peut aller d'une situation embarrassante à une situation complètement dévastatrice pour votre réputation et votre entreprise.
L'injection SQL est une ancienne façon d'attaquer un site Web, mais elle est toujours très efficace et de nombreuses personnes recherchent des moyens d'utiliser cette forme d'attaque. En octobre 2020, le populaire plugin WordPress Loginizer a annoncé qu'il avait une vulnérabilité d'injection SQL qui laissait plus d'un million de sites Web en danger.
En 2019, des pirates informatiques inconnus ont volé des millions de données fiscales de Bulgares via une attaque par injection SQL, et en 2016, un groupe de pirates informatiques russes a extrait les informations électorales d'environ 500 000 personnes dans l'Ohio. Ces types d'attaques sont toujours très efficaces et vous pouvez trouver de nombreuses informations à leur sujet.
Source : https://xkcd.com/327/
L'endroit le plus courant où une injection SQL se produit est dans un champ de formulaire qui accepte les entrées de l'utilisateur - par exemple, un nom. L'attaque se produit en saisissant des parties de code SQL dans les champs de saisie, en créant une requête personnalisée donnant un résultat différent de celui auquel vous vous attendez.
Disons que vous avez un formulaire qui permet aux gens de rechercher un nom particulier.
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' AND meta_key = 'celebrity_name';
Cet exemple simple récupèrerait toutes les lignes de la méta table post avec toutes les lignes qui ont le nom Henry et une clé spécifique, celebrity_name - de cette façon, nous ne renvoyons pas la base de données entière et seulement les lignes particulières dont nous avons besoin.
Un attaquant tenterait d'analyser une valeur différente - par exemple 'Henry' OR 1=1--
La requête renverra maintenant toutes les lignes avec notre valeur spécifique, ou toute autre chose - puisque OR 1=1 en SQL est toujours vrai.
Mais ça s'aggrave. Notre requête SQL ne demandait que des résultats où le meta_key correspond à la valeur particulière que nous recherchons, nous ne renverrions donc pas tout. Cela devrait limiter l'impact de l'attaque par injection SQL, n'est-ce pas ?
Eh bien, pas si. En SQL, le double tiret est un indicateur de commentaire, donc tout ce qui suit est commenté.
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1--' AND meta_key = 'celebrity_name';
Cela signifie que la requête ressemble à ceci :
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1
La requête renvoie maintenant essentiellement tout ce qui se trouve dans cette table de base de données.
Ce n'était qu'un simple exemple. Il existe de nombreuses façons plus compliquées d'accéder à la plupart, sinon à la totalité, des informations d'une base de données. Un attaquant pourrait tenter des attaques par injection SQL aveugle, ce qui signifie exécuter du code sur votre base de données – ajouter un nouvel administrateur, supprimer toutes vos données, etc.
La plupart des attaques se présenteraient sous la forme de chaînes de requête aléatoires contenant des parties de SQL soumises aux formulaires de votre site Web. Les scripts automatisés détecteraient toute modification apportée à la sortie de votre site Web, puis détecteraient le potentiel d'attaque.
Un moyen simple et efficace consiste à envoyer une apostrophe ' en entrée et à voir si cela change quelque chose, si une erreur se produit ou si d'autres résultats sont renvoyés.
WordPress à la rescousse
Au lieu d'interagir directement avec la base de données, tout développeur doit utiliser la classe d'abstraction de base de données intégrée dans WordPress, $wpdb .
La classe $wpdb dans WordPress possède toutes les fonctionnalités CRUD dont vous avez besoin pour interagir avec la base de données en toute sécurité, et vous pouvez même utiliser la classe pour interagir avec vos propres tables de base de données si votre plugin ou votre thème en a besoin.
Vous pouvez résoudre le problème en anticipant le type de données à saisir raisonnablement dans chaque formulaire de saisie. Dans notre exemple précédent, nous avons recherché un nom. Nous pourrions désinfecter l'entrée pour nous assurer que nous n'acceptons que les lettres. Si vous avez une zone de sélection ou un groupe radio qui ne contient que quelques options, vous pouvez vérifier les données pour vous assurer qu'il ne s'agit que de l'un des choix que vous autorisez.
La chose la plus importante que vous puissiez faire pour résoudre le problème est de préparer vos données avec la $wpdb->prepare() .
Cette fonction prend une chaîne de requête préparée et un tableau des arguments que vous souhaitez ajouter à la requête SQL.
$meta_key = 'celebrity_name';
$meta_val = 'Henry'
$allhenrys = $wpdb->get_results(
$wpdb->prepare(
"SELECT * FROM $wpdb->postmeta WHERE meta_key = %s AND meta_value = %s",
$meta_key,
$meta_val
)
);
Tout le travail a lieu à l'intérieur de la fonction prepare() . Le premier paramètre, la requête préparée, contient l'espace réservé %s au lieu des valeurs réelles. Ceci est remplacé par les autres variables analysées, $meta_key et $meta_val .
Remarque - Il est important de ne pas avoir d'apostrophe dans votre requête entourant les espaces réservés, car la fonction les ajoutera pour vous.
Ceci est un exemple simplifié, mais le même processus peut être utilisé pour n'importe quelle requête de base de données et vous pouvez utiliser %s pour les chaînes, %d pour les entiers et %f pour les flottants.
Il existe également des fonctions pour des situations spécifiques, telles que l'ajout d'une nouvelle ligne à la base de données. Pour cela, vous pouvez utiliser $wpdb->insert() .
$wpdb->insert(
"{$wpdb->prefix}my_custom_table",
array(
'name' => 'Henry',
'userid' => 123,
'score' => 10,
),
array(
'%s',
'%d',
'%d',
)
);
L'utilisation de la fonction de préparation peut aider à empêcher la majorité des tentatives d'injection SQL contre votre produit.
N'oubliez pas de consulter la documentation de $wpdb. Certaines fonctions échapperont à la saisie pour vous ; d'autres s'attendent à ce que vous échappiez vous-même à l'entrée avant d'analyser les données dans la fonction.
4. Utilisez des nonces pour protéger vos demandes
L'utilisation du système nonce dans WordPress peut vous aider à prévenir de nombreuses attaques. Un nonce en termes de sécurité est un nombre utilisé une seule fois. L'idée est d'ajouter ce numéro unique à toutes les demandes que vous faites depuis votre code vers l'installation de WordPress afin de vérifier que cette demande est légitime.
C'est un peu comme avoir un mot de passe secret qu'il faut donner au videur pour entrer dans un club
Cependant, les nonces dans WordPress sont un peu différents - ils ne sont pas un nombre et le nonce n'est utilisé qu'une seule fois.
Techniquement, les nonces de WordPress peuvent contenir à la fois des lettres minuscules et des chiffres, et au lieu d'être utilisés une seule fois , ils sont régénérés après un certain temps.
La façon dont vous utilisez un nonce est que le code PHP qui enregistre vos fichiers JavaScript génère une petite combinaison unique de chiffres et de lettres et les analyse afin que votre code JS puisse le lire.
Chaque fois que le code JavaScript envoie une requête à votre site Web, il envoie ce morceau de code, et si le code ne correspond pas, votre code doit ignorer complètement la requête.
C'est toujours un peu plus facile avec un exemple, alors voyons une manière simple de charger un fichier .js dans votre plugin en suivant ces étapes :
Utiliser des nonces dans un plugin WordPress
add_action('wp_enqueue_scripts', 'load_my_plugin_script');
function load_my_plugin_script() {
// Register the script with all details and ensures it is loaded after jQuery
wp_register_script('secure-plugin', plugin_dir_url( __FILE__ ). 'js/secure-plugin.js', array( 'jquery' ) );
// Here happens the magic, we add some details to an object that we can later reference and read from in our JS code.
wp_localize_script(
'secure-plugin',
'plugin_ajax_object',
array(
'nonce' => wp_create_nonce('secure-plugin-nonce')
)
);
// Once that is done, we can now enqueue the script
wp_enqueue_script('secure-plugin');
}
Dans cette fonction, nous disons à WordPress de charger un fichier JavaScript. Tout d'abord, nous enregistrons le fichier que nous voulons charger avec wp_register_script() .
Ensuite, nous utilisons wp_localize_script() pour analyser un tableau de données, en particulier "nonce" qui contient le nonce unique que nous voulons utiliser dans notre code JS. N'oubliez pas que vous pouvez également envoyer toutes sortes d'autres informations dans ce tableau, mais nous restons simples dans cet exemple.
Lorsque vous envoyez une requête à partir de votre fichier JavaScript, vous devez inclure ce nonce unique. Faire cela est facile :
Utiliser nonce du plugin WordPress dans un fichier JavaScript
jQuery(document).ready(function($) {
$.ajax({
url: ajaxurl, // WP variable, contains URL pointing to admin-ajax.php
type: 'POST',
data: {
'action': 'get_custom_data',
'_ajax_nonce': plugin_ajax_object.nonce,
'user_data': 'Some input from a user'
},
success: function( response ) {
// Here we do what happens if all is good - update the interface with a success message!?
},
error: function( response ) {
// Whooops, something went wrong!
// console.log(response);
}
});
});
Puisque nous avons utilisé wp_localize_script() nous pouvons utiliser la variable plugin_ajax_object en JavaScript. Nous envoyons le nonce en tant que variable, _ajax_nonce .
Vérifier et vérifier un nonce dans un plugin WordPress à partir du code JavaScript
add_action('wp_ajax_get_custom_data', 'get_custom_data');
function get_custom_data() {
// Ready for the magic to protect your code?
check_ajax_referer('secure-plugin-nonce');
/**
* That's it - the check_ajax_referer function verifies the nonce is correct or it dies and stops code execution if it fails.
*
* If you want to customize the error handling and perhaps return an error to your JS code, you could change the code to something like:
* if ( ! check_ajax_referer( 'secure-plugin-nonce', false, false ) ) {
* wp_send_json_error( 'Invalid nonce' );
* }
*/
$sanitized_user_data = sanitize_text_field( $_POST['user_data'] );
// ... continue with the rest of your plugin's function code ...
}
La magie opère avec la fonction check_ajax_referer() qui vérifie le nonce et échoue simplement et arrête toute autre exécution de code si le nonce ne correspond pas à ce qui était attendu.
Vous pouvez personnaliser davantage le code pour renvoyer des informations spécifiques à l'utilisateur sur ce qui s'est passé.
L'utilisation de nonces dans votre code est un moyen rapide, simple et efficace d'empêcher de nombreux types de tentatives de piratage. Cela ne signifie pas que vous pouvez ignorer toutes les autres mesures de sécurité, mais cela aide à réduire les pires problèmes.
Tu te souviens de ce que j'ai dit sur le fait de ne jamais faire confiance à personne ? Cela nous amène à une autre façon de protéger votre code : la désinfection.
Abonnez-vous et obtenez un exemplaire gratuit de notre livre
11 techniques éprouvées pour augmenter le taux de réussite de vos litiges de carte de crédit de 740 %
Partager avec un ami
Saisissez l'adresse e-mail de votre ami. Nous leur enverrons seulement ce livre par e-mail, l'honneur du scout.
Merci pour le partage
Génial - une copie de '11 Techniques éprouvées pour augmenter votre taux de réussite des litiges de carte de crédit de 740%' vient d'être envoyée à . Vous voulez nous aider à faire passer le mot encore plus ? Allez-y, partagez le livre avec vos amis et collègues.
Merci pour votre subscription!
- nous venons d'envoyer votre copie de '11 techniques éprouvées pour augmenter votre taux de réussite des litiges de carte de crédit de 740%' à .
Vous avez une faute de frappe dans votre e-mail ? cliquez ici pour modifier l'adresse e-mail et envoyer à nouveau.
5. Désinfectez l'entrée de l'utilisateur
Dans l'exemple précédent, nous avons inclus une donnée supplémentaire envoyée de JS à PHP. Chaque fois que vous obtenez des données dans votre code, vous devez vous attendre à ce qu'il soit dangereux.
'user_data':'Some input from a user'
Dans cet exemple, il s'agit d'une simple chaîne, mais puisque nous renvoyons des données à PHP, nous devons nous assurer que l'entrée ne contient aucun code qui pourrait être exploité dans notre environnement PHP ou être stocké dans la base de données permettant d'autres abus.
Vient la désinfection. WordPress a une gamme de fonctions qui prennent toutes les entrées que vous lui donnez et nettoient les données avant de vous les renvoyer.
Dans cet exemple, nous avons utilisé la fonction sanitize_text_field() , mais WordPress est livré avec de nombreuses fonctions de nettoyage adaptées à différents types de données.
Il existe de nombreuses autres fonctions et méthodes intéressantes intégrées à WordPress que vous pouvez utiliser pour sécuriser votre code et prévenir les abus.
Vous ne devriez jamais, au grand jamais, utiliser les données envoyées à votre code sans les avoir préalablement nettoyées. Consultez cet article sur les erreurs courantes des développeurs WordPress avec plus de détails sur la désinfection et d'autres excellents conseils pratiques.
Et cela m'amène au conseil suivant, que la plupart des développeurs WordPress ont expérimenté :
6. N'oubliez pas que is_admin() n'est pas ce que vous pensez
Lorsque vous commencerez à penser à protéger votre code du mal, vous tomberez probablement sur la fonction is_admin() , et d'après le nom, cela semble être tout ce dont vous avez besoin, et tout ce que vous avez à faire est d'envelopper votre code avec cela, et tout ira bien.
Non, malheureusement non. La fonction is_admin() détecte uniquement si le code est en cours d'exécution du côté administration du site Web. Il ne fait rien pour détecter si votre code est exécuté par un utilisateur ou un administrateur régulier.
Vous ne le remarquerez jamais si vous entrez simplement le code dans votre plugin parce que vous exécutez très probablement le code dans l'interface d'administration, et cela signifie que le code sera simplement évalué à true , et vous arrêterez d'y penser et passerez à quelque chose autre.
La bonne façon de vérifier si un utilisateur est un administrateur est de vérifier la capacité de l'utilisateur :
if ( current_user_can( 'activate_plugins' ) ) {
// Do your code here
}
Il existe différentes capacités pour différents rôles d'utilisateur, vous avez donc un contrôle beaucoup plus granulaire. Dans la plupart des cas, 'activate_plugins' est ce dont vous avez besoin uniquement pour les administrateurs.
Si vous voulez un moyen d'autoriser à la fois les administrateurs et les éditeurs à faire quelque chose, vous devriez tester la capacité 'edit_pages' .
7. Ajoutez rel= »noopener » ou rel= »noreferrer » à vos liens
La création de liens vers des ressources externes est tout à fait normale, et la méthode à l'ancienne consistant à ajouter target="_blank" à ces liens est logique car vous ne voulez pas que vos utilisateurs quittent votre page de plugin/thème.
Cependant, cela vous ouvre la porte à ce qu'on appelle le Tabnabbing. Il s'agit d'un problème de sécurité où un code JavaScript malveillant peut voler des informations à vos utilisateurs en abusant de la fonctionnalité JavaScript window.opener .
Empêcher cela peut être aussi simple que d'ajouter rel="noopener" à vos liens. La page vers laquelle vous créez un lien aujourd'hui est peut-être très bien, mais cela pourrait changer à l'avenir.
rel=noopener signifie que la page vers laquelle vous créez un lien ne peut pas accéder aux informations ni prendre le contrôle de votre page.
rel=noreferrer fait de même, et indique également au navigateur de ne transmettre aucune information de référence via l'en-tête Referrer. L'ajout rel="noreferrer" signifie que la page vers laquelle vous créez un lien ne sait pas d'où vient votre visiteur.
Remarque : ces deux propriétés ne doivent pas être confondues avec rel=nofollow , qui est liée au SEO.
8. Utilisez HTTPS et Secure Tokens avec des API tierces
En tant que développeur, vous devrez souvent intégrer des API, et il est essentiel de le faire en toute sécurité pour protéger les données que vous échangez.
Heureusement, il existe déjà des normes mises en place sur la façon de le faire en toute sécurité ; l'un d'eux est HTTPS. L'utilisation de HTTPS introduit une couche de sécurité où toutes les données transmises sont cryptées.
Cependant, pour vous assurer que vos données sont protégées des regards indiscrets, l'utilisation de HTTPS ne suffit pas.
Comme l'explique cet article d'Ars Technica, "HTTPS ne signifie pas que vos données sont sécurisées, cela signifie simplement que votre connexion est sécurisée."
Jetons sécurisés – JWT
Une norme sécurisée pour gérer la communication et les intégrations d'API consiste à utiliser JSON Web Tokens, JWT.
Un jeton sécurisé est créé en adressant une demande à un serveur qui valide les informations de connexion d'un utilisateur et génère un jeton, un petit morceau de chaîne contenant des données, telles que le nom d'utilisateur, l'ID, etc.
Lorsque vous envoyez des demandes ultérieures au serveur, vous incluez ce jeton dans la demande. Ce jeton prouve que vous êtes authentifié et que vous y avez accès. Si le jeton est valide et qu'il n'a pas expiré, le serveur utilisera les détails de l'utilisateur contenus dans le jeton et extraira les données demandées.
Le serveur peut traiter rapidement les demandes de cette manière, par rapport à l'utilisation d'une clé API, qui nécessiterait de rechercher l'utilisateur via cette clé avant de décider de traiter les données. À l'aide d'un jeton, vous pouvez inclure des données à l'intérieur du jeton sur l'utilisateur et enregistrer plusieurs requêtes de base de données.
Avec la manière dont un jeton sécurisé est généré puis utilisé, il n'est pas possible de créer de faux jetons ou de manipuler le contenu d'un jeton. Il n'est possible de créer un jeton valide qu'en connaissant une clé secrète, que l'entreprise derrière la plateforme gardera bien cachée.
Une note très importante à retenir est que les données à l'intérieur d'un jeton ne sont pas chiffrées. Il est impossible de falsifier le contenu du jeton sans l'invalider, mais les données à l'intérieur d'un jeton peuvent facilement être lues par n'importe qui, ce n'est donc pas un bon endroit pour stocker des données sensibles.
Une bonne ressource si vous souhaitez vous plonger davantage dans les jetons et leur fonctionnement est l'introduction aux jetons Web JSON.
9. N'utilisez pas de bibliothèques externes à partir de CDN
Bien qu'il puisse être tentant d'inclure toutes les bibliothèques dont vous pourriez avoir besoin via cdnjs.com ou d'autres CDN mondiaux gratuits, il y a quelques inconvénients.
Tout d'abord, vous n'avez aucun contrôle sur les bibliothèques et tout code malveillant qui se faufile dans les fichiers que vous incluez.
Bien que les CDN soient généralement stables et rapides par définition, ils sont également sujets à davantage d'attaques. Si votre code repose sur une bibliothèque JS sur un CDN attaqué, votre plugin et votre thème se chargeront très lentement ou pas du tout.
Cela est arrivé à un site Web client où le CDN public qu'un plugin utilisait à l'époque expirait pour les utilisateurs de certaines régions, rendant l'interface inutilisable. En fin de compte, j'ai dû changer le plugin pour utiliser une copie locale du script JS à la place comme solution rapide.
L'utilisation d'une source tierce externe peut également compromettre la confidentialité. Il sera possible pour le CDN d'enregistrer toutes vos adresses IP d'utilisateurs - assurez-vous de vérifier la politique GDPR et d'informer vos clients.
En général, si vous utilisez des fournisseurs de CDN tiers réputés, vous ne rencontrerez aucun problème, mais l'approche la plus simple et la plus fiable consiste à distribuer la bibliothèque JS incluse dans votre produit.
Le saviez-vous? WordPress est livré avec plusieurs bibliothèques JS incluses. La plupart des bibliothèques JS les plus courantes que vous pourriez vouloir utiliser sont incluses avec WordPress. Ces bibliothèques couvriront la plupart de vos besoins de base.
Conseil développeur : chargez uniquement les fichiers JS et CSS supplémentaires sur les pages spécifiques dont vous avez besoin. En tant que développeur et utilisateur, je n'aime pas du tout les plugins qui ralentissent l'administration en chargeant des fichiers JS et CSS inutiles sur chaque page. Non seulement cela ralentit les autres pages d'administration, mais cela peut aussi vraiment gâcher la présentation visuelle et rendre certaines pages d'administration presque inutilisables. S'il te plaît
Il existe également des outils qui peuvent vous aider à protéger votre code, et un excellent outil que vous pouvez utiliser gratuitement est Coderisk.
en train de recruter 
10. Utilisez des outils et des services pour analyser votre code
Code-risque
Il existe de nombreux services automatisés pour aider à identifier les problèmes de code. Exakat, SonarSource et PHPStan pour n'en nommer que quelques-uns, et un de mes préférés - Coderisk.com - Un moyen facile de trouver certaines des erreurs de sécurité les plus évidentes dans votre code.
Cette société analyse tous les plugins WordPress à partir du référentiel public WordPress.org. Leur logiciel est capable de scanner et d'identifier des centaines de types différents de problèmes de sécurité basés sur différentes normes de codage.
Selon leurs propres statistiques, ils ont scanné plus de 4 milliards de lignes de code public jusqu'à présent, et il y a beaucoup de problèmes avec même les meilleurs plugins.
Pour vous inscrire à leur service gratuit, c'est assez simple - vous pouvez créer un compte gratuit, puis commencer à réclamer vos plugins. Réclamer un plugin est aussi simple que de prendre une seule ligne de code que vous mettez dans votre fichier readme.txt la prochaine fois que vous déployez une nouvelle version.
Cela vous permet d'accéder à leur dernière analyse de votre plugin, et à l'intérieur, ils ont des informations et des détails spécifiques sur chaque problème, avec des liens directement vers votre code.
Gardez à l'esprit qu'il s'agit d'un service gratuit, il se peut donc qu'ils ne mettent pas souvent à jour leur analyse de votre plugin, mais une fois que vous recevez une notification, cela vaut la peine de vérifier votre code, car vous avez peut-être introduit une erreur depuis la dernière fois que vous avez examiné votre code.
L'interface est assez facile à naviguer une fois que vous avez compris, et le système est très utile, vous donnant des instructions très faciles à comprendre sur ce qui ne va pas, ce qui vous aide à retracer l'erreur.
Il existe également de nombreuses façons de filtrer les bogues, et vous pouvez marquer chaque problème comme résolu ou de nombreuses autres options pour vous aider à obtenir rapidement un aperçu de tous les problèmes.
Remarque : si vous n'exécutez jamais Coderisk (ou tout autre outil de sa catégorie) sur votre code, ne vous inquiétez pas du nombre de problèmes suspects dont vous serez averti. Ces outils peuvent générer une bonne quantité de faux positifs car ils analysent uniquement le code sans comprendre la logique métier. Utilisez la sortie de l'outil comme une liste de départ solide d'éléments à examiner.
PHP_CodeSniffer
Un autre excellent outil pour vérifier votre code est PHP_CodeSniffer. Le PHPCS se compose de deux scripts, PHPCS qui vérifie votre code et vous signale les erreurs et le PHPCBF qui peut résoudre automatiquement une grande partie des problèmes identifiés par PHPCS.
L'utilisation de PHPCS est très facile à utiliser à partir de la ligne de commande une fois que vous l'avez installé. Cet outil n'empêchera pas les problèmes de sécurité d'apparaître dans votre code, mais vous pouvez éliminer les simples erreurs de codage, ce qui rend encore plus difficile l'abus de problèmes plus importants.
Il est également possible d'intégrer PHPCS directement dans votre éditeur, comme Sublime Text et Visual Code. De cette façon, vous pouvez facilement voir les erreurs et les corriger rapidement dans votre IDE.
Peu importe si vous travaillez en équipe ou en tant que développeur unique, il vaut la peine d'utiliser un système automatisé car c'est un moyen facile d'éliminer les problèmes de sécurité de base que vous pourriez autrement manquer.
L'utilisation d'un système automatisé pour analyser votre code à la recherche de problèmes de sécurité n'est pas une méthode sûre pour détecter tous les bogues, mais cela peut vous aider à identifier les erreurs les plus évidentes.
11. Ne copiez pas le code du Web sans un examen approprié
Garder votre produit WP aussi sécurisé que possible devrait être un processus continu, pas seulement de temps en temps. Lorsque vous introduisez de nouvelles fonctionnalités ou supprimez du code, vous pouvez également introduire de nouveaux problèmes de sécurité.
Google n'est pas toujours votre ami. En tant que développeur, vous avez l'habitude de vérifier sur Internet des exemples de code pour vous inspirer - ou simplement de réécrire des morceaux ici et là si vous êtes paresseux.
La plupart des morceaux de code que vous trouvez sur Internet sont rarement prêts à être utilisés dans un environnement de production sécurisé et sont considérés comme un exemple de tout problème de codage que vous essayez de résoudre. L'utilisation de ces morceaux de code aveuglément et sans examen peut introduire des problèmes très rapidement.
Il y a beaucoup à faire en tant que développeur WordPress, et résoudre un problème de sécurité urgent dans votre plugin avec des milliers d'installations ne devrait pas en faire partie.
Gardez à l'esprit que votre réputation est en jeu
Si vous ne faites pas attention à la sécurité de votre plugin ou de votre thème, vous mettez en jeu vos utilisateurs, leurs entreprises, votre entreprise et votre réputation. C'est beaucoup de temps et d'argent potentiellement perdus !
Les failles de sécurité peuvent avoir un impact considérable sur la confiance que les clients accordent à votre marque ou à vos produits. L'exemple de Loginizer ci-dessus montre que même les vulnérabilités de sécurité les plus embarrassantes peuvent arriver aux développeurs de plugins de sécurité eux-mêmes ! Et les autres exemples de fraude électorale et de piratage du gouvernement nous disent que tout le monde est vulnérable.
Si et quand vous découvrez une vulnérabilité, agissez rapidement pour la résoudre et suivez les meilleures pratiques pour annoncer publiquement le problème (si nécessaire) et publier un correctif.
Si vous gardez une longueur d'avance en matière de communication et de problèmes de « relations publiques » pouvant découler d'une vulnérabilité, vous pouvez éviter des maux de tête géants et augmenter votre réputation au lieu de l'endommager.
Merci d'avoir lu!
Il peut être intimidant d'examiner toutes les choses que vous devez faire lorsque vous ne savez pas quoi chercher pour commencer, et il peut être difficile de trouver la bonne information. Si vous ne savez pas par où commencer, vous devriez envisager de faire examiner votre produit par un expert en sécurité WP (je fais aussi des examens de sécurité).
Il est tentant d'économiser de l'argent ou du temps pour un examen de sécurité, mais le coût de ne pas sécuriser autant que possible votre produit peut être encore plus élevé à long terme.
Ce ne sont là que quelques- unes des façons dont vous pouvez et devriez protéger votre produit WordPress contre les abus. Si vous avez le moindre doute, rappelez-vous simplement - Ne faites confiance à personne