Security Pilot

Security Pilot est un plugin de sécurité WordPress complet qui durcit votre site contre les attaques et vulnérabilités courantes. Il applique les en-têtes HTTP de sécurité standards de l’industrie, protège la page de connexion contre les attaques par force brute, bloque les requêtes malveillantes avec un pare-feu intégré, restreint les endpoints sensibles de l’API REST et embarque un audit en un clic qui note l’installation de A à F.

À l’inverse des suites de sécurité gonflées, Security Pilot est léger et modulaire : n’activez que les protections dont vous avez besoin. Chaque module peut être basculé indépendamment, et tous les réglages sont gérés depuis le menu de premier niveau Security Pilot dans la barre latérale d’administration WordPress.

Points forts

• En-têtes HTTP de sécurité — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection et suppression de l’en-tête X-Powered-By.
• Protection du login — limitation de débit configurable, verrouillages temporaires et bans permanents pour les récidivistes, avec alertes e-mail optionnelles.
• Pare-feu applicatif — détection par motifs des injections SQL, du cross-site scripting (XSS), du path traversal, du remote file inclusion (RFI) et de l’injection de commandes.
• Protection de l’API REST — bloque les accès non autorisés à des groupes d’endpoints sensibles comme /wp/v2/users, WooCommerce, Jetpack, wp-site-health, Divi Builder et Elementor.
• Durcissement WordPress — désactive l’éditeur de fichiers et XML-RPC, supprime pingbacks et trackbacks, masque la version de WordPress, retire le lien RSD et le manifeste Windows Live Writer.
• Limiteur de débit — limitation par IP des floods de 404 et autres schémas de requêtes à haute fréquence, avec compteur max-block et fenêtre temporelle glissante configurables.
• Protection des formulaires — limite les soumissions front, bloque les domaines d’e-mail jetables et piège les bots avec des champs honeypot cachés et un contrôle configurable du temps minimum de remplissage.
• Security Check — audit en un clic qui note l’installation de A à F et rapporte le statut par vérification (PASS / WARNING / FAIL) sur le durcissement, l’exposition de l’API REST, les plugins/thèmes obsolètes, les réglages de debug, l’éditeur de fichiers et bien d’autres.
• Règles d’accès et journalisation des attaques — gérez les IPs bloquées, les IPs en liste blanche et les URLs en liste blanche depuis un écran à trois onglets, et plongez dans chaque requête bloquée via le Journal d’attaques.

Prérequis

Security Pilot est conçu pour les sites WordPress modernes auto-hébergés.

• Une installation WordPress fonctionnelle avec un accès administrateur.
• Une version de PHP prise en charge par votre release WordPress courante.
• HTTPS est fortement recommandé. L’en-tête HSTS ne devrait être activé que lorsque votre site est joignable en TLS sur chaque URL, sous-domaines inclus que vous souhaitez couvrir.
• Une permission suffisante pour modifier les en-têtes de réponse HTTP. Sur la plupart des hébergements managés cela fonctionne d’emblée ; devant certains reverse proxies ou CDN, il peut être nécessaire d’autoriser les en-têtes au niveau de l’edge.

Aucun service externe à configurer et aucune clé d’API n’est requise. Les réglages, journaux et listes de blocage sont stockés dans votre propre base de données WordPress.

Installation

1. Téléchargez le ZIP du plugin Security Pilot.
2. Dans WordPress, ouvrez Extensions → Ajouter → Téléverser une extension.
3. Choisissez le fichier ZIP et cliquez sur Installer maintenant.
4. Cliquez sur Activer une fois le téléversement terminé.
5. Ouvrez Security Pilot → Réglages pour passer en revue les modules. Les quatre éléments du sous-menu, dans l’ordre, sont Security Check, Règles d’accès, Journal d’attaques et Réglages.

Après l’activation, aucune protection n’est forcée — chaque module démarre dans un état connu et peut être basculé individuellement. Vous pouvez donc installer le plugin en toute sécurité sur un site en production et introduire le durcissement par petites étapes réversibles.

