Reprise du message précédent :
J'ai reçu la réponse de Gandi et pour eux, ça dépend bien de moi, confirmant l'analyse de FlorentG
 
Je n'ai pas encore eu le temps de suivre les recommandation de FlorentG mais je regarderais ça la semaine prochaine après le gros des inscriptions : actuellement, j'ai juste à envoyer un message aux personnes qui utilisent des mails hotmail ou outlook (vive les modèles de Thunderbird ), mais si je casse un truc en faisant les modifications et que je me retrouve à devoir envoyer des messages à tout le monde, voir à ne plus avoir les redirections qui fonctionnent, ça va être encore plus galère.

Ah ben clairement SPF et DMARC sont nécessaire de nos jours, ne serait ce qu'avec des enregistrements minimum (et trop permissif ).
 
Sans doute que DKIM va le devenir un jour, ce qui ne serait pas un mal pour réguler tout les e-mails illégitime mais comme tout les serveurs d'envoi ne sont pas encore prêt je penses que ce n'est pas encore pour tout de suite...
 
Après leur message gagnerait à être plus clair, celui de Gmail ne laisse aucune ambiguïté sur la démarche à accomplir pour régler le problème :

Quand je pense que Free a mis le DKIM il y a seulement quelques années (2021 je crois) mais uniquement sur free.fr et pas sur les autres noms de domaine qu'il possède Orange, Sfr et Bouygues, pas sûr que ça soit mis en place.

Bonjour est il possible depuis fizella de mettre à jour la versions PHP d'un site wordpress ?  
 
J'ai plus acces à mon compte wordpress car le mail n'existe plus.

