| Nom du plugin | RevivePress |
|---|---|
| Type de vulnérabilité | Scripts intersites (XSS) |
| Numéro CVE | CVE-2024-13362 |
| Urgence | Moyen |
| Date de publication du CVE | 2026-05-01 |
| URL source | CVE-2024-13362 |
XSS réfléchi non authentifié dans RevivePress (<= 1.5.8) — Ce qu'il faut savoir et que faire maintenant
Une divulgation récente (CVE-2024-13362) rapporte une vulnérabilité de Cross-Site Scripting (XSS) réfléchie affectant le plugin RevivePress (également connu sous le nom de WP Auto Republish / Keep Your Old Content Evergreen plugin) dans les versions jusqu'à et y compris 1.5.8. En tant que professionnels de la sécurité WordPress expérimentés travaillant sur WP-Firewall, nous voulons vous expliquer ce que cela signifie, qui est à risque, comment l'exploitation peut se produire et, surtout, des étapes claires et pratiques que vous pouvez prendre immédiatement — même avant qu'un correctif officiel du fournisseur ne soit disponible.
Cet article est écrit pour les propriétaires de sites, les administrateurs et les développeurs qui souhaitent un résumé clair et actionnable d'un expert en sécurité WordPress humain plutôt qu'un bulletin technique sec.
TL;DR (résumé rapide)
- Une vulnérabilité XSS réfléchie (CVE-2024-13362) affecte les versions de RevivePress <= 1.5.8.
- Le défaut est “réfléchi”, ce qui signifie qu'un attaquant peut créer une URL malveillante qui amène le plugin à afficher du contenu contrôlé par l'attaquant sur une page, exécuté dans le navigateur de l'utilisateur.
- L'exploitation nécessite généralement une interaction de l'utilisateur — un attaquant doit amener un utilisateur privilégié ou un visiteur du site à visiter une URL conçue ou à cliquer sur un lien.
- L'impact peut varier du vol de session et de l'escalade de privilèges (si un administrateur clique) à la manipulation persistante de l'interface utilisateur ou au phishing.
- Aucun correctif officiel n'est peut-être encore disponible pour les versions affectées. Si vous ne pouvez pas mettre à jour, appliquez immédiatement des mesures d'atténuation : désactivez ou supprimez le plugin, appliquez des règles WAF / correctifs virtuels, restreignez l'accès administrateur et surveillez les signes de compromission.
- WP-Firewall peut protéger les sites avec des règles WAF gérées, des correctifs virtuels et une analyse continue des logiciels malveillants. Inscrivez-vous au plan de base gratuit ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Qu'est-ce que le XSS réfléchi et pourquoi est-ce important
Le Cross-Site Scripting (XSS) est une vulnérabilité web courante où une application inclut des données non fiables dans une page web sans validation ou échappement appropriés. Un XSS réfléchi se produit lorsque la charge utile malveillante provient de la requête (par exemple, un paramètre de requête ou une entrée de formulaire) et est “réfléchie” dans la réponse immédiate. Si le contenu réfléchi n'est pas correctement assaini ou encodé, le script malveillant s'exécute dans le contexte du navigateur de la victime.
Pourquoi le XSS réfléchi est dangereux :
- Si un administrateur ou un utilisateur avec des privilèges plus élevés clique sur un lien spécialement conçu, le script de l'attaquant s'exécute avec les privilèges de cet utilisateur dans le navigateur.
- L'attaquant peut voler des cookies d'authentification (jetons de session), effectuer des actions au nom de l'utilisateur (actions de type CSRF), injecter des éléments d'interface utilisateur pour voler des identifiants, et plus encore.
- Même si l'attaquant ne peut pas escalader directement les privilèges, il peut cibler les visiteurs avec des redirections malveillantes, des injections publicitaires ou la collecte d'identifiants.
Le XSS réfléchi est généralement plus facile à exploiter lorsque la cible est une interface administrative ou toute page chargée par des utilisateurs détenant des privilèges élevés.
Résumé technique du problème RevivePress
- Logiciel affecté : RevivePress (plugin) — versions <= 1.5.8.
- Classification de la vulnérabilité : Cross-Site Scripting (XSS) réfléchi.
- CVE : CVE-2024-13362.
- Gravité signalée : score de base CVSS ~6.1 (moyenne). Le score reflète la complexité de l'attaque et l'impact ; l'exploitation nécessite généralement une interaction de l'utilisateur.
- Privilège requis : Non authentifié (ce qui signifie qu'un attaquant non authentifié peut créer le lien d'exploitation ; cependant, des actions malveillantes réussies nécessitent généralement qu'un utilisateur privilégié clique dessus).
Ce qui se passe généralement dans des bugs similaires de plugin XSS réfléchi :
- Le plugin accepte une entrée dans un paramètre de requête ou un champ de formulaire (par exemple, un paramètre utilisé pour les redirections, les aperçus, les messages d'état ou d'autres textes d'interface utilisateur).
- Cette entrée est renvoyée par le plugin dans une page (frontend, page de paramètres ou panneau d'administration) sans un encodage HTML approprié ou une désinfection.
- Un attaquant crée une URL contenant des charges utiles JavaScript et persuade un utilisateur (possiblement un administrateur) de cliquer dessus. Lorsqu'il est cliqué, le script de l'attaquant s'exécute dans le contexte du navigateur de la victime.
Comme le correctif peut ne pas être disponible immédiatement pour tous les sites, des mesures d'atténuation qui bloquent ou désinfectent l'entrée avant qu'elle n'atteigne les utilisateurs victimes sont essentielles.
Qui est à risque ?
- Sites ayant RevivePress installé et version active 1.5.8 ou antérieure.
- Sites où les administrateurs, éditeurs ou autres utilisateurs privilégiés accèdent à des pages qui incluent des sorties de plugin — surtout si ces pages acceptent des paramètres GET, des données de formulaire ou des entrées similaires.
- Sites avec un accès administratif assoupli, comme des identifiants de connexion partagés ou pas d'authentification multi-facteurs (MFA).
- Sites qui n'ont pas de pare-feu d'application Web (WAF) actif ou de protection en temps réel (patches virtuels) en place.
Même les sites Web à faible trafic sont à risque : les attaquants utilisent des analyses automatisées pour trouver des points de terminaison vulnérables et distribuent largement des liens malveillants. Le facteur critique est de savoir si un utilisateur privilégié pourrait cliquer sur un lien conçu.
Scénarios d'attaque réalistes
- Ciblage des administrateurs par e-mail ou ingénierie sociale
L'attaquant crée une URL contenant des charges utiles malveillantes ciblant un paramètre que le plugin reflète.
L'attaquant envoie un e-mail de phishing à un administrateur de site avec un lien qui semble légitime.
L'administrateur clique sur le lien (par exemple, pour vérifier un rapport). Le script injecté s'exécute dans le contexte du navigateur de l'administrateur et peut exfiltrer des cookies ou effectuer des actions administratives. - Page publique ciblant les visiteurs
Si la sortie réfléchie du plugin apparaît sur une page publique, l'attaquant peut l'armement pour livrer des scripts malveillants aux visiteurs, provoquant des redirections ou des popups qui tentent de récolter des identifiants. - Chaîne persistante via des plateformes sociales
L'attaquant publie le lien conçu sur les réseaux sociaux ou des forums publics. Les utilisateurs privilégiés non méfiants qui cliquent peuvent voir leurs sessions compromises.
En résumé : la vulnérabilité est dangereuse lorsque le contenu réfléchi peut être déclenché dans des contextes où des utilisateurs ayant des privilèges plus élevés ou un grand nombre de visiteurs l'exécuteront.
Actions immédiates (que faire dans l'heure qui suit)
Ne paniquez pas — suivez ces étapes rapides pour limiter l'exposition.
- Identifier les sites touchés
Connectez-vous à tous les tableaux de bord WordPress que vous gérez et confirmez si RevivePress (ou WP Auto Republish / Keep Your Old Content Evergreen) est installé et quelle version il s'agit.
Si les versions sont 1.5.8 ou antérieures, considérez le site comme vulnérable jusqu'à preuve du contraire. - Appliquez des mesures d'atténuation à court terme
Si vous pouvez mettre à jour le plugin vers une version corrigée fournie par le développeur, mettez à jour immédiatement. (Si aucun correctif officiel n'est disponible, passez à l'étape suivante.)
Si la mise à jour n'est pas possible ou si aucun correctif n'existe encore :- Désactivez le plugin lorsque cela est pratique.
- Si vous ne pouvez pas le désactiver (le site dépend du plugin), envisagez de le retirer temporairement de l'utilisation publique ou de restreindre l'accès aux pages affectées.
Mettez en œuvre un WAF / un correctif virtuel :
- Si vous exécutez un WAF (niveau serveur ou service), appliquez des règles pour bloquer les chaînes de requête suspectes et les modèles XSS courants — consultez la section d'atténuation ci-dessous pour des exemples de modèles.
Restreindre l'accès admin :
- Accédez aux pages d'administration uniquement depuis des réseaux de confiance lors de l'enquête.
- Appliquez l'authentification multi-facteurs (MFA) pour tous les comptes administratifs.
- Changez les mots de passe administratifs si vous soupçonnez une interaction avec un lien d'attaquant.
Examinez les journaux pour des requêtes suspectes vers les points de terminaison du plugin (GET avec des paramètres de requête étranges, longues chaînes, balises de script).
- Communiquez avec votre équipe.
Informez les administrateurs et les éditeurs de ne pas cliquer sur des liens inconnus liés au site.
Si vous gérez plusieurs sites clients, informez les clients du risque et des mesures d'atténuation que vous avez appliquées.
Détection : comment savoir si quelqu'un a essayé ou réussi
Recherchez les indicateurs suivants dans les journaux et sur le site :
- HTTP access logs that include queries to plugin endpoints with suspicious payloads (e.g., occurrences of “<script>”, “javascript:”, suspicious percent-encoded sequences like %3C%73%63%72%69%70%74).
- Changements inattendus dans le contenu du site, les publications ou les options — les attaquants exploitant des XSS au niveau administrateur peuvent parfois effectuer des actions laissant des traces.
- Nouveaux comptes administrateurs, rôles d'utilisateur modifiés ou réinitialisations de mot de passe que vous n'avez pas initiées.
- Requêtes HTTP sortantes inattendues du site (si un attaquant a téléchargé une porte dérobée).
- Alertes de scanner de sécurité ou résultats de scanner de malware.
Si vous soupçonnez une compromission, effectuez une réponse à l'incident (étapes fournies ci-dessous).
Comment atténuer si vous ne pouvez pas mettre à jour immédiatement
Si un correctif officiel du fournisseur n'est pas disponible ou si la mise à jour casserait la fonctionnalité, vous avez besoin de contrôles compensatoires. Ceux-ci réduisent la surface d'attaque jusqu'à ce qu'un correctif approprié soit disponible.
- Patching virtuel via WAF (recommandé)
Un WAF peut intercepter et neutraliser les tentatives d'exploitation en bloquant les entrées malveillantes avant qu'elles n'atteignent WordPress.
Exemple de logique WAF (niveau élevé uniquement) :- Bloquer les requêtes contenant des balises non encodées dans les chaînes de requête ou les entrées de formulaire.
- Bloquer les requêtes où les paramètres incluent des attributs “onerror=” ou “onload=” intégrés dans des paramètres de redirection ou de texte.
- Limiter ou bloquer les requêtes répétées contenant des charges utiles encodées suspectes.
Remarque : Évitez les règles de blocage trop larges qui pourraient casser des fonctionnalités légitimes. Testez les règles en mode surveillance/enregistrement uniquement d'abord si possible.
- Filtrage des entrées au niveau du serveur web/application
Utilisez des règles au niveau du serveur (par exemple, Nginx, Apache mod_rewrite/mod_security) pour rejeter les requêtes avec des charges utiles suspectes.
Implémentez des en-têtes de Politique de Sécurité de Contenu (CSP) pour réduire l'impact de tout script injecté — par exemple, restreindre les sources de script autorisées. - Limiter l'exposition des pages administratives
Restreindre /wp-admin et les pages administratives liées aux plugins à des adresses IP connues via des listes blanches (si possible).
Ajouter une authentification HTTP (protection par mot de passe) devant l'administration WordPress pour une couche d'authentification supplémentaire.
Activez MFA pour tous les comptes privilégiés. - Suppression/désactivation temporaire du plugin
Si le plugin n'est pas essentiel, désactivez-le ou supprimez-le jusqu'à ce qu'il soit corrigé.
Pour les sites qui dépendent du plugin pour des fonctionnalités critiques, envisagez de remplacer le plugin par une alternative (après une diligence raisonnable) ou de déplacer la fonctionnalité vers une mise en œuvre plus sûre. - Renforcez les comptes utilisateurs
Forcez la réinitialisation du mot de passe pour les comptes administrateur et éditeur si une interaction utilisateur a pu se produire.
Supprimez les comptes inutilisés et limitez le nombre d'utilisateurs ayant des privilèges d'administrateur.
Protections spécifiques à WP-Firewall (comment nos outils aident)
En tant que fournisseur de pare-feu et de sécurité WordPress, notre objectif est d'offrir des protections en couches qui réduisent le besoin de changements manuels d'urgence et fournissent une atténuation immédiate pendant que vous planifiez une solution à long terme.
Fonctionnalités clés que vous pouvez utiliser immédiatement :
- WAF géré avec patching virtuel
Notre équipe peut déployer des règles ciblées qui correspondent aux modèles de réflexion du plugin et bloquer les demandes portant des modèles de charge utile XSS connus, neutralisant efficacement les tentatives d'exploitation en temps réel. - Scanner de malware automatique et surveillance
La détection continue identifie tôt les scripts injectés ou les modifications non autorisées.
Les alertes permettent une réponse rapide et un retour en arrière. - Atténuation des 10 principaux risques OWASP
Nos ensembles de règles par défaut ciblent les vecteurs d'injection courants et les signatures d'attaque, pas seulement ce plugin spécifique. - Liste noire/liste blanche IP et limitation de taux
Restreignez les origines de trafic suspectes et réduisez l'efficacité des analyses automatisées. - Conseils et support en cas d'incident
Nous fournissons des conseils pour la containment, l'investigation et la récupération (si vous avez un plan payant qui inclut le support).
Si vous n'êtes pas déjà protégé, commencez avec notre plan de base gratuit pour ajouter une couche WAF efficace, un scan de malware et une atténuation OWASP pour une couverture immédiate : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Concepts de règles WAF d'exemple (non-exploit, modèles défensifs)
Ci-dessous se trouvent des modèles défensifs non exécutables qui sont couramment utilisés pour atténuer les tentatives de XSS réfléchi. Ceux-ci sont destinés à guider un WAF ou un ingénieur en sécurité dans la création de règles. Ne copiez-collez pas aveuglément en production sans test.
- Bloquez les balises de script non encodées dans les valeurs de requête :
Si la valeur du paramètre de requête contient “<script” ou des équivalents décodés par URL, bloquez ou assainissez. - Bloquer les attributs de gestionnaire d'événements suspects dans les paramètres :
Si le paramètre contient “onerror=”, “onload=”, “onclick=” etc., signalez/bloquez. - Bloquez l'utilisation de l'URI “javascript:” dans les paramètres qui seront reflétés sur les pages :
Si le paramètre inclut des schémas “javascript:”, refusez la requête. - Limitez le taux des requêtes avec des encodages suspects longs et répétés :
Multiple percent-encoded sequences (%3C, %3E) in a single parameter should trigger throttle or block.
Remarques :
– Testez toujours les nouvelles règles en mode surveillance pour mesurer les faux positifs.
– Préférez des règles ciblées qui s'adressent aux points de terminaison spécifiques des plugins ou aux noms de paramètres plutôt qu'à un blocage global agressif.
Réponse à l'incident étape par étape (si vous soupçonnez une exploitation)
Si vous découvrez des indicateurs de compromission ou si vous n'êtes pas certain qu'une exploitation ait eu lieu, suivez ces étapes :
- Isoler et contenir
Bloquez temporairement l'accès au site, ou du moins aux zones administratives, si vous soupçonnez une exploitation en cours.
Mettez en œuvre des règles WAF pour bloquer les charges utiles malveillantes dans les paramètres de requête. - Préserver les preuves
Faites des copies judiciaires des journaux du serveur web, des journaux d'accès et des sauvegardes de base de données.
Enregistrez les horodatages et les lignes de requête qui semblent suspectes. - Analysez et identifiez les changements
Exécutez une analyse complète des malwares et de l'intégrité des fichiers.
Recherchez des thèmes modifiés, des fichiers de plugins ou des fichiers inattendus dans wp-content/uploads. - Validez les comptes utilisateurs et les sessions
Vérifiez la présence de nouveaux comptes administratifs et de changements de rôle inattendus.
Forcer la réinitialisation du mot de passe pour tous les comptes privilégiés et invalider les sessions actives. - Supprimez le contenu malveillant et les portes dérobées
Supprimer les comptes administrateurs non autorisés, les fichiers malveillants et les scripts injectés.
Si vous n'êtes pas sûr de pouvoir nettoyer, envisagez de restaurer à partir d'une sauvegarde propre avant l'incident, puis appliquez des mesures d'atténuation. - Corrigez et renforcez
Mettre à jour les plugins/thèmes vulnérables et le cœur de WordPress.
Appliquer un durcissement à long terme : supprimer les plugins inutilisés, limiter l'accès administrateur, ajouter une MFA et déployer un WAF. - Surveillance post-incident
Surveiller les journaux pour toute indication de tentatives de reconnexion par l'attaquant et pour des entrées suspectes récurrentes. - Informer les parties prenantes
Si des données client/utilisateur ont pu être exposées, suivre les exigences de notification applicables (légal/conformité).
Meilleures pratiques de durcissement pour réduire les risques futurs de XSS
- Principe du moindre privilège
Donner aux utilisateurs uniquement les capacités dont ils ont besoin. Évitez d'utiliser des comptes administrateurs pour des tâches routinières. - Tenez tout à jour
Les mises à jour des plugins, thèmes et du cœur de WordPress incluent des correctifs de sécurité. Planifiez une maintenance régulière. - Utilisez un pare-feu d'application Web géré
Un WAF ajoute une couche de protection empêchant de nombreuses classes d'attaques, y compris le XSS réfléchi. - Appliquez l'authentification multi-facteurs (MFA)
La MFA réduit considérablement le risque lié aux identifiants volés. - Utilisez des pratiques de développement sécurisées.
Les développeurs doivent utiliser des fonctions d'échappement (esc_html(), esc_attr(), wp_kses_post(), etc.) lors de l'affichage des données et toujours assainir les entrées aux points d'entrée. - Implémentez CSP (Content Security Policy)
Un CSP bien configuré peut réduire l'impact du XSS en restreignant les sources de scripts. - Limiter l'exposition des points de terminaison des plugins
Si un plugin expose des points de terminaison frontend qui acceptent des paramètres, envisagez de limiter l'accès ou d'ajouter des vérifications de nonce pour les actions modifiant l'état.
Comment tester votre site en toute sécurité (non destructif)
Si vous êtes responsable d'un site et souhaitez confirmer si la vulnérabilité est présente :
- Configurez un environnement de staging — ne testez jamais des vecteurs d'attaque sur un site de production en direct sans autorisation.
- Sur le staging :
Installez la même version du plugin et reproduisez les conditions où les paramètres sont reflétés sur la page.
Utilisez des outils de test sûrs qui vérifient uniquement la présence de contenu réfléchi non échappé (pas pour la livraison de charges utiles d'exploitation). - Si vous manquez d'expertise, demandez à un professionnel de la sécurité d'effectuer un test sûr et autorisé.
Foire aux questions
Q : Cette vulnérabilité est-elle exploitable sans aucune interaction de l'utilisateur ?
R : En général, le XSS réfléchi nécessite une interaction de l'utilisateur — l'attaquant doit amener un utilisateur (souvent un administrateur) à cliquer sur un lien malveillant ou à visiter une URL conçue. Cependant, une fois déclenché contre un utilisateur privilégié, les conséquences peuvent être graves.
Q : Mon site a le plugin mais je n'utilise pas la page ou le point de terminaison mentionné — dois-je m'inquiéter ?
R : Peut-être. L'entrée réfléchie peut être utilisable via plusieurs points de terminaison de plugin. Si une fonctionnalité renvoie des paramètres dans des pages HTML ou administratives, cela pourrait être un vecteur. En cas de doute, considérez le plugin comme vulnérable jusqu'à ce qu'il ait été corrigé ou atténué.
Q : Un WAF peut-il éliminer complètement le risque ?
R : Un WAF bien entretenu peut réduire considérablement le risque en bloquant les tentatives d'exploitation (patching virtuel). Cependant, les WAF sont une couche d'atténuation — vous devez toujours appliquer le patch du fournisseur une fois disponible et suivre les meilleures pratiques de durcissement.
Q : Si je désactive le plugin, mon site est-il sûr ?
R : Désactiver le plugin supprime le code vulnérable de l'exécution, ce qui est une atténuation pratique à court terme. Assurez-vous que la désactivation ne laisse pas de données ou de fonctionnalités dépendantes qui pourraient causer des problèmes sur le site.
Exemple de liste de contrôle — plan immédiat et sur 7 jours
Immédiat (dans l'heure)
- Identifiez les sites et les versions de plugin affectés.
- Désactivez le plugin ou bloquez l'accès aux points de terminaison vulnérables si possible.
- Appliquez l'authentification multifacteur et les changements de mot de passe pour les administrateurs.
- Ajoutez des règles WAF simples pour bloquer les balises de script et les charges utiles encodées suspectes.
À court terme (dans les 24 à 72 heures)
- Mettez en œuvre des patches virtuels ciblés via votre WAF.
- Restreignez l'accès administrateur par IP ou ajoutez une authentification HTTP basique.
- Scannez les fichiers et les journaux du site pour détecter des activités suspectes.
- Communiquez le risque aux administrateurs et aux parties prenantes.
Moyen terme (dans les 7 jours)
- Mettez à jour le plugin vers une version corrigée si disponible.
- Passez en revue les rôles des utilisateurs et supprimez les comptes administratifs inutilisés.
- Mettez en œuvre CSP et d'autres mesures de durcissement à long terme.
- Envisagez un audit de sécurité pour examiner la posture globale.
Liste de contrôle de récupération d'incidents (si compromission confirmée)
- Restaurer à partir d'une sauvegarde propre vérifiée si nécessaire.
- Faites tourner les identifiants (mots de passe administratifs, clés API, jetons OAuth).
- Réinstaller le cœur de WordPress et les plugins à partir de sources fiables.
- Re-scanner l'environnement après restauration pour garantir un état propre.
- Mettre en œuvre une surveillance continue et des scans programmés.
Réflexions finales de l'équipe de sécurité de WP-Firewall
Les vulnérabilités XSS réfléchies comme CVE-2024-13362 nous rappellent que même des plugins apparemment petits peuvent ouvrir des voies dangereuses vers les sites web. L'attaque est simple à réaliser si un attaquant peut persuader un utilisateur privilégié de cliquer sur un lien — ce qui est le vecteur principal d'ingénierie sociale derrière de nombreuses intrusions réussies.
La bonne défense est en couches :
- retirez ou corrigez le code vulnérable lorsque cela est possible,
- ajoutez des contrôles compensatoires comme le patching virtuel et les règles WAF,
- appliquez des pratiques de durcissement des comptes (MFA, moindre privilège),
- et maintenez un scan continu pour repérer rapidement les attaques.
Si vous gérez plusieurs sites WordPress ou des sites clients, priorisez les ressources pour les sites avec des utilisateurs à privilèges élevés et un contenu ou des données précieux. Des étapes rapides et pratiques prises maintenant peuvent empêcher une petite vulnérabilité de se transformer en un long exercice de récupération coûteux.
Protégez votre site aujourd'hui avec une couche de sécurité essentielle
Sécurisez aujourd'hui, dormez plus facilement demain
Si vous souhaitez une protection immédiate pendant que vous évaluez ou appliquez des correctifs de fournisseur, notre plan WP-Firewall Basic (Gratuit) offre des capacités essentielles de pare-feu géré, une bande passante illimitée, une protection WAF, un scan de malware et une atténuation des risques OWASP Top 10 — le tout sans frais. C'est un moyen rapide d'ajouter une couche défensive éprouvée à tout site WordPress.
Commencez à protéger votre site maintenant : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Si vous avez besoin de fonctionnalités plus avancées comme la suppression automatique de malware, les contrôles IP, le patching virtuel ou un support dédié, envisagez nos plans Standard ou Pro.)
Ressources et lectures complémentaires
- CVE-2024-13362 (nom de référence pour ce problème)
- Guides de durcissement officiels de WordPress (Principes de base pour sécuriser un site WordPress)
- Fiche de triche OWASP pour la prévention des XSS (orientations générales pour l'atténuation des XSS)
- Pages de produit WP-Firewall (pour les fonctionnalités détaillées du plan et l'intégration)
Si vous le souhaitez, notre équipe peut :
- Vérifiez votre site pour des indicateurs de cette vulnérabilité spécifique,
- Appliquez des correctifs virtuels via notre WAF géré,
- Vous guider dans la récupération si vous soupçonnez un incident.
Contactez notre équipe des opérations de sécurité via le tableau de bord WP-Firewall après vous être inscrit avec le plan gratuit ou contactez votre spécialiste de compte si vous êtes sur un plan payant. Nous sommes là pour vous aider à sécuriser WordPress rapidement et avec un minimum de perturbations.