Configuration

Toute la configuration se fait depuis Security Pilot → Réglages. La page regroupe les réglages par module — chaque module est une carte pliable avec son propre interrupteur et un petit nombre d’options.

Une carte Licence en haut accepte une clé PILOT-XXXX-XXXX-XXXX-XXXX (issue de votre confirmation de commande) et active les mises à jour automatiques du plugin via le flux des releases GitHub lorsqu’elle est vérifiée. Le plugin fonctionne entièrement sans clé ; seul le canal d’auto-update est conditionné.

En-têtes HTTP de sécurité

Le module d’en-têtes ajoute à chaque requête servie par WordPress des en-têtes HTTP de réponse standards. Activez ou désactivez chaque en-tête selon les besoins de votre site.

Quelques points à connaître lors de la configuration des en-têtes :

• HSTS est permanent dans les navigateurs une fois reçu. Vérifiez que HTTPS fonctionne partout — y compris sur www et sur tout sous-domaine que vous prévoyez d’inclure — avant de l’activer.
• La Content-Security-Policy est l’en-tête le plus puissant et le plus intrusif. Démarrez avec les valeurs par défaut tolérantes, puis resserrez la politique après avoir vérifié dans la console du navigateur les ressources bloquées sur vos vraies pages.
• Si votre site est derrière un CDN ou un reverse proxy qui réécrit les en-têtes, assurez-vous que ces edges laissent passer telles quelles les valeurs ajoutées par Security Pilot.

Protection du login

La Protection du login compte les tentatives d’authentification échouées par adresse IP et applique un verrouillage lorsque le seuil est atteint. Après un nombre configurable de verrouillages, l’IP peut être bannie de façon permanente.

Réglages disponibles :

• Tentatives échouées maximum — nombre de connexions ratées depuis une IP avant de déclencher un verrouillage. Valeurs acceptées : 1 à 20. La valeur par défaut 5 est un point de départ raisonnable.
• Fenêtre de tentatives — fenêtre temporelle glissante, en minutes, utilisée pour compter les échecs. Valeurs acceptées : 1 à 120.
• Durée du verrouillage — durée pendant laquelle une IP verrouillée reste bloquée, en minutes. Valeurs acceptées : 1 à 1440 (24 heures).
• Seuil de ban permanent — nombre de verrouillages distincts qu’une IP peut accumuler avant d’être bannie de façon permanente. Valeurs acceptées : 1 à 20.
• Alertes e-mail — lorsqu’elles sont activées, l’administrateur du site reçoit un e-mail à chaque détection d’attaque et à chaque ajout d’IP à la liste de blocage.
• Masquer les messages d’erreur détaillés — des messages génériques (« identifiants invalides ») remplacent les messages par défaut de WordPress, pour empêcher les attaquants d’apprendre l’existence d’un nom d’utilisateur.

La protection s’applique aussi bien à wp-login.php qu’à l’endpoint d’authentification XML-RPC standard lorsque XML-RPC reste activé.

Pare-feu applicatif

Le Pare-feu applicatif inspecte les requêtes entrantes à la recherche de motifs malveillants et renvoie une réponse 403 Forbidden lorsqu’il en trouve un. Les motifs de détection sont intégrés et couvrent :

• Injection SQL — payloads courants contre les paramètres de requête, les corps POST et les cookies.
• Cross-site scripting (XSS) — signatures d’attaque réfléchies et stockées.
• Path traversal — tentatives de type ../ pour sortir de la racine du document.
• Remote file inclusion (RFI) — références à des URLs externes dans des contextes où des chemins locaux sont attendus.
• Injection de commandes — métacaractères shell dans des paramètres susceptibles d’atteindre des fonctions de type system.

Le pare-feu n’a pas de configuration règle par règle. Il est soit activé, soit désactivé. Les requêtes bloquées sont enregistrées dans le journal d’attaques décrit plus bas, avec le paramètre fautif et la règle qui a déclenché le blocage.

