Soyez vigilant : les fonctions PHP et WordPress qui peuvent rendre votre site non sécurisé

La sécurité d'un site Web WordPress (ou de tout autre) est un problème à multiples facettes. La mesure la plus importante que quelqu'un puisse prendre pour s'assurer qu'un site est sécurisé est de garder à l'esprit qu'aucun processus ou méthode unique ne suffit à garantir que rien de mal ne se passe. Mais il y a des choses que vous pouvez faire pour aider. L'un d'eux est d'être à l'affût, dans le code que vous écrivez et dans le code des autres que vous déployez, des fonctions qui peuvent avoir des conséquences négatives. Dans cet article, nous couvrirons exactement celles-ci : les fonctions auxquelles un développeur WordPress doit réfléchir clairement avant de les utiliser.

WordPress lui-même fournit une importante bibliothèque de fonctions, dont certaines peuvent être dangereuses. Au-delà de cela, il existe de nombreuses fonctions PHP qu'un développeur WordPress (PHP) utilisera avec une certaine fréquence qui peut être dangereuse lorsqu'elle est utilisée.

Toutes ces fonctions ont des utilisations légitimes et sûres, mais ce sont aussi des fonctions qui peuvent faciliter l'utilisation abusive de votre code à des fins malveillantes. Nous couvrirons les éléments les plus susceptibles d'être la cause d'une vulnérabilité de sécurité et pourquoi vous devez les surveiller. Nous allons d'abord passer en revue les fonctions PHP dans votre code que les mauvais acteurs peuvent utiliser pour le mal, puis parler des fonctions PHP spécifiques à WordPress qui peuvent également causer des maux de tête.

Fonctions PHP à surveiller

Comme nous l'avons dit, PHP contient de nombreuses fonctions faciles à utiliser. Certaines de ces fonctions sont connues pour la facilité avec laquelle les gens peuvent faire de mauvaises choses avec elles. Toutes ces fonctions ont une utilisation appropriée, mais faites attention à la façon dont vous les utilisez et à la façon dont les autres codes que vous insérez dans un projet le font.

Nous allons supposer que vous avez déjà désactivé les guillemets magiques et enregistrer les globals si votre version de PHP les prend en charge. Ils étaient désactivés par défaut dans PHP 5 et plus, mais pouvaient être activés pour les versions inférieures à 5.4. Peu d'hébergeurs l'ont autorisé, mais je ne pense pas qu'un article sur la sécurité PHP soit vraiment complet sans les inclure.

Ou une mention que PHP 5.6 est la dernière version 5.x toujours avec un support de sécurité continu. Vous devriez être dessus, au moins. Et vous devriez avoir un plan pour passer à PHP 7 avant la fin du support 5.6 fin 2018.

Après cela, vous n'aurez plus qu'à gérer certaines fonctions risquées. Commençant par…

extract est une mauvaise nouvelle, en particulier sur $_POST ou similaire

Heureusement, l'utilisation de la fonction d' extract de PHP est largement tombée en disgrâce. Le cœur de son utilisation était que vous pouviez l'exécuter sur un tableau de données, et ses paires clé-valeur deviendraient des variables vivantes dans votre code. Alors

 $arr = array( 'red' => 5 ); extract($arr); echo $red; // 5

travaillerait. C'est cool, mais c'est aussi très dangereux si vous $_GET , $_POST , etc. Dans ces cas, vous recréez essentiellement le problème register_globals vous-même : un attaquant extérieur peut facilement modifier les valeurs de vos variables en ajoutant une chaîne de requête ou champ de formulaire. La meilleure solution est simple : n'utilisez pas extract .

Si vous créez vous-même le tableau que vous extrayez, l'utilisation de extract n'est pas spécifiquement un problème de sécurité et, dans certains cas, cela peut être utile. Mais toutes les utilisations de celui-ci ont le problème de confondre les futurs lecteurs. Créer un tableau et appeler extract est plus déroutant que de simplement déclarer vos variables. Je vous encourage donc à faire des déclarations manuelles à la place, à moins que ce ne soit complètement irréalisable.

