Qu’est-ce qu’une vuln\u00e9rabilit\u00e9 ?<\/h2>\n\n\n\n
WordPress est programm\u00e9 avec le langage PHP.
Le code PHP permet d’obtenir des sites \u00ab\u00a0dynamiques\u00a0\u00bb. C’est \u00e0 dire que le contenu est g\u00e9n\u00e9r\u00e9 \u00e0 chaque page par un programme PHP. Un site dynamique permet aussi l’interaction avec les visiteurs. En termes techniques, il permet de recevoir et traiter des requ\u00eates.<\/p>\n\n\n\n
Cette force est aussi une faiblesse en ce sens qu’elle peut laisser place \u00e0 des interactions non d\u00e9sir\u00e9es, permettant ainsi le piratage d’un site internet.
On appelle cela une \u00ab\u00a0faille de s\u00e9curit\u00e9\u00a0\u00bb ou \u00ab\u00a0vuln\u00e9rabilit\u00e9\u00a0\u00bb.<\/p>\n\n\n\n
Les vuln\u00e9rabilit\u00e9s en PHP<\/h3>\n\n\n\n\n![\"\"](\"https:\/\/portail.lrob.fr\/wp-content\/uploads\/2023\/10\/new-php-logo.png\")
<\/figure>\n\n\n\nLes vuln\u00e9rabilit\u00e9s dans le code PHP peuvent avoir diverses causes.
En voici quelques exemples fr\u00e9quents.<\/p>\n<\/div>\n\n\n\n
\n- Entr\u00e9es non valid\u00e9es : Lorsque le code PHP accepte des donn\u00e9es d’utilisateurs, telles qu’un formulaire ou une requ\u00eate, sans validation appropri\u00e9e, il peut \u00eatre vuln\u00e9rable aux attaques d’injection de code malveillant.<\/li>\n\n\n\n
- Permissions excessives : L’attribution de permissions excessives aux fichiers et aux utilisateurs peut permettre des attaques de manipulation non autoris\u00e9e.<\/li>\n\n\n\n
- Mauvaise gestion des erreurs : La r\u00e9v\u00e9lation d’informations sensibles dans les messages d’erreur peut donner aux attaquants des indices pour exploiter davantage le syst\u00e8me.<\/li>\n<\/ol>\n\n\n\n\n\n
En outre, il peut y avoir des vuln\u00e9rabilit\u00e9s dans PHP. L’ex\u00e9cuteur PHP lui-m\u00eame, contient parfois des failles de s\u00e9curit\u00e9 s’il n’est pas tenu \u00e0 jour. (voir image)<\/p>\n\n\n\n
D’autres failles non li\u00e9es directement \u00e0 PHP telles que les failles XSS sont \u00e9galement courantes. Celles-ci permettent d’ex\u00e9cuter du code malveillant.<\/p>\n\n\n\n
Nous allons voir comment cela s’articule concr\u00e8tement pour WordPress.<\/p>\n<\/div>\n\n\n\n![\"\"](\"https:\/\/portail.lrob.fr\/wp-content\/uploads\/2023\/10\/php-supported-versions-1024x673.png\")
Source: Versions de PHP support\u00e9es<\/a><\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n\nLes vuln\u00e9rabilit\u00e9s des sites WordPress<\/h2>\n\n\n\nFailles de s\u00e9curit\u00e9 dans WordPress<\/h3>\n\n\n\n\n![\"\"](\"https:\/\/portail.lrob.fr\/wp-content\/uploads\/2022\/06\/icons8-wordpress-480-150x150.png\")
<\/figure>\n\n\n\nWordPress est un syst\u00e8me de gestion de contenu robuste, mais il comporte pr\u00e8s d’un million de lignes de code PHP (924.096 lignes<\/a> pr\u00e9sentement).
WordPress, ce sont aussi 59.772 plugins<\/a> et 11.378 th\u00e8mes<\/a> disponibles rien que sur wordpress.org<\/a>. Des millions de lignes de code en plus disponibles \u00e0 l’installation sur votre site.
Cette richesse de code cr\u00e9e un terrain fertile pour les failles de s\u00e9curit\u00e9. Plus vous multipliez le code, plus vous multipliez le risque. Ainsi, chaque jour, des vuln\u00e9rabilit\u00e9s sont d\u00e9couvertes. Elles peuvent se trouver dans le c\u0153ur de WordPress mais aussi des th\u00e8mes et plugins install\u00e9s.<\/p>\n<\/div>\n\n\n\nD\u00e9tection, correction, r\u00e9v\u00e9lation des failles<\/h3>\n\n\n\n
Si un intervenant d\u00e9tecte une faille (un d\u00e9veloppeur particulier, un \u00ab\u00a0white hat\u00a0\u00bb, un organisme sp\u00e9cialis\u00e9 dans la s\u00e9curit\u00e9), il averti les d\u00e9veloppeurs du script comportant la faille.<\/p>\n\n\n\n
Si les d\u00e9veloppeurs sont r\u00e9actifs, ils corrigent la faillent et publient le correctif.<\/p>\n\n\n\n
Puis, typiquement 30 \u00e0 90 jours apr\u00e8s sa d\u00e9couverte, la faille de s\u00e9curit\u00e9 est r\u00e9v\u00e9l\u00e9e publiquement. Afin d’une part de donner cr\u00e9dits de la d\u00e9couverte au lanceur d’alerte, et d’autre part d’avertir les usagers du script du risque encouru en cas de non mise \u00e0 jour.<\/p>\n\n\n\n
Faille actuelle non corrig\u00e9e<\/h4>\n\n\n\n
WordPress comporte actuellement une faille non corrig\u00e9e<\/a> depuis la version 6.1.1 (donc depuis plusieurs mois). Celle-ci permet d’utiliser un site web pour ex\u00e9cuter des requ\u00eates vers d’autres cibles. Elle est mitigable en bloquant l’acc\u00e8s \u00e0 xmlrpc.php et en d\u00e9sactivant les pingbacks WordPress (s\u00e9curisation effectu\u00e9e sur tous les sites que j’ai en gestion avant m\u00eame la d\u00e9tection de cette faille).<\/p>\n<\/div>\n\n\n\n\nQuand est-ce que WordPress est vuln\u00e9rable et que faire ?<\/h2>\n\n\n\nFailles r\u00e9v\u00e9l\u00e9es<\/h3>\n\n\n\n
Lorsqu’une faille est r\u00e9v\u00e9l\u00e9e, toutes les installations poss\u00e9dant le script vuln\u00e9rable sont par essence atteints de cette vuln\u00e9rabilit\u00e9. Les pirates risquent d’exploiter la faille si c’est votre cas.<\/p>\n\n\n\n
On trouve alors deux cas de vuln\u00e9rabilit\u00e9s :<\/p>\n\n\n\n
\n- Votre site comporte un script (WordPress, plugin, th\u00e8me) ayant une faille connue et n’\u00e9tant pas corrig\u00e9e par les d\u00e9veloppeurs. Le d\u00e9veloppement de ce script est peut-\u00eatre abandonn\u00e9. Il convient alors de d\u00e9sactiver ce script ou de le remplacer par un script non vuln\u00e9rable et mieux suivi par ses d\u00e9veloppeurs.<\/li>\n\n\n\n
- Votre site n’est pas \u00e0 jour. Vous n’avez pas corrig\u00e9 la faille de s\u00e9curit\u00e9. Il faut donc effectuer les mises \u00e0 jour le plus r\u00e9guli\u00e8rement possible et vous assurer de ne pas avoir de script obsol\u00e8te (ce qui vous mettrait potentiellement dans le cas pr\u00e9c\u00e9dent \u00e0 terme).<\/li>\n<\/ul>\n\n\n\n
Failles \u00ab\u00a0zero-day\u00a0\u00bb<\/h3>\n\n\n\n
Parfois, les pirates vont trouver une faille avant qu’elle soit r\u00e9v\u00e9l\u00e9e puis corrig\u00e9e. Ils vont l’exploiter directement. On appelle cela une faille \u00ab\u00a0zero-day\u00a0\u00bb.<\/p>\n\n\n\n
Plus un script est populaire, plus les pirates vont chercher des failles zero-day dans celui-ci. Cela est rare, mais arrive.
Voici une autre raison de concevoir des sites simples : Plus vous multipliez les plugins populaires, plus vous multipliez la vuln\u00e9rabilit\u00e9 de votre site WordPress. Non seulement aux failles zero-day, mais \u00e9galement aux failles en g\u00e9n\u00e9ral.<\/p>\n\n\n\n
Pour se prot\u00e9ger des failles 0-day, il faut que le serveur h\u00e9bergeant votre site soit s\u00e9curis\u00e9. Pour cela, il peut notamment bloquer les requ\u00eates suspectes des pirates \u00e0 l’aide d’un pare-feu applicatif. Puis bloquer les IP attaquantes avec par exemple fail2ban. Cela n’est g\u00e9n\u00e9ralement pas le cas sur les offres d’h\u00e9bergement mutualis\u00e9es. A l’exception d’HaiSoft<\/a> chez qui j’ai pouss\u00e9 ces s\u00e9curit\u00e9s, ce qui a d’ailleurs grandement divis\u00e9 le nombre de piratages. Mais cela peut cr\u00e9er des faux positifs : Des requ\u00eates bloqu\u00e9es alors qu’elles sont l\u00e9gitimes, en particulier avec les builders WordPress (Elementor, Divi, WP-Bakery et autres). Le support technique demand\u00e9 est alors sup\u00e9rieur, raison pour laquelle la plupart des prestataires n’impl\u00e9mentent pas ce type de s\u00e9curit\u00e9s. La s\u00e9curit\u00e9 est toujours plus complexe que l’absence de s\u00e9curit\u00e9.<\/p>\n\n\n\nMalgr\u00e9 toutes les s\u00e9curit\u00e9s possibles en place, il faut garder \u00e0 l’esprit que certaines requ\u00eates pirate peuvent passer outre les filets. Le risque z\u00e9ro n’existe pas et quiconque pr\u00e9tend le contraire est un ignorant ou un menteur.<\/p>\n\n\n\n
Alors comme la s\u00e9curit\u00e9 parfaite n’existe pas, partez du principe que votre site peut \u00eatre pirat\u00e9 demain. Si cela arrive, que faites-vous ? Vous avez int\u00e9r\u00eat \u00e0 avoir une sauvegarde \u00e0 jour, facilement restorable et qui ne soit pas stock\u00e9e dans votre site.<\/p>\n<\/div>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
Les piratages n’arrivent pas qu’au autres. Tr\u00e8s r\u00e9guli\u00e8rement, des possesseurs de sites WordPress viennent \u00e0 ma rencontre avec un site web pirat\u00e9 \u00e0 r\u00e9parer<\/a>.<\/p>\n\n\n\nTout syst\u00e8me informatique est potentiellement vuln\u00e9rable, y-compris votre site WordPress. L’enjeu est de minimiser les risques de piratage en appliquant toutes les mesures pr\u00e9ventives. Cela passe d’abord par un serveur \u00e0 jour et s\u00e9curis\u00e9, capable de bloquer les attaques. Puis, cela passe par un suivi r\u00e9gulier de votre site WordPress et une mise \u00e0 jour la plus fr\u00e9quente possible, une v\u00e9rification permanente des failles de s\u00e9curit\u00e9 connues et une action rapide en cas de probl\u00e8me. Dans tous les cas, une sauvegarde externalis\u00e9e, automatis\u00e9e et ind\u00e9pendante de votre site doit \u00eatre effectu\u00e9e quotidiennement. C’est pr\u00e9cis\u00e9ment l’ensemble des services que vous retrouverez dans mes offres de Webmastering WordPress<\/a>.<\/p>\n\n\n\nSi votre site est important pour votre entreprise, n’attendez pas d’\u00eatre pirat\u00e9s, prenez les devants et faites v\u00e9rifier votre site gr\u00e2ce \u00e0 un audit de s\u00e9curit\u00e9 WordPress<\/a> ou passez directement sur mon offre de Webmastering<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"Beaucoup se demandent comment WordPress peut \u00eatre vuln\u00e9rable aux attaques malgr\u00e9 sa popularit\u00e9 et son suivi. D’autres ignorent totalement le risque. Analyse. Qu’est-ce qu’une vuln\u00e9rabilit\u00e9 ? WordPress est programm\u00e9 avec le langage PHP.Le code PHP permet d’obtenir des sites \u00ab\u00a0dynamiques\u00a0\u00bb. C’est \u00e0 dire que le contenu est g\u00e9n\u00e9r\u00e9 \u00e0 chaque page par un programme PHP. […]<\/p>\n","protected":false},"author":1,"featured_media":3339,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41],"tags":[],"class_list":["post-3179","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-securite-wordpress"],"_links":{"self":[{"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/comments?post=3179"}],"version-history":[{"count":0,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/media\/3339"}],"wp:attachment":[{"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/media?parent=3179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/categories?post=3179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/tags?post=3179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
<\/figure>\n\n\n\nLes vuln\u00e9rabilit\u00e9s dans le code PHP peuvent avoir diverses causes.
En voici quelques exemples fr\u00e9quents.<\/p>\n<\/div>\n\n\n\n
- \n
- Entr\u00e9es non valid\u00e9es : Lorsque le code PHP accepte des donn\u00e9es d’utilisateurs, telles qu’un formulaire ou une requ\u00eate, sans validation appropri\u00e9e, il peut \u00eatre vuln\u00e9rable aux attaques d’injection de code malveillant.<\/li>\n\n\n\n
- Permissions excessives : L’attribution de permissions excessives aux fichiers et aux utilisateurs peut permettre des attaques de manipulation non autoris\u00e9e.<\/li>\n\n\n\n
- Mauvaise gestion des erreurs : La r\u00e9v\u00e9lation d’informations sensibles dans les messages d’erreur peut donner aux attaquants des indices pour exploiter davantage le syst\u00e8me.<\/li>\n<\/ol>\n\n\n\n\n\n
En outre, il peut y avoir des vuln\u00e9rabilit\u00e9s dans PHP. L’ex\u00e9cuteur PHP lui-m\u00eame, contient parfois des failles de s\u00e9curit\u00e9 s’il n’est pas tenu \u00e0 jour. (voir image)<\/p>\n\n\n\n
D’autres failles non li\u00e9es directement \u00e0 PHP telles que les failles XSS sont \u00e9galement courantes. Celles-ci permettent d’ex\u00e9cuter du code malveillant.<\/p>\n\n\n\n
Nous allons voir comment cela s’articule concr\u00e8tement pour WordPress.<\/p>\n<\/div>\n\n\n\n
Source: Versions de PHP support\u00e9es<\/a><\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n \nLes vuln\u00e9rabilit\u00e9s des sites WordPress<\/h2>\n\n\n\n
Failles de s\u00e9curit\u00e9 dans WordPress<\/h3>\n\n\n\n
\n<\/figure>\n\n\n\nWordPress est un syst\u00e8me de gestion de contenu robuste, mais il comporte pr\u00e8s d’un million de lignes de code PHP (924.096 lignes<\/a> pr\u00e9sentement).
WordPress, ce sont aussi 59.772 plugins<\/a> et 11.378 th\u00e8mes<\/a> disponibles rien que sur wordpress.org<\/a>. Des millions de lignes de code en plus disponibles \u00e0 l’installation sur votre site.
Cette richesse de code cr\u00e9e un terrain fertile pour les failles de s\u00e9curit\u00e9. Plus vous multipliez le code, plus vous multipliez le risque. Ainsi, chaque jour, des vuln\u00e9rabilit\u00e9s sont d\u00e9couvertes. Elles peuvent se trouver dans le c\u0153ur de WordPress mais aussi des th\u00e8mes et plugins install\u00e9s.<\/p>\n<\/div>\n\n\n\nD\u00e9tection, correction, r\u00e9v\u00e9lation des failles<\/h3>\n\n\n\n
Si un intervenant d\u00e9tecte une faille (un d\u00e9veloppeur particulier, un \u00ab\u00a0white hat\u00a0\u00bb, un organisme sp\u00e9cialis\u00e9 dans la s\u00e9curit\u00e9), il averti les d\u00e9veloppeurs du script comportant la faille.<\/p>\n\n\n\n
Si les d\u00e9veloppeurs sont r\u00e9actifs, ils corrigent la faillent et publient le correctif.<\/p>\n\n\n\n
Puis, typiquement 30 \u00e0 90 jours apr\u00e8s sa d\u00e9couverte, la faille de s\u00e9curit\u00e9 est r\u00e9v\u00e9l\u00e9e publiquement. Afin d’une part de donner cr\u00e9dits de la d\u00e9couverte au lanceur d’alerte, et d’autre part d’avertir les usagers du script du risque encouru en cas de non mise \u00e0 jour.<\/p>\n\n\n\n
Faille actuelle non corrig\u00e9e<\/h4>\n\n\n\n
WordPress comporte actuellement une faille non corrig\u00e9e<\/a> depuis la version 6.1.1 (donc depuis plusieurs mois). Celle-ci permet d’utiliser un site web pour ex\u00e9cuter des requ\u00eates vers d’autres cibles. Elle est mitigable en bloquant l’acc\u00e8s \u00e0 xmlrpc.php et en d\u00e9sactivant les pingbacks WordPress (s\u00e9curisation effectu\u00e9e sur tous les sites que j’ai en gestion avant m\u00eame la d\u00e9tection de cette faille).<\/p>\n<\/div>\n\n\n\n
\nQuand est-ce que WordPress est vuln\u00e9rable et que faire ?<\/h2>\n\n\n\n
Failles r\u00e9v\u00e9l\u00e9es<\/h3>\n\n\n\n
Lorsqu’une faille est r\u00e9v\u00e9l\u00e9e, toutes les installations poss\u00e9dant le script vuln\u00e9rable sont par essence atteints de cette vuln\u00e9rabilit\u00e9. Les pirates risquent d’exploiter la faille si c’est votre cas.<\/p>\n\n\n\n
On trouve alors deux cas de vuln\u00e9rabilit\u00e9s :<\/p>\n\n\n\n
- \n
- Votre site comporte un script (WordPress, plugin, th\u00e8me) ayant une faille connue et n’\u00e9tant pas corrig\u00e9e par les d\u00e9veloppeurs. Le d\u00e9veloppement de ce script est peut-\u00eatre abandonn\u00e9. Il convient alors de d\u00e9sactiver ce script ou de le remplacer par un script non vuln\u00e9rable et mieux suivi par ses d\u00e9veloppeurs.<\/li>\n\n\n\n
- Votre site n’est pas \u00e0 jour. Vous n’avez pas corrig\u00e9 la faille de s\u00e9curit\u00e9. Il faut donc effectuer les mises \u00e0 jour le plus r\u00e9guli\u00e8rement possible et vous assurer de ne pas avoir de script obsol\u00e8te (ce qui vous mettrait potentiellement dans le cas pr\u00e9c\u00e9dent \u00e0 terme).<\/li>\n<\/ul>\n\n\n\n
Failles \u00ab\u00a0zero-day\u00a0\u00bb<\/h3>\n\n\n\n
Parfois, les pirates vont trouver une faille avant qu’elle soit r\u00e9v\u00e9l\u00e9e puis corrig\u00e9e. Ils vont l’exploiter directement. On appelle cela une faille \u00ab\u00a0zero-day\u00a0\u00bb.<\/p>\n\n\n\n
Plus un script est populaire, plus les pirates vont chercher des failles zero-day dans celui-ci. Cela est rare, mais arrive.
Voici une autre raison de concevoir des sites simples : Plus vous multipliez les plugins populaires, plus vous multipliez la vuln\u00e9rabilit\u00e9 de votre site WordPress. Non seulement aux failles zero-day, mais \u00e9galement aux failles en g\u00e9n\u00e9ral.<\/p>\n\n\n\nPour se prot\u00e9ger des failles 0-day, il faut que le serveur h\u00e9bergeant votre site soit s\u00e9curis\u00e9. Pour cela, il peut notamment bloquer les requ\u00eates suspectes des pirates \u00e0 l’aide d’un pare-feu applicatif. Puis bloquer les IP attaquantes avec par exemple fail2ban. Cela n’est g\u00e9n\u00e9ralement pas le cas sur les offres d’h\u00e9bergement mutualis\u00e9es. A l’exception d’HaiSoft<\/a> chez qui j’ai pouss\u00e9 ces s\u00e9curit\u00e9s, ce qui a d’ailleurs grandement divis\u00e9 le nombre de piratages. Mais cela peut cr\u00e9er des faux positifs : Des requ\u00eates bloqu\u00e9es alors qu’elles sont l\u00e9gitimes, en particulier avec les builders WordPress (Elementor, Divi, WP-Bakery et autres). Le support technique demand\u00e9 est alors sup\u00e9rieur, raison pour laquelle la plupart des prestataires n’impl\u00e9mentent pas ce type de s\u00e9curit\u00e9s. La s\u00e9curit\u00e9 est toujours plus complexe que l’absence de s\u00e9curit\u00e9.<\/p>\n\n\n\n
Malgr\u00e9 toutes les s\u00e9curit\u00e9s possibles en place, il faut garder \u00e0 l’esprit que certaines requ\u00eates pirate peuvent passer outre les filets. Le risque z\u00e9ro n’existe pas et quiconque pr\u00e9tend le contraire est un ignorant ou un menteur.<\/p>\n\n\n\n
Alors comme la s\u00e9curit\u00e9 parfaite n’existe pas, partez du principe que votre site peut \u00eatre pirat\u00e9 demain. Si cela arrive, que faites-vous ? Vous avez int\u00e9r\u00eat \u00e0 avoir une sauvegarde \u00e0 jour, facilement restorable et qui ne soit pas stock\u00e9e dans votre site.<\/p>\n<\/div>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
Les piratages n’arrivent pas qu’au autres. Tr\u00e8s r\u00e9guli\u00e8rement, des possesseurs de sites WordPress viennent \u00e0 ma rencontre avec un site web pirat\u00e9 \u00e0 r\u00e9parer<\/a>.<\/p>\n\n\n\n
Tout syst\u00e8me informatique est potentiellement vuln\u00e9rable, y-compris votre site WordPress. L’enjeu est de minimiser les risques de piratage en appliquant toutes les mesures pr\u00e9ventives. Cela passe d’abord par un serveur \u00e0 jour et s\u00e9curis\u00e9, capable de bloquer les attaques. Puis, cela passe par un suivi r\u00e9gulier de votre site WordPress et une mise \u00e0 jour la plus fr\u00e9quente possible, une v\u00e9rification permanente des failles de s\u00e9curit\u00e9 connues et une action rapide en cas de probl\u00e8me. Dans tous les cas, une sauvegarde externalis\u00e9e, automatis\u00e9e et ind\u00e9pendante de votre site doit \u00eatre effectu\u00e9e quotidiennement. C’est pr\u00e9cis\u00e9ment l’ensemble des services que vous retrouverez dans mes offres de Webmastering WordPress<\/a>.<\/p>\n\n\n\n
Si votre site est important pour votre entreprise, n’attendez pas d’\u00eatre pirat\u00e9s, prenez les devants et faites v\u00e9rifier votre site gr\u00e2ce \u00e0 un audit de s\u00e9curit\u00e9 WordPress<\/a> ou passez directement sur mon offre de Webmastering<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"
Beaucoup se demandent comment WordPress peut \u00eatre vuln\u00e9rable aux attaques malgr\u00e9 sa popularit\u00e9 et son suivi. D’autres ignorent totalement le risque. Analyse. Qu’est-ce qu’une vuln\u00e9rabilit\u00e9 ? WordPress est programm\u00e9 avec le langage PHP.Le code PHP permet d’obtenir des sites \u00ab\u00a0dynamiques\u00a0\u00bb. C’est \u00e0 dire que le contenu est g\u00e9n\u00e9r\u00e9 \u00e0 chaque page par un programme PHP. […]<\/p>\n","protected":false},"author":1,"featured_media":3339,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41],"tags":[],"class_list":["post-3179","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-securite-wordpress"],"_links":{"self":[{"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/comments?post=3179"}],"version-history":[{"count":0,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/media\/3339"}],"wp:attachment":[{"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/media?parent=3179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/categories?post=3179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/portail.lrob.fr\/en\/wp-json\/wp\/v2\/tags?post=3179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}