Limiteur de débit (protection contre les floods de 404)

Les sites en cours de probing brute-force enchaînent des centaines de réponses 404 par IP et par minute, à la recherche d’assets de plugins cachés ou de sauvegardes de wp-config. Le Limiteur de débit plafonne ce trafic par IP source en suivant les hits 404 sur une fenêtre glissante :

Le blocage est appliqué par le même mécanisme que la Protection du login, il apparaît donc dans l’onglet Règles d’accès → IPs bloquées avec la raison 404_flood.

Protection de l’API REST

WordPress expose par défaut une API REST étendue, dont des endpoints utiles aux page builders mais souvent superflus sur un site en production. Security Pilot peut bloquer l’accès non authentifié à des groupes entiers d’endpoints tout en laissant le reste de l’API intact.

Groupes protégés :

• /wp/v2/users — énumération d’utilisateurs via l’endpoint utilisateurs du cœur.
• WooCommerce — endpoints boutique, commandes et clients exposés par WooCommerce lorsqu’il est installé.
• Jetpack — namespace REST propre à Jetpack.
• wp-site-health — endpoints de health-check qui peuvent fuiter des informations sur l’environnement.
• Divi Builder — endpoints REST de Divi.
• Elementor — endpoints REST d’Elementor.

N’activez la protection que pour les groupes dont vous n’avez pas besoin. Par exemple, un site qui ne fait pas tourner WooCommerce peut verrouiller sans risque les endpoints WooCommerce. Le plugin vérifie l’authentification sur chaque requête et renvoie une erreur d’autorisation aux appelants non authentifiés qui tentent d’accéder à un groupe protégé.

Protection des formulaires

Protège les formulaires de contact / commentaires / login du site contre le spam, les inscriptions avec e-mails jetables et les soumissions de bots à haute vélocité :

Des pièges honeypot (champs cachés que seuls les bots remplissent) et un contrôle du temps minimum de remplissage tournent en parallèle des barrières de débit. Les tentatives bloquées sont consignées dans le Journal d’attaques.

Durcissement WordPress

Le module de durcissement coupe des fonctionnalités WordPress fréquemment abusées ou qui révèlent des informations utiles à la préparation d’un exploit. Chaque option est indépendante.

• Désactiver l’éditeur de fichiers — coupe l’éditeur de fichiers de thèmes et de plugins intégré au dashboard (DISALLOW_FILE_EDIT). Un attaquant qui parvient à obtenir des identifiants admin ne peut plus modifier de code directement depuis l’interface WordPress.
• Désactiver XML-RPC — bloque l’endpoint xmlrpc.php, cible courante des attaques brute-force et d’amplification. Ne désactivez XML-RPC que si aucune intégration de votre site n’en dépend.
• Désactiver pingbacks et trackbacks — ferme un vecteur d’amplification de longue date, utilisé dans des campagnes DDoS.
• Masquer la version de WordPress — retire la balise meta generator et les paramètres de version sur les assets enqueued, pour que la version installée ne soit pas exposée dans le source de la page.
• Retirer le lien RSD — supprime le lien Really Simple Discovery utilisé par les clients de publication externes.
• Retirer le manifeste WLW — retire le lien du manifeste Windows Live Writer, rarement utile aujourd’hui.

Pour la plupart des sites en production, il est sans risque d’activer toutes les options de durcissement. Désactiver l’éditeur de fichiers et XML-RPC, en particulier, est considéré comme une recommandation de base par la communauté de sécurité WordPress.

Security Check

La page Security Check — Security Pilot → Security Check — lance un audit en un clic et produit une note littérale de A (« excellent, votre sécurité est solide ») à F, accompagnée de compteurs KPI pour le total des passées, échouées, avertissements et vérifications totales.

Le Check couvre chaque catégorie que le plugin peut vérifier depuis WordPress, dont (mais pas seulement) :