Si vous devez utiliser l' extract sur l'entrée utilisateur, vous devez toujours utiliser l'indicateur EXTR_SKIP . Cela pose toujours le problème de la confusion, mais cela élimine la possibilité que vos valeurs prédéfinies puissent être modifiées par un tiers malveillant via une simple chaîne de requête ou une modification de formulaire Web. (Parce qu'il "ignore" les valeurs déjà définies.)

« eval est mauvais » parce que le code arbitraire fait peur

eval en PHP et à peu près n'importe quel autre langage qui le porte est toujours haut sur des listes comme celle-ci. Et pour une bonne raison. La documentation officielle de PHP sur PHP.net le dit assez franchement :

ATTENTION : La construction du langage eval() est très dangereuse car elle permet l'exécution de code PHP arbitraire. Son utilisation est donc déconseillée. Si vous avez soigneusement vérifié qu'il n'y a pas d'autre option que d'utiliser cette construction, faites particulièrement attention à ne pas y transmettre de données fournies par l'utilisateur sans l'avoir correctement validée au préalable.

eval permet à n'importe quelle chaîne arbitraire de votre programme d'être exécutée comme s'il s'agissait de code PHP. Cela signifie qu'il est utile pour la "méta-programmation" où vous construisez un programme qui peut lui-même construire un programme. C'est aussi très dangereux parce que si jamais vous autorisez des sources arbitraires (comme une zone de texte sur une page Web) à être transmises immédiatement à votre évaluateur de chaîne eval , vous avez soudainement rendu trivialement facile pour un attaquant malveillant de faire à peu près tout ce que PHP peut faire. faire sur votre serveur. Cela inclut, évidemment, la connexion à la base de données, la suppression de fichiers et à peu près tout ce que quelqu'un peut faire lorsqu'il est connecté en SSH à une machine. C'est mauvais.

Si vous devez utiliser eval dans votre programme, vous devez faire tout votre possible pour vous assurer que vous n'autorisez pas la transmission d'entrées utilisateur arbitraires. Et si vous devez autoriser des utilisateurs arbitraires à accéder aux entrées de eval , limitez ce qu'ils peuvent faire via une liste noire de commandes que vous ne les laissez pas exécuter, ou (mieux, mais beaucoup plus difficile à implémenter) une liste blanche qui ne contient que les commandes que vous considérer comme sûr. Mieux encore, n'autorisez qu'un petit nombre de modifications de paramètres spécifiques, comme uniquement des entiers validés.

Mais gardez toujours à l'esprit cette ligne de Rasmus Lerdorf, le fondateur de PHP :

"Si `eval()` est la réponse, vous posez certainement la mauvaise question."

Variations sur eval

Il existe, en plus du bien connu eval , une variété d'autres façons dont PHP a historiquement pris en charge les chaînes évaluées en tant que code. Les deux plus pertinentes pour les développeurs WordPress sont preg_replace avec le modificateur /e et create_function . Chacun fonctionne un peu différemment, et preg_replace après PHP 5.5.0 ne fonctionne plus du tout. (PHP 5.5 et les versions antérieures ne reçoivent plus les mises à jour de sécurité officielles et il est donc préférable de ne pas les utiliser.)

/e Les modificateurs dans Regex sont également "mauvais"

Si vous utilisez PHP 5.4.x ou une version antérieure, vous voudrez garder un œil sur les appels PHP preg_replace qui se terminent par un e. Cela peut ressembler à :

 $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );)

PHP propose différentes manières de "clôturer" votre expression régulière, mais la principale chose que vous devez rechercher est "e" en tant que dernier caractère du premier argument de preg_replace . Si c'est le cas, vous passez en fait tout le segment trouvé comme argument à votre PHP en ligne, puis vous l' eval . Cela a exactement les mêmes problèmes que eval si vous laissez l'entrée de l'utilisateur entrer dans votre fonction. L'exemple de code peut être remplacé en utilisant à la place preg_replace_callback . L'avantage est que vous avez écrit votre fonction, il est donc plus difficile pour un attaquant de modifier ce qui est évalué. Donc, vous écririez ce qui précède comme suit :

 // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html );