T'es hébergé où ? Il reste quelques hébergeurs chez qui on peut spécifier la version de PHP par un fichier spécial (et donc modifiable via FTP), mais il n'y a rien de "standard" (quand c'est seulement possible).

Hello, je suis chez OVH (j'ai contacté le SV) j'ai commencé la procédure de changement de mail pour, je l'espère retrouver mes accès à ce compte.

 
Chez ovh, c'est sur ton espace que tu fais le changement de version php.

L'interface permet de générer un fichier .ovhconfig au niveau au dessus du www (à la racine du ftp) donc techniquement modifiable sans l'accès au backoffice.  
En tout cas c'était le cas à une époque, après il vaut mieux passer par l'interface car toute les valeurs ne seront pas forcément reconnus.

Chez O2switch et PlanetHoster c'est possible avec une méthode analogue... Chez Infomaniak c'est un sélecteur dans le panel.

C'est à ça que je pensais. Et ça à l'air de toujours fonctionner, cf Modifier la configuration de l'hébergement web depuis le fichier « .ovhconfig ».

Merci, vous pouvez me dire la marche à suivre étape par étape, car je ne voudrais pas mettre le site KO.  
 
j'ai déjà fizella.

Connecte-toi à ton site par FTP, et télécharge le fichier .ovhconfig qui doit être à la racine. Ensuite poste ici le contenu, et on te dira ce qu'il faut changer.

Oui, la doc que t'a donné FlorentG ( https://help.ovhcloud.com/csm/fr-we [...] -ovhconfig ) est déjà assez clair, on va pas recopier ici ce qui y est écrit...

Ok je vous envoie ça demain.

désoler du retard  
 
app.engine=php
app.engine.version=7.2
http.firewall=none
environment=production
container.image=stable

Les valeurs possible via la back OVH pour les versions de php  sont : 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2, 8.3

Ne passe peut-être pas directement à une 8.3, c'est risqué avec certains plugins. Je commencerai avec la 7.4, ensuite la 8.0, etc.

donc je fais 7.4 et je renvois le document ?

Exactement ! Et si jamais il y avait un soucis, tu peux remettre comme c'était.

Ok merci de vos retours.

Tiens une question WordPress + python.  
 
Depuis Python, je veux pouvoir récupérer le résultat d'une query WordPress. Par exemple, j'ai un custom field qui est une base de donnée d'entreprises avec contact, num de tel etc...
 
Je veux query ce custom field depuis un script externe à WordPress écrit en python.
 
Quelle est selon vous la meilleure méthode, la plus propre et la moins risquée en terme de sécurité (PS : python et le code en python se trouvent sur le même serveur que WP).
 
Je sais que je peux utiliser XML-RPC, mais ça me semble pas super génial, déjà parce qu'en terme de sécu, je dois laisser xml-rcp actif (même si je peux bloquer toutes les queries qui lui sont adressées à part celle provenant du surveur via son IP par exemple).
 
D'autres suggestions ?
 
PS : la librairie en python s'appelle python-wordpress-xmlrpc et elle est très simple à utiliser.
 
https://python-wordpress-xmlrpc.rea [...] en/latest/
 
À noter que cette librairie semble vieille (last version : June 29, 2014)

Bon je vais commencer à me répondre. Une première piste : WordPress REST API avec appel à wp-json.
 
Je continue mes recherches...

Bon je confirme que WordPress Rest API est une solution vraiment facile à mettre en place. Ça crée quand même un trou de sécu car il faut activer application password (qui est désactivée par défaut par Wordfence).
 
BTW, xml-rpc est déprécié.

Pour ce que ça vaux c'est le genre de cas ou je préférerais coder un bout de plugin, une page du theme (ou un simple script dans un dossier à la racine), dans lequel je code une sécurité basique (vérification de l'origine de l'appel), plutôt que rouvrir l'API REST.
Y'a des cas ou on a pas le choix mais quand on peut assez facilement faire autrement...
 
Après je suis ptet un peu parano mais je me méfie un peu, la sécurité et Wordpress sont des sujets sensible.

 
 
Non mais j'ai déjà des plugins codés à la mano (c'est un projet perso btw) pour d'autres trucs. Le but ici, c'est de pouvoir interfacer Python avec WordPress pour certains scripts pythons appelés par CRON. Mon script python utilise des APIs type OpenAI, crée un XML (mais a besoin de certaines infos qui se trouvent dans WP d'où le besoin de WP Rest API) et ensuite, un plugin WP va utiliser ce XML pour créer des posts. Je pourrais aussi tout faire en PHP depuis le plugin. Je pourrais également appeler le script python avec un PHP exec ou un truc du genre... Mais j'ai envie de séparer les deux car plus tard, si je scale l'ensemble, la partie python pourrait être dans un conteneur séparé.

Je ne doutes pas que tu saches faire des plugin WP (vous avez surement dut avoir à en faire plus souvent que nous dans ta boite), mais ce que je dit c'est que du coups, à ta place j'aurais préféré avoir mon bout de code sur une url connu de moi seul et gérant ma propre sécurité que d'ouvrir l'API REST, dont tout les hackers connaissent le fonctionnement et à la moindre faille de sécurité d'un plugin en maj auto on s'expose à un retour de bâton.
 
Après comme je le disais c'est sans doute un excès de paranoïa de ma part.

 
Non, je pense que tu as probablement raison. Je suis en train de regarder si cette API Rest pourrait être autorisée uniquement par localhost ou un truc du genre. Il y a aussi la possibilité de lire directement la BDD depuis python.
 
Edit :
 
https://www.jucra.com/whmcs/knowled [...] t-API.html
 
Apparemment, avec un truc comme ça, ça devrait le faire...

Y'a toujours plusieurs façon de faire, perso sur du WP j'aime pas trop taper direct dans la BDD, mais après chacun voit midi à sa porte...
Dans tous les cas sans difficile de savoir ce qui est le plus susceptible de péter à l'avenir.
Ce serais moi j'aurais plutôt tendance à utiliser des primitives d'accès à la BDD genre get_post_meta mais je ne sais pas exactement ce que fait ton projet donc je suis probablement à coté de la plaque.
 
EDIT: effectivement avec une restriction de l'API au localhost ça restreint quand même énormément le vecteur d'attaque, y'aura toujours l'upload de fichier malveillant mais de toute façon, quand on en est là le gars n'as plus qu'a ouvrir le config.php pour être en mode openbar donc bon...

Sur un des sites que j'héberge (je ne l'ai pas configuré, j'ai juste fait une migration vers mon serveur en gardant la configuration d'origine), Wordpress m'indique que la taille limite des médias est 1M (j'ai aussi une erreur le lien que vous avez suivi est expiré ou un truc du genre et dans les conseils, ils disent de modifier certaines valeurs - je doute que ça règle la question, mais 1M, c'est trop faible de toute façon), alors que par ailleurs, la section sur la santé du site reconnait bien la limite de 8M fixé dans php.ini et au niveau du serveur.

J'ai regardé dans le fichier functions.php du thème (et celui du thème enfant), dans wp-config, je n'ai rien vu en relation avec upload_max_size.

Quelqu'un a une idée ?

Edit : oh, comme c'est un système avec multi-sites, il y a un réglage spécifique dans le réseau… Bon, faut maintenant que je trouve pourquoi alors que je suis Super Admin, on me refuse de modifier cette valeur (ou trouver le champ correspondant dans la base de données et y aller à la minime...)

Edit 2: ok, j'ai la bonne valeur, quelle idée d'avoir autant d'endroits où la changer, surtout que ça ne semble pas possible de la personnaliser par site du réseau, donc ça semble un poil stupide de la définir au niveau du réseau alors qu'elle est déjà défini côté serveur ou PHP…

Reste à régler les autres erreurs mais demain est un autre jour.

Ça dépend des hébergeurs en fait, souvent t'as pas accès au php.ini.

Bonjour à tous, je suis en discussion avec des développeurs pour rafraîchir un site vitrine Wordpress vieux de 6 ans (donc mise à jour vers dernière version, mise à jour du template + plugins etc).
 
On a attiré mon attention sur la vulnérabilité potentielle des sites Wordpress. Quels sont, selon vous, les points d'attention que je dois demander au développeur vérifier/configurer/mettre en place en priorité dans la foulée de la mise à jour pour renforcer la sécurité du site (même si j'ai bien conscience que ce ne sera jamais étanche à 100% contre les attaques) ?
 