• HTTPS configuré sur l’URL du site.
• Éditeur de fichiers désactivé (DISALLOW_FILE_EDIT).
• XML-RPC désactivé.
• Journal et affichage de debug coupés en production.
• Accès à wp-config.php bloqué au niveau du serveur web.
• Cœur WordPress, plugins et thèmes à jour.
• Plugins inactifs encore installés (surface d’attaque).
• Nom d’utilisateur admin par défaut absent.
• Protection de l’API REST activée.
• En-têtes HTTP de sécurité, protection du login et pare-feu applicatif actifs.
• Préfixe DB robuste, exposition PHP, signature serveur.

Chaque ligne affiche un titre court, une description en une phrase et un badge de statut (PASS, WARNING, FAIL, INFO). Le module Réglages → Security Check expose trois interrupteurs en opt-in qui ajoutent des vérifications plus profondes (plugins obsolètes, thèmes obsolètes, lookup de vulnérabilités plugins face à un flux public) — ces vérifications tournent au moment de la demande et la ralentissent de quelques secondes, elles sont donc désactivées par défaut. Depuis le rapport lui-même, les correctifs sont en général à un clic dans l’admin WordPress (mettre à jour un plugin, supprimer un plugin inactif, modifier un interrupteur de durcissement).

Utilisation

Une première passe pratique dans le plugin ressemble à ceci.

1. Installez et activez Security Pilot.
2. Ouvrez Security Pilot → Réglages.
3. Activez les en-têtes HTTP de sécurité avec les valeurs recommandées par défaut. Visitez quelques pages de votre site et regardez la console du navigateur à la recherche de violations de Content-Security-Policy inattendues.
4. Activez la Protection du login. Laissez Tentatives échouées maximum à 5, choisissez une fenêtre de 15 minutes et un verrouillage de 60 minutes pour un site typique. Activez les alertes e-mail pour être averti quand le site est attaqué.
5. Activez le Pare-feu applicatif. Aucune configuration supplémentaire n’est nécessaire.
6. Activez le Limiteur de débit pour attraper les floods de 404 (par défaut 25 hits en 60 secondes → IP ajoutée à la liste de blocage).
7. Basculez la Protection de l’API REST pour les groupes d’endpoints que votre site n’utilise pas publiquement. Le groupe /wp/v2/users peut presque toujours être verrouillé sans risque.
8. Activez la Protection des formulaires sur les sites avec formulaires de contact / commentaires — choisissez un cooldown par IP raisonnable et une blocklist de TLDs.
9. Activez les options de Durcissement WordPress. Au minimum, désactivez l’éditeur de fichiers et XML-RPC sur les sites en production.
10. Lancez un Security Check et agissez sur chaque ligne WARNING et FAIL (mettez à jour ou supprimez les plugins et thèmes listés, basculez les interrupteurs de durcissement signalés).

Après cette première passe, revenez périodiquement sur Security Pilot → Security Check pour maintenir la note au-dessus de C, et sur Journal d’attaques + Règles d’accès pour passer en revue ce qui a été attrapé.

Examiner les règles d’accès

L’écran Règles d’accès (Security Pilot → Règles d’accès) est un panneau de contrôle centralisé à trois onglets pour les blocklists et whitelists par IP et par URL :

• IPs bloquées — chaque adresse actuellement bloquée par la Protection du login, le Limiteur de débit ou le pare-feu. Chaque ligne affiche l’IP, le motif de blocage (par exemple firewall:path_traversal, 404_flood, firewall:sqli), la date d’ajout et un bouton Débloquer. Un formulaire simple en haut permet de bloquer manuellement une IP arbitraire avec un motif optionnel, et un champ de recherche filtre par IP ou par motif.
• IPs en liste blanche — adresses exemptées de toutes les vérifications (bureau, service de supervision, serveur de staging, votre IP personnelle).
• URLs en liste blanche — chemins exemptés du Limiteur de 404 (utile lorsqu’un endpoint légitime renvoie légitimement des 404 par bouffées).

