Foire aux questions (FAQ)

Retrouvez ici les réponses aux questions les plus fréquemment posées sur Samaritain Security.

[rank_math_breadcrumb]

Installation et licence

Comment fonctionne la licence ? Que se passe-t-il à expiration ?

Samaritain Security nécessite une licence valide pour fonctionner. La licence est vérifiée périodiquement auprès du serveur de licence.

Licence active : L’extension fonctionne normalement avec toutes les fonctionnalités
Serveur injoignable : Une période de grâce de 7 jours s’active automatiquement. L’extension continue de fonctionner et un avertissement s’affiche dans l’administration
Licence expirée : L’extension cesse de fonctionner. Un message vous invite à renouveler votre licence

Pour renouveler ou acheter une licence, rendez-vous sur samaritain-security.com.

Puis-je utiliser Samaritain Security avec d’autres plugins de sécurité ?

C’est fortement déconseillé. Utiliser plusieurs extensions de sécurité en même temps peut provoquer des conflits (double filtrage du pare-feu, doubles notifications, problèmes de performance). Samaritain Security détecte automatiquement les plugins conflictuels et affiche un avertissement.

Si vous migrez depuis un autre plugin de sécurité, désactivez-le avant d’activer Samaritain Security.

Accès et connexion

J’ai perdu mon URL de connexion personnalisée, comment faire ?

Si vous avez activé la fonctionnalité « Masquer la page de connexion » et oublié l’URL :

Via l’URL de secours (recommandé) : Utilisez l’URL de secours affichée sur la page Samaritain > Licence de votre administration. Elle a la forme votre-site.com/?samaritain_rescue=VOTRE_CLE. Cette URL débloque votre IP et bypasse temporairement la protection pendant 15 minutes, le temps de vous reconnecter.
Via la base de données : Connectez-vous à phpMyAdmin depuis le panel de votre hébergeur. Dans la table wp_options, recherchez samaritain_security_settings. Dans la valeur JSON, cherchez "hide_login" et changez "enabled":true en "enabled":false. Vous pourrez ensuite accéder à wp-login.php normalement.
Via FTP/SFTP : Renommez le dossier du plugin wpsam-security (par exemple en wpsam-security-disabled). L’extension sera désactivée et vous retrouverez l’accès via wp-login.php. Renommez ensuite le dossier pour réactiver l’extension.

💡 Conseil : Notez toujours votre URL de secours et votre URL de connexion dans un endroit sûr (gestionnaire de mots de passe, note sécurisée).

Mon adresse IP a été bloquée, que faire ?

Plusieurs solutions :

URL de secours (recommandé) : Utilisez votre URL de secours (votre-site.com/?samaritain_rescue=VOTRE_CLE). Elle débloque automatiquement votre IP et vous donne 15 minutes pour vous reconnecter. Vous la trouverez sur la page Samaritain > Licence
Attendre : Si le blocage est temporaire (verrouillage), il expire après la durée configurée (15 minutes par défaut)
Changer d’IP : Connectez-vous depuis votre réseau mobile ou un VPN, puis débloquez votre IP depuis la page de gestion des IP
Base de données : Via phpMyAdmin, cherchez votre IP dans la table de logs de l’extension et supprimez-la de la liste de blocage

Pour éviter ce problème à l’avenir, ajoutez votre adresse IP à la liste blanche.

Pare-feu

Le pare-feu bloque un service ou un plugin légitime

Consultez le journal d’audit dans le tableau de bord pour identifier le type de blocage et l’adresse IP concernée
Ajoutez l’adresse IP du service dans la liste blanche du pare-feu (Réglages > Pare-feu > IPs en liste blanche)
Si le problème persiste, passez temporairement le pare-feu en mode « Journaliser uniquement » pour identifier le filtre responsable (Query Strings, URI, User Agents, etc.)
Une fois le filtre identifié, vous pouvez le désactiver individuellement si nécessaire

💡 Conseil : Le mode « Journaliser uniquement » vous permet de voir les requêtes qui seraient bloquées sans les bloquer réellement. C’est l’outil idéal pour diagnostiquer les faux positifs.