Modifications de configurations/deactivation de fonctionnalités/installation de plugins sécurité connus, reconnus et maintenus ?
 
Et en complément de la sécurité, il me faudra aussi un bon backup, des recommendations de plugins ou méthodologies efficaces au passage ? Ou stockez-vous vos backups de manière automatisée ?  
 
Merci pour vos conseils

Bonjour,

Les points importants :
- PHP 8.0 mini
- Tous les plugins doivent être compatibles Wordpress 6.7 sinon il faut les remplacer
- Installer un outil tel que Wordfence, ça permet d'avoir un bon baromètre de la sécurisation du site. Il dit si tel ou tel plugin, thèmes... contient des failles de sécurité
- Compte "admin" par défaut désactivé voire supprimé
- Créer 2 comptes admins (1 compte principal, 1 compte de secours) avec 2 noms distincts et 2 mots de passe différents très forts (10/15 caractères alphanumériques, minuscules, majuscules, caractères spéciaux)
- Le compte gérant la chaine de connexion à la base de données doit avoir un mot de passe très fort
- Certificat SSL pour l'url (Je le précise même si c'est obligatoire)
- Pour le backup, perso, je laisse faire mon hébergeur (Hostinger en l'occurence) qui gère plusieurs sauvegardes des fichiers et de la BDD. En cas de crash, je restaure à la date souhaitée via l'interface Hostinger.

D'ailleurs verifiez que vous avez bien a votre plugin really simple ssl qui est à jour !
https://korben.info/faille-critique [...] ation.html

 
Pour le backup, j'utilise le plugin wpvivid en version gratuite d'une part parce qu'il est simple et d'autre part il gère le clonage/transfert facilement.
 
Rien d'automatique en revanche, je fais une sauvegarde manuelle tous les 15 ou 30 jours avant de passer les mises à jour wp/plugins (au cas ou une maj provoque un crash, ça m'est déjà arrivé) puis je la télécharge en local. Je supprime l'ancienne lorsque la nouvelle s'est bien déroulée jusqu'au bout.
 
Pour la sécu, j'avais testé Wordfence mais une usine à gaz que j'ai remplacé par Secupress dont la version gratuite est - pour moi - suffisante.
 
Depuis le conflit en Ukraine, les attaques me semblent bien plus nombreuses et concernent surtout les .com

Quelques considérations supplémentaires pour faire suite aux autres posts :
 