Utilisez cet écran pour :

• Débloquer une adresse piégée par un utilisateur légitime qui s’est trompé de mot de passe.
• Mettre en liste blanche une IP de confiance connue (votre bureau, service de supervision, serveur de staging) pour qu’elle ne puisse pas être verrouillée par accident.
• Mettre en liste blanche une URL qui atteint la limite de 404 par design (par exemple un chemin de sonde consommé par une supervision externe).

Examiner le journal d’attaques

Le Journal d’attaques (Security Pilot → Journal d’attaques) enregistre chaque requête bloquée, dont les verrouillages brute-force, les hits du pare-feu, les déclenchements du limiteur de débit, les rejets de spam de formulaires et les refus de l’API REST. Chaque ligne porte l’horodatage, l’IP source, le Type d’attaque (par exemple RESTRICTION, REQUEST_URI, PATH_TRAVERSAL, COMMAND_INJECTION, POST_X), le Rule listener qui a émis le blocage et le Request URI qui l’a déclenché. Une action groupée Vider le journal efface la page et la barre d’outils expose une recherche libre ainsi que des filtres par IP et par listener.

Le journal est utile à la fois pour la revue post-incident et pour ajuster le pare-feu : si une requête légitime apparaît dans le journal, vous pouvez identifier la règle responsable et décider de mettre la requête en liste blanche, l’IP, ou d’affiner la règle.

Widget du tableau de bord WordPress

Security Pilot ajoute un widget à l’écran Tableau de bord standard (la page que WordPress ouvre à la connexion) pour que les chiffres essentiels soient visibles dès l’authentification.

Le widget affiche :

• La dernière note Security Check (A–F) et le score numérique (par exemple A 95/100), rendus sous forme d’anneau coloré.
• Un compteur IPs bloquées live alimenté par la table des Règles d’accès.
• Un compteur Attaques en continu alimenté par le Journal d’attaques.
• La liste Attaques récentes — cinq dernières lignes du Journal d’attaques avec badge de type, IP source et horodatage.
• Des raccourcis en pied vers Journal d’attaques et Rapport de sécurité complet.

FAQ

Security Pilot remplace-t-il les autres plugins de sécurité ?

Pour la plupart des sites, oui. Security Pilot couvre les en-têtes HTTP, la protection du login, le filtrage des requêtes, les restrictions de l’API REST, le durcissement et l’audit. Il est volontairement léger plutôt qu’une suite « couteau suisse ». Le faire tourner aux côtés d’un autre pare-feu ou plugin de protection du login est techniquement possible mais rarement utile et peut entraîner le déclenchement de règles en doublon.

Les en-têtes peuvent-ils casser mon site ?

Les valeurs par défaut sont conservatrices. Les deux en-têtes qui demandent le plus d’attention sont HSTS et Content-Security-Policy.

• N’activez HSTS qu’après que votre site est entièrement joignable en HTTPS, sous-domaines inclus que vous voulez couvrir. L’en-tête est mis en cache par les navigateurs et ne peut pas être facilement révoqué.
• Ajustez la Content-Security-Policy après avoir surveillé la console du navigateur à la recherche de ressources bloquées sur de vraies pages. Les scripts personnalisés, polices et analytics doivent souvent être ajoutés à la politique.

Le pare-feu applicatif va-t-il bloquer du trafic légitime ?

Les motifs de détection ciblent des signatures d’attaque connues et tendent à être spécifiques. Si une requête légitime est bloquée, elle apparaît dans le journal d’attaques avec la règle qui a déclenché le blocage. Vous pouvez alors débloquer l’IP et, si le motif est réellement inévitable, documenter l’exception pour votre équipe.

Le plugin fonctionne-t-il derrière un CDN ou un reverse proxy ?

Oui. Le plugin lit l’adresse IP d’origine depuis les en-têtes de requête standards et peut identifier correctement les visiteurs derrière un CDN, à condition que votre environnement d’hébergement transmette correctement l’en-tête X-Forwarded-For ou équivalent. Assurez-vous qu’aucune couche edge devant WordPress ne supprime les en-têtes de réponse ajoutés par Security Pilot.

Puis-je exporter les journaux d’attaques ou les listes d’IPs bloquées ?

Le journal d’attaques et la table des IPs bloquées sont stockés dans votre base WordPress et peuvent être consultés directement depuis l’interface d’administration. Pour un archivage long terme ou une analyse off-site, prenez une sauvegarde de base de données comme pour n’importe quelle autre donnée WordPress.

Désactiver XML-RPC casse-t-il quelque chose ?

XML-RPC est utilisé par l’ancien client Windows Live Writer, par les applications mobiles WordPress dans certaines configurations et par un petit nombre d’intégrations tierces. Si vous n’utilisez aucun de ces cas, désactiver XML-RPC est l’une des étapes de durcissement en un clic les plus efficaces que vous puissiez faire.

Les réglages sont-ils conservés à la désactivation du plugin ?

Oui. Désactiver Security Pilot conserve votre configuration, le journal d’attaques et la liste de blocage en base de données, pour que réactiver le plugin restaure l’état précédent.

Dépannage

Un utilisateur légitime est verrouillé

Ouvrez IPs bloquées, repérez l’entrée pour l’adresse concernée et supprimez le blocage. Si le même utilisateur est verrouillé à répétition, envisagez de :

• Augmenter les Tentatives échouées maximum pour les utilisateurs étourdis.
• Ajouter l’IP de l’utilisateur (ou l’IP NAT du bureau) à la liste blanche.
• Demander à l’utilisateur de réinitialiser son mot de passe plutôt que de le deviner.

Le navigateur bloque des ressources après l’activation de la CSP

La Content-Security-Policy est volontairement stricte par défaut. Ouvrez les outils de développement du navigateur et regardez l’onglet Console — le navigateur signalera chaque ressource bloquée avec la directive qui l’a rejetée. Ajustez la CSP pour inclure les origines de confiance (CDN, fournisseur d’analytics, hôte de polices) dont votre site dépend.

Les pages continuent de charger en HTTP après l’activation de HSTS

HSTS n’est honoré qu’après que le navigateur a vu l’en-tête au moins une fois en HTTPS. Visitez le site directement en https:// pour amorcer le cache. Si le site n’est pas encore joignable en HTTPS sur chaque URL que vous publiez, désactivez HSTS jusqu’à la fin de la migration.

Les intégrations API REST cessent de fonctionner

Si une intégration qui s’appuie sur un groupe d’endpoints protégé cesse de fonctionner, désactivez temporairement la protection pour ce groupe sous Protection de l’API REST et confirmez que l’intégration s’authentifie correctement. Beaucoup d’intégrations s’attendent à être appelées comme un utilisateur WordPress authentifié ; les requêtes authentifiées ne sont pas bloquées par ce module.

Les en-têtes ne sont pas présents dans la réponse

Certains hébergeurs ou reverse proxies suppriment ou écrasent les en-têtes de réponse ajoutés par PHP. Vérifiez les en-têtes avec un outil comme curl -I https://example.com/ ou l’inspecteur réseau de votre navigateur. Si un en-tête manque, consultez la documentation de l’hébergeur pour autoriser les en-têtes personnalisés à passer, ou ajoutez l’en-tête au niveau de l’edge si l’hébergeur l’exige.

Les alertes e-mail n’arrivent pas

Les alertes e-mail utilisent la fonction wp_mail() de WordPress. Si aucun e-mail n’arrive, le problème vient presque toujours de la configuration mail du site et non de Security Pilot. Installez un plugin de mail transactionnel (par exemple un plugin qui route les e-mails WordPress via SMTP) et retestez en déclenchant un verrouillage depuis un navigateur de test.