Open-SDF

A propos de nous en video

CECI EST URGENT‼️: Une faille rend VULNÉRABLES QUELQUES MILLIONS de SITS WEB à l'heure actuelle. Dans les faits, cette fameuse vulnérabilité permettrait à un attaquant de prendre le contrôle de l'Administration back-office de votre site sans trop d'effort, et ceci, en exploitant juste un peu un fichier de débogage qui contiendrait des traces de données de cookies et d'authentification. TECHNIQUEMENT, le fichier Debug d'un plugin laisserait fuiter des entêtes HTTP à l'instar de l'entête "Set-Cookie", suite à des demandes de connexion des utilisateurs du site. Et vu que ce fichier de débogage est rarement bien protégé par les dev et admins 🧐 > LES CONCERNÉS : Si vous êtes propriétaire/administrateur/lead developer de sites web (motorisés par WP), sincèrement vous êtes concernés. Vous devez prendre les dispositions nécessaires asap, avant tout drame. Plus principalement, si votre infrastructure d'hébergement utilise le serveur HTTP LiteSpeed, que votre infra soit administrée par vous-même (cas des institutions ou grosse plateformes) ou même qu'elle soit basée sur un simple hébergement mutualisé (acheté chez un hébergeur grand public), je vous prie de bien vouloir vous interesser à celà. En soi, ce n'est pas directement le serveur LiteSpeed qui est le problème: le problème concerne certaines versions du module LiteSpeed Cache, le plugin par exellence de mise en cache des environements WP hébergés sur un serveur LSpeed. Faites rapidement un upgrade à la version 6.5.0.1 si ce n'est encore le cas pour éliminer le risque SVP🙏 AU CAS OÙ, précisons ceci: LiteSpeedCache est un module qui s'occupe de définir et d'appliquer des réglages divers qui "favorisent la performance" des sites web. À l'instar de la mise en cache de certains fichiers, de la compression (automatisée) des images pour alléger le poids des pages, etc. Souvent, les constructeurs de sites web activent des modules et des composants sans vraiment prendre le soin d'évaluer leur nécessité ou encore ce qu'impliquent vraiment tels ou tels parametres. Voici un cas de figure des plus courants : "votre prestataire achète votre hébergement chez un hébergeur mutualisé qui utilise LiteSpeed comme serveur HTTP. Il installe les TOUS les modules SUGGÉRÉS et ne se dérange pas d'évaluer leur nécessité. Après quoi, aucun suivi technique ni de maintenance n'est fait... Nous pensons à tort qu'un projet web est fini à partir du moment où le site est en ligne et accessible au public, alors qu'un projet web ne fini presque jamais si le site web est en cours d'utilisation. Les modules qu'il a installé ne reçoivent pas de mise-à-jour régulierement et vous ne vous plaignez de rien. Or, entre temps, l'hébergeur mutualisé recommandait aussi l'activation de LiteSpeed Cache pour contribuer à la performance du site. Voici qu'une faille a été trouvée par des pirates informatique dans ce module qui n'est pas à jour. La suite, si ce n'est pas un drame, c'est qu'on a régit à temps pour colmater la fissure dans le mur."

POV: Le développement web avec des CMS #opensource, notamment WordPress, peut être beaucoup plus flexible sans l’utilisation de PageBuilders complexes (qu'on ne le pense). Dans mes expériences, j’ai souvent vu des développeurs adopter systématiquement des constructeurs de pages populaires pour créer des mises en page, même pour des éléments simples. Par exemple, j’ai travaillé sur un projet où un simple ajustement CSS était rendu impossible à cause des styles injectés par un builder. Ce phénomène, bien que pratique avec le drag & drop, introduit un coût caché : lourdeur du code, performances dégradées et flexibilité limitée, impactant le #SEO, l’#UX et la #Sécurité. Pourtant, WordPress propose des solutions natives, comme les Blocks et les Hooks, offrant des customisations sans code parasite. On pourra intégrer des fonctions en se greffant sur des natives et personnaliser le comportement des composants pour les utilisateurs de nos sites sans subir un lot de JS dont on n'a pas besoin à chaque fois. Voici 3 raisons pour lesquelles je recommande souvent de privilégier ces fonctions : A) Focus Performance : Les page builders ajoutent une abstraction supplémentaire qui ralentit le chargement. Les Blocks et Hooks, en revanche, s’intègrent nativement, garantissant un site plus rapide et léger. B) Focus Flexibilité : Les Blocks (surtout avec FSE) et les Hooks (grâce à une documentation opensource plus fournie que la Bible) permettent un contrôle total du site, sans les limitations des builders. J’ai souvent vu des développeurs coincés par des classes CSS générées avec des "!important", rendant chaque ajustement frustrant. C) Focus Sécurité : Moins de plugins, c’est moins de failles. De plus, les licences freemium poussent à ajouter des plugins supplémentaires, augmentant les coûts et les risques de dépendance technique. Plus sérieusement, ce facteur alourdi rapidement le cout d’un projet web sur le moyen et long terme, quand ce projet devient à "100% Dépendant de ses PageBuilders”. Pour contourner cette contrainte financière et rester dans les limites du budget, les prestataires ajouteront d’autres plugins supplémentaires qui viendront greffer aussi un N_ième code comme si cela ne suffisait pas, juste pour avoir une substitution d’un composant verrouillé par la licence Free. Le nombre de plugin ne cessera de grimper augmentant les chances d'avoir plus de vulnérabilités dans son site. Privilégier les fonctions natives, c’est choisir un WordPress plus propre, rapide et résilient. Essayez-les, et découvrez la puissance d’un site performant et évolutif ! Si non, avoir un bon score lighthouse sur l'ensemble des pages d'un site ce n'est pas utopique: c'est juste une façon de voir les choses et une rigueur sur les bonnes pratiques.