On utilise SolidWP (anciennement iThemes Security) pour :
 - protéger du brute force (ban de l'IP au bout de quelques tentatives)
 - renommer l'URL d'admin (éloigne les script kiddies)
 - parfois on rajoute encore un Captcha sur la connexion/perte de mot de passe
 
J'ai aussi utilisé NinjaScanner/Firewall pour :
 - scanner toutes les 24h le site, et envoyer un rapport si un fichier a changé. J'ai pu parfois observer sur certains sites dont les clients ne voulaient pas le contrat de maintenance, (donc pas mis à jour) que les hackers t'installent une backdoor, et la laissent dormante pendant quelques mois. Puis ça s'active. Scanner périodiquement permet ainsi d'attraper toute tentative d'installation d'un script
 - envoyer une alerte si un fichier récemment créé est accédé. Parfois aussitôt backdooré, aussitôt hacké, c'est très utile pour savoir si une attaque est en cours.
 
Pour les comptes, comme indiqué par les autres, ne surtout pas utiliser "admin." Pas sûr qu'avoir plusieurs compte soit utile. Je crois que ce qui est plus important, c'est d'avoir un accès SSH au site avec WP-Cli, ce qui te permet d'interagir avec le site (et ainsi pouvoir créer/modifier/supprimer des comptes).
 
Pour les backup, il est important de l'automatiser (sinon on oublie). Nous avons ainsi :
 - les backups de l'hébergeur (fichiers + BDD)
 - des backups supplémentaires (en fonction des besoins du clients, ça peut être journalier ou mensuel), important : hors-site (on va éviter de faire une OVH où tout grille simultanément)
 
L'idéal est un système qui "pull" la sauvegarde, et non qui la "push" (ex. envoi sur FTP), sinon ça veut dire que ton espace de sauvegarde est configuré et accessible à partir de ton site, ce qui en fait une ouverture potentielle...
 
Et bien-sûr, essayer de temps à autre de restaurer une sauvegarde pour éviter les mauvaises surprises.
 

Bonjour,

Excellente idée de créer un topic WordPress ! C'est une plateforme incontournable pour de nombreux projets web. En cas de problème, je vous recommande aussi de bien vérifier les plugins installés et leur compatibilité avec votre thème. Pensez également à régulièrement mettre à jour WordPress, vos thèmes et vos extensions pour éviter des failles de sécurité.

Pour ceux qui débutent ou souhaitent un accompagnement sur mesure, découvrez notre service de [spam] pour des solutions adaptées à vos besoins.

Hâte de voir les échanges et astuces sur ce topic !

Tu as les signatures pour ça... Au lieu de mettre un SPAM dans ton message.

Création de compte, 1 seul message, ça ressemble à du SPAM.
Astuce N°1, tu as la balise [ url = ] sur le forum pour créer des liens...

+1
 
 

Je crois qu'il s'en fout, il est juste venu poser sa pub et son bl...

 
 
Merci à tous pour vos réponses
 
Pour le backup, j'avais effectivement en tête le cas OVH où de nombreux sites sont tombés et pour certains ne sont jamais remontés...
Effectivement, backup de l'hébergeur + backup complet extérieur. Avez-vous des suggestions de solution type "pull" qui permette l'automatisation ?
 
En ce qui concerne les différents plugins sécurité qui ont été listés, j'ai le dilemme "habituel" entre ajouter des plugins (indispensables?) pour optimiser le site, et avoir "trop" de plugins qui augmentent le risque que le site ne puisse pas traverser les années et les versions Wordpress futures (en gros, l'école du "moins de plugins = moins de problèmes potentiels d'incompatibilités à l'avenir" ).  
Du coup, est-ce que les plugins que vous avez cité (SolidWP, Ninjascanner, Secupress,Wordfence...) sont connus pour être durables et maintenus ?  
On m'a proposé Jetpack aussi, qu'en pendez-vous ?  
 
Quels sont les indispensables selon vous ?    
 
Merci pour vos conseils

Le mieux c'est de prendre des plugins durables effectivement, qui sont déjà bien ancrés dans la communauté et avec des mises à jour régulières. Ça se vérifie assez facilement sur la page du plugin.
 
Perso on utilise :
Elementor pour le page builder.
wpforms pour les formulaires.
Cleantalk pour l'antispam.
Seo Press pour le SEO.
wp mail smtp couplé avec brevo pour les envois de mails.
wprocket pour l'opti/cache.
Complianz pour les cookies.
 
C'est le "core" qui compose la majorité de nos sites et ça fonctionne plutôt bien. Après ça représente un certain coût et je déconseillerai certains si tu restes avec la version gratuite (seo press/wpforms). Pour nous l'avantage c'est qu'on a un paquet de sites et c'est rentabilisé sur le nombre vu qu'on a tout en unlimited.
 
Après y a plein d'autres plugins sympas qu'on teste de temps en temps, mais le but pour nous c'est de tester la compatibilité d'un site et d'être sûr que ça fonctionne pour pouvoir faire un gros update de tout le reste derrière.
 
Jetpack j'éviterais si j'étais toi, il a très mauvaise réputation.