Laisser l'entrée utilisateur create_function s est également mauvais…

PHP a également la fonction create_function . Ceci est maintenant obsolète dans PHP 7.2, mais il était très similaire à eval et présentait les mêmes inconvénients de base : il permet de transformer une chaîne (le deuxième argument) en PHP exécutable. Et cela comportait les mêmes risques : il est trop facile pour vous de donner accidentellement à un cracker intelligent la capacité de faire n'importe quoi sur votre serveur si vous ne faites pas attention.

Celui-ci, si vous utilisez PHP au-dessus de 5.3, est encore plus facile à corriger que preg_replace . Vous pouvez simplement créer votre propre fonction anonyme sans utiliser de chaînes comme intermédiaires. C'est à la fois plus sécurisé et plus lisible, du moins à mes yeux.

assert est aussi eval -Like

assert n'est pas une fonction que de nombreux développeurs PHP utilisent, dans WordPress ou en dehors. Son intention est de faire des assertions très légères sur les conditions préalables de votre code. Mais il prend également en charge une opération de type eval . Pour cette raison, vous devez vous en méfier autant que de eval . Les assertions basées sur des chaînes (le cœur de la raison pour laquelle cela est mauvais) sont également obsolètes dans PHP 7.2, ce qui signifie qu'elles devraient être moins préoccupantes à l'avenir.

L'inclusion de fichiers variables est un moyen de permettre éventuellement l'exécution incontrôlée de PHP

Nous avons assez bien exploré pourquoi eval est mauvais, mais quelque chose comme include ou require($filename'.php') peut, en particulier lorsque $filename est défini à partir d'une valeur contrôlable par l'utilisateur, être également une mauvaise nouvelle. La raison est subtilement différente de eval . Les noms de fichiers variables sont souvent utilisés pour des choses comme le simple routage URL vers fichier dans les applications PHP non-WordPress. Mais vous pouvez également les voir utilisés dans WordPress.

Le cœur du problème est que lorsque vous include ou require (ou include_once ou require_once ), vous faites en sorte que votre script exécute le fichier inclus. Il s'agit plus ou moins d' eval conceptuellement ce fichier, bien que nous y pensions rarement de cette façon.

Si vous avez écrit tous les fichiers que votre variable peut include et que vous avez réfléchi à ce qui se passerait, tout va bien. Mais c'est une mauvaise nouvelle si vous n'avez pas réfléchi à ce que fera l' include password.php ou wp-config.php . C'est aussi une mauvaise nouvelle si quelqu'un pouvait ajouter un fichier malveillant puis exécuter votre include (bien qu'à ce stade, vous ayez probablement de plus gros problèmes).

La solution à cela n'est cependant pas trop difficile : le code dur inclut quand vous le pouvez. Lorsque vous ne pouvez pas, ayez soit une liste blanche (mieux) soit une liste noire des fichiers qui peuvent être inclus. Si les fichiers de la liste blanche (c'est-à-dire que vous avez vérifié ce qu'ils font lorsqu'ils sont ajoutés), vous saurez que vous êtes en sécurité. S'il ne figure pas sur votre liste blanche, votre script ne l'inclura pas. Avec ce simple ajustement, vous êtes assez en sécurité. Une liste blanche ressemblerait à ceci :

 $white_list = ['db.php', filter.php', 'condense.php'] If (in_array($white_list, $file_to_include)) { include($file_to_include); }

Ne transmettez jamais l'entrée utilisateur à shell_exec et aux variantes

C'est un grand. shell_exec , system , exec et backticks en PHP permettent tous au code que vous exécutez de parler au shell sous-jacent (généralement Unix). Ceci est similaire à ce qui rend eval dangereux mais doublé. Double car si vous laissez passer l'entrée de l'utilisateur par ici avec insouciance, l'attaquant n'est même pas lié par les contraintes de PHP.

La possibilité d'exécuter des commandes shell à partir de PHP peut être très utile en tant que développeur. Mais si jamais vous laissez l'entrée d'un utilisateur là-dedans, il a la capacité d'acquérir subrepticement de nombreux pouvoirs dangereux. J'irais donc jusqu'à dire que l'entrée utilisateur ne doit jamais être transmise aux fonctions de type shell_exec .

La meilleure façon de gérer ce type de situation, si vous étiez tenté de l'implémenter, serait de fournir aux utilisateurs l'accès à un petit ensemble de commandes shell prédéfinies sûres. Cela pourrait être possible de sécuriser. Mais même alors, je vous avertirais d'être très prudent.

Regarder pour unserialize ; Il exécute le code automatiquement

L'action principale d'appeler serialize sur un objet PHP vivant, de stocker ces données quelque part, puis d'utiliser cette valeur stockée plus tard pour unserialize cet objet à la vie est cool. C'est aussi assez courant, mais cela peut être risqué. Pourquoi risqué ? Si l'entrée de cet appel de unserialize n'est pas complètement sécurisée (par exemple, elle est stockée sous forme de cookie plutôt que dans votre base de données…), un attaquant peut modifier l'état interne de votre objet de manière à ce que l'appel de unserialize fasse quelque chose de mal.

Cet exploit est plus ésotérique et moins susceptible d'être remarqué qu'un problème d' eval . Mais si vous utilisez un cookie comme mécanisme de stockage pour les données sérialisées, n'utilisez pas la serialize pour ces données. Utilisez quelque chose comme json_encode et json_decode . Avec ces deux PHP n'exécutera jamais automatiquement aucun code.

La principale vulnérabilité ici est que lorsque PHP unserialize sa chaîne dans une classe, il appelle la méthode magique __wakeup sur cette classe. Si une entrée utilisateur non validée est autorisée à être unserialized , quelque chose comme un appel de base de données ou une suppression de fichier dans la méthode __wakeup pourrait potentiellement pointer vers un emplacement dangereux ou indésirable.

unserialize est distinct des vulnérabilités eval car il nécessite l'utilisation de méthodes magiques sur les objets. Plutôt que de créer son propre code, l'attaquant est obligé d'abuser de vos méthodes déjà écrites sur un objet. Les méthodes magiques __destruct et __toString sur les objets sont également risquées, comme l'explique cette page Wiki OWASP.

En général, tout va bien si vous n'utilisez pas les __wakeup , __destruct ou __toString dans vos classes. Mais comme vous verrez peut-être plus tard quelqu'un les ajouter à une classe, c'est une bonne idée de ne jamais laisser un utilisateur près de vos appels pour serialize et unserialize et transmettre toutes les données publiques pour ce type d'utilisation via quelque chose comme JSON ( json_encode et json_decode ) où il y a n'est jamais une exécution automatique de code.

Récupérer des URL avec file_get_contents est risqué

Une pratique courante lors de l'écriture rapide de code PHP qui doit appeler une URL externe consiste à rechercher file_get_contents . C'est rapide, c'est facile, mais ce n'est pas super sécurisé.

Le problème avec file_get_contents est subtil, mais il est assez courant que les hôtes configurent parfois PHP pour ne même pas vous permettre d'accéder à des URL externes. Ceci est destiné à vous protéger.

Le problème ici est que file_get_contents récupérera les pages distantes pour vous. Mais lorsqu'il le fait, il ne vérifie pas l'intégrité de la connexion au protocole HTTPS. Cela signifie que votre script pourrait potentiellement être victime d'une attaque de l'homme du milieu qui permettrait à un attaquant de mettre à peu près tout ce qu'il veut dans le résultat de votre page file_get_contents .

C'est une attaque plus ésotérique. Mais pour m'en protéger lorsque j'écris du PHP moderne (basé sur Composer), j'utilise presque toujours Guzzle pour envelopper l'API cURL plus sécurisée. Dans WordPress, c'est encore plus simple : utilisez wp_remote_get . Cela fonctionne de manière beaucoup plus cohérente que file_get_contents , et il vérifiera par défaut les connexions SSL. (Vous pouvez désactiver cela, mais, euh, peut-être pas ...) Mieux encore, mais un peu plus ennuyeux d'en parler, sont wp_safe_remote_get , etc. Celles-ci fonctionnent de la même manière que les fonctions sans safe_ dans leur nom, mais elles feront assurez-vous que les redirections et les transferts dangereux ne se produisent pas en cours de route.

Ne faites pas aveuglément confiance à la validation d'URL de filter_var

Donc celui-ci est un peu obscur, alors bravo à Chris Weigman pour l'avoir expliqué dans cette conférence WordCamp. En général, le filter_var de PHP est un excellent moyen de valider ou de nettoyer les données. (Cependant, ne vous trompez pas sur ce que vous essayez de faire...)

Le problème ici est assez spécifique : si vous essayez de l'utiliser pour vous assurer qu'une URL est sûre, filter_var ne valide pas le protocole. Ce n'est pas souvent un problème, mais si vous transmettez l'entrée de l'utilisateur à cette méthode pour validation et que vous utilisez FILTER_VALIDATE_URL , quelque chose comme javascript://comment%0aalert(1) passera. Autrement dit, cela peut être un très bon vecteur pour une attaque XSS de base dans un endroit auquel vous ne vous attendiez pas.

Pour valider une URL, la fonction esc_url de WordPress aura un impact similaire, mais ne laisse passer que les protocoles autorisés. javascript n'est pas dans la liste par défaut, il vous protégerait donc. Cependant, contrairement à filter_var , il renverra une chaîne vide (pas un faux) pour un protocole non autorisé qui lui est transmis.

Fonctions spécifiques à WordPress à surveiller

En plus des fonctions potentiellement vulnérables de core-PHP, certaines fonctions spécifiques à WordPress peuvent être un peu un piège. Certaines d'entre elles sont très similaires à la variété de fonctions dangereuses énumérées ci-dessus, d'autres un peu différentes.

WordPress désérialise avec maybe_unserialize

Celui-ci est probablement évident si vous lisez ce qui précède. Dans WordPress, il existe une fonction appelée maybe_unserialize et, comme vous vous en doutez, elle désérialise ce qui lui est transmis si nécessaire.

Il n'y a pas de nouvelle vulnérabilité que cela introduit, le problème est simplement que, tout comme la fonction de unserialize de base, celle-ci peut entraîner l'exploitation d'un objet vulnérable lorsqu'il n'est pas sérialisé.

is_admin ne répond pas si un utilisateur est un administrateur !

Celui-ci est assez simple, mais le nom de la fonction est ambigu, et il est donc susceptible de confondre les gens ou de manquer si vous êtes pressé. Vous devez toujours vérifier qu'un utilisateur qui essaie d'effectuer une action dans WordPress dispose des droits et privilèges nécessaires pour effectuer cette action. Pour cela, vous devez utiliser la fonction current_user_can .

Mais vous pourriez, à tort, penser que is_admin vous dira si l'utilisateur actuel est un compte de niveau administrateur et devrait donc pouvoir définir une option utilisée par votre plugin. C'est une erreur. Ce que fait is_admin dans WordPress, c'est plutôt vous dire si le chargement actuel de la page se trouve du côté de l'administration du site (par rapport au front-side). Ainsi, tout utilisateur pouvant accéder à une page d'administration (comme le « Tableau de bord ») pourra potentiellement passer ce contrôle. Tant que vous vous souvenez que is_admin concerne le type de page, pas l'utilisateur actuel, tout ira bien.

add_query_arg() ne nettoie pas les URL

Ce n'est pas si courant, mais il y a eu une grande vague de mises à jour dans l'écosystème WordPress il y a quelques années car la documentation publique sur ces fonctions n'était pas correcte. Le problème principal est que la fonction add_query_arg (et son inverse remove_query_arg ) ne nettoie pas automatiquement l'URL du site si une URL ne lui a pas été transmise, et les gens pensaient que c'était le cas. De nombreux plugins avaient été induits en erreur par le Codex et l'utilisaient de manière dangereuse.

La chose principale qu'ils devaient faire était différente : nettoyer le résultat d'un appel à cette fonction avant de l'utiliser. Si vous faites cela, vous êtes vraiment à l'abri des attaques XSS que vous pensiez qu'elles étaient. Donc ça ressemble à quelque chose comme :

 echo esc_url( add_query_arg( 'foo', 'bar' ) );

$wpdb->query() est ouvert à l'attaque par injection SQL

Si vous connaissez l'injection SQL, cela peut sembler idiot, voire superflu à énumérer. Parce que le fait est que vous accédez à une base de données de quelque manière que ce soit (par exemple en utilisant les pilotes de base de données mysqli ou PDO de PHP) pour créer des requêtes de base de données qui permettent des attaques par injection SQL.

La raison pour laquelle j'appelle spécifiquement $wpdb->query est que d'autres méthodes (comme insert , delete , etc.) sur $wpdb s'occupent des attaques par injection pour vous. De plus, si vous avez l'habitude de faire des requêtes de base de base de données WordPress avec WP_Query ou similaire, vous n'aurez pas besoin d'envisager l'injection SQL. C'est pourquoi je l'appelle : pour vous assurer que vous comprenez qu'une attaque par injection sur la base de données est possible lorsque vous essayez d'utiliser $wpdb pour créer votre propre requête.

Ce qu'il faut faire? Utilisez $wpdb->prepare() puis $wpdb->query() . Vous voudrez également vous assurer de vous préparer avant d'autres méthodes "d'obtention" de $wpdb comme get_row() et get_var() . Sinon, Bobby Tables pourrait vous avoir.

esc_sql ne vous protège pas non plus de l'injection SQL

Pour la plupart des développeurs WordPress, je dirais que esc_sql ne s'enregistre avec aucune signification, mais il le devrait. Comme nous venons de le mentionner, vous devriez utiliser wpdb->prepare() avant de faire une requête de base de données. Cela vous gardera en sécurité. Mais il est tentant et compréhensible qu'un développeur puisse esc_sql à la place. Et ils pourraient s'attendre à ce que ce soit sûr.

Le problème est que esc_sql n'a pas de protections aussi robustes contre l'injection SQL. C'est vraiment une version glorifiée de la fonction add_slashes de PHP, que l'on vous a découragé d'utiliser pour protéger votre base de données pendant des années.

Il y a plus à faire, mais c'est un grand début

La sécurité va bien au-delà de la simple recherche de fonctions dans votre code que les attaquants peuvent utiliser à mauvais escient. Nous n'avons pas, par exemple, discuté en profondeur de la nécessité de valider et de nettoyer toutes les données que vous recevez des utilisateurs et de les échapper avant de les mettre dans une page Web (bien que j'ai récemment publié un article sur ce sujet, "Protéger votre WordPress site contre une attaque de script intersite »). Mais vous pouvez et devez l'utiliser dans le cadre d'une stratégie de sécurité plus large.

Garder cette liste de fonctions faciles à utiliser à vos côtés pendant que vous effectuez une inspection finale avant de déployer un nouveau plugin dans WordPress est une excellente idée. Mais vous voudrez également vous assurer que vous faites confiance à la sécurité de votre hébergement, assurez-vous que vos utilisateurs ont de bons mots de passe, et bien plus encore.

La chose essentielle à retenir à propos de la sécurité est que votre maillon le plus faible est celui qui compte. Les bonnes pratiques dans un domaine renforcent d'éventuels points faibles ailleurs, mais elles ne peuvent jamais totalement le corriger. Mais soyez attentif à ces fonctions, et vous aurez une longueur d'avance sur la plupart.