Protection API

Un plugin ne fonctionne plus après l’activation de la protection REST API

Certains plugins WordPress nécessitent l’accès public à l’API REST pour fonctionner. Si un plugin ne fonctionne plus après activation de la protection :

Désactivez temporairement la protection REST API pour confirmer que c’est bien la cause
Si le problème disparaît, vous avez deux options :
- Laisser la protection REST API désactivée
- Demander à votre développeur d’ajouter une exception via le filtre WordPress samaritain_security_rest_allowed_endpoints

Les plugins les plus courants (WooCommerce, Contact Form 7, Elementor) fonctionnent généralement sans problème car ils utilisent l’API REST en mode connecté.

Score de sécurité

Mon score n’est pas à 100 %, est-ce grave ?

Pas nécessairement. Un score de 90+ (note A) est excellent. Les points manquants correspondent souvent à :

Fonctionnalités volontairement désactivées : Le blocage de création d’administrateur et le forçage HTTPS ne sont pas activés par défaut pour de bonnes raisons
Vérifications système : Le préfixe de base de données wp_ est signalé mais le changer nécessite de la prudence
HSTS non activé : Nécessite d’être certain que le SSL est permanent

Consultez la section Points à améliorer du tableau de bord pour voir exactement quels éléments contribuent à la baisse du score et décider si les activer est pertinent pour votre cas.

Le mode debug est signalé comme problème, que faire ?

Rien à faire : Samaritain Security s’en occupe automatiquement. La fonctionnalité Protection mode debug (activée par défaut) modifie directement votre fichier wp-config.php pour désactiver WP_DEBUG, WP_DEBUG_DISPLAY, SCRIPT_DEBUG et ajouter @ini_set('display_errors', 0). Une sauvegarde automatique (wp-config.php.samaritain-backup) est créée avant toute modification.

Si vous voyez encore un avertissement après l’activation, c’est généralement parce que le fichier wp-config.php n’est pas accessible en écriture par le serveur web. Dans ce cas, l’extension affiche une notice dans l’administration pour vous prévenir.

Solutions possibles :

Vérifiez les permissions du fichier : Demandez à votre hébergeur de s’assurer que wp-config.php a des permissions permettant l’écriture par PHP (généralement 644 avec le bon propriétaire).
Contactez votre hébergeur : Demandez-lui simplement de « désactiver le mode debug WordPress » — toute personne du support technique saura le faire en quelques secondes.
Modification manuelle (en dernier recours, si vous êtes à l’aise avec l’édition de fichiers) : Ouvrez wp-config.php via FTP ou le gestionnaire de fichiers de votre hébergeur, cherchez les lignes contenant WP_DEBUG et modifiez-les :

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SCRIPT_DEBUG', false );

💡 Conseil : Si vous voulez conserver la journalisation des erreurs (dans wp-content/debug.log) sans les afficher publiquement, activez l’option « Autoriser WP_DEBUG_LOG » dans les réglages avancés de la Protection mode debug. L’extension configurera automatiquement wp-config.php en conséquence.

Le mode debug ne doit jamais être activé en production car il peut afficher des informations sensibles (chemins de fichiers, requêtes SQL, variables) aux visiteurs.

Le préfixe de table `wp_` est signalé, comment le changer ?

Le préfixe de table par défaut wp_ est connu de tous les attaquants. Le changer rend certaines attaques par injection SQL plus difficiles.

⚠️ Avertissement : Changer le préfixe de table sur un site existant est une opération sensible qui nécessite une sauvegarde complète de la base de données. Nous recommandons de le faire uniquement lors de l’installation initiale de WordPress ou avec l’aide d’un professionnel.

Headers de sécurité

J’ai activé HSTS, comment revenir en arrière ?

HSTS est mémorisé par le navigateur du visiteur. Après désactivation dans les réglages :

Pour vous-même : Videz le cache HSTS de votre navigateur (dans Chrome : chrome://net-internals/#hsts, supprimez votre domaine)
Pour les visiteurs : Ils devront attendre l’expiration de la directive HSTS (jusqu’à 1 an) ou vider eux-mêmes leur cache
Si HSTS Preload était activé : Vous devez demander le retrait de votre domaine sur hstspreload.org. Le processus peut prendre plusieurs mois

C’est pourquoi nous recommandons d’activer HSTS uniquement si vous êtes certain que votre site restera en HTTPS de manière permanente.

Le CSP casse mon site, que faire ?

Si le CSP est en mode actif, repassez immédiatement en mode test (report-only) dans les réglages des headers. Le mode test collecte les violations sans rien bloquer
Consultez le journal des violations CSP dans la section CSP des réglages pour identifier les ressources bloquées
Ajoutez les domaines manquants dans les directives concernées (ex: frame-src, script-src). Utilisez les boutons de préréglages (YouTube, Vimeo, Google Fonts, etc.) pour les services courants
Une fois les violations résolues, repassez en mode actif

💡 Conseil : Si trop de violations sont détectées en mode actif, le CSP repasse automatiquement en mode test pour protéger votre site. Consultez le journal pour corriger les directives avant de réactiver le mode actif.

Durcissement

Le blocage de création d’administrateur m’empêche d’ajouter un nouvel admin

C’est le comportement attendu de cette fonctionnalité. Pour ajouter un administrateur :

Allez dans Samaritain > Réglages (mode avancé)
Désactivez temporairement le Blocage création administrateur
Enregistrez les modifications
Créez le nouveau compte administrateur
Réactivez le blocage et enregistrez

Surveillance et notifications

Les notifications par e-mail n’arrivent pas

Ce problème est souvent lié à la configuration d’envoi d’e-mails de votre hébergeur :

Testez d’abord avec le bouton « Envoyer un e-mail de test » dans les réglages des notifications
Si le test échoue, votre serveur ne peut probablement pas envoyer d’e-mails via la fonction PHP mail()
Installez un plugin SMTP comme WP Mail SMTP et configurez l’envoi via un service fiable (Gmail SMTP, SendGrid, Mailgun, etc.)
Retestez avec le bouton de test

💡 Conseil : Vérifiez aussi le dossier spam/indésirables de votre boîte e-mail. Les premières notifications peuvent y être classées.

Comment configurer l’envoi d’e-mails si mon hébergeur les bloque ?

De nombreux hébergeurs mutualisés limitent ou bloquent l’envoi d’e-mails par PHP. La solution recommandée est d’utiliser un plugin SMTP :

Installez WP Mail SMTP (gratuit)
Configurez-le avec un service d’envoi :
- Gmail : Gratuit, 500 e-mails/jour
- SendGrid : 100 e-mails/jour gratuits
- Mailgun : 5 000 e-mails/mois gratuits
Testez l’envoi depuis les réglages de WP Mail SMTP
Retestez le bouton d’e-mail de test dans Samaritain Security

Compatibilité

Samaritain Security est-il compatible avec Cloudflare ?

Oui. Quelques points à vérifier :

Ajoutez les plages d’IP de Cloudflare dans la liste blanche pour éviter les faux positifs du pare-feu
L’extension détecte automatiquement les services CDN et propose de les ajouter à la liste blanche
Les en-têtes de sécurité configurés via Samaritain Security peuvent entrer en conflit avec ceux configurés dans Cloudflare. Vérifiez que les mêmes en-têtes ne sont pas définis dans les deux endroits

Samaritain Security fonctionne-t-il sur Nginx ?

Oui, entièrement. Toutes les fonctionnalités sont compatibles :

Les en-têtes de sécurité sont envoyés via PHP et fonctionnent sur tous les serveurs
La protection du dossier uploads utilise .htaccess (Apache/LiteSpeed). Sur Nginx, une configuration manuelle est nécessaire, l’extension affiche les instructions directement dans l’administration
La redirection HTTPS utilise par défaut la méthode PHP (compatible partout)
Le pare-feu, la limitation de connexion, la 2FA et toutes les autres fonctionnalités fonctionnent normalement