Block 404 PHP File Scanning: bloquer le scan de fichiers PHP inexistants pour renforcer la sécurité WordPress

Pourquoi ce module est utile

Les bots malveillants testent souvent des URLs de fichiers PHP connus ou supposés vulnérables, par exemple des scripts dans des plugins/thèmes.
Quand ces URLs n’existent pas, WordPress peut répondre en 404. Le problème: cela confirme qu’une ressource est sondée et alimente du bruit dans les logs.

Le module Block 404 PHP File Scanning ajoute une défense simple et efficace:

1. détecter une requête front vers un chemin se terminant par .php
2. vérifier que WordPress l’a résolue en 404
3. confirmer que le fichier ciblé n’existe pas physiquement
4. renvoyer une réponse 403 Forbidden
5. journaliser l’événement avec le marqueur PHP404

Résultat: vous réduisez la surface de reconnaissance automatisée et améliorez la lisibilité de vos journaux.

Fonctionnement technique

Le module exécute sa logique pendant template_redirect avec une priorité élevée, pour agir au bon moment du cycle de requête.

Ce qui est bloqué

• Requêtes frontend vers un chemin .php
• Requêtes déjà résolues en 404 par WordPress
• Fichier cible inexistant sous la racine WordPress

Ce qui est ignoré volontairement

• Administration WordPress
• REST API
• AJAX
• CRON
• WP-CLI
• XML-RPC
• Requêtes qui ne ciblent pas de .php
• Requêtes vers un fichier .php réellement présent

Bypass personnalisé via filtre

Si vous avez un cas métier spécifique, vous pouvez bypasser la protection avec le filtre wpmastertoolkit/block_404_on_php/bypass.

Exemple:

add_filter('wpmastertoolkit/block_404_on_php/bypass', function($bypass, $current_url) {
    if (strpos($current_url, '/mon-endpoint-technique.php') !== false) {
        return true;
    }
    return $bypass;
}, 10, 2);

Logs et observabilité

Chaque blocage est logué avec le code PHP404.
Exemple de message: Blocked nonexistent PHP request: URL demandée.

C’est pratique pour:

1. mesurer le volume de scan
2. identifier des patterns d’attaque
3. prioriser des règles WAF/CDN complémentaires

Bonnes pratiques SEO + sécurité

Même si ce module est sécurité-first, il a un impact SEO indirect positif:

1. moins de bruit serveur et plus de stabilité sur les vraies pages crawlables
2. meilleure qualité d’analyse des logs techniques
3. réduction du risque d’exploitation automatisée de endpoints historiques

Conseils d’implémentation:

1. activer le module en production et préproduction
2. surveiller les logs la première semaine
3. ajouter un bypass uniquement si un cas légitime est confirmé
4. combiner avec durcissement des accès sensibles et limitation des tentatives

FAQ rapide

Est-ce que le module bloque des pages WordPress normales

Non. Il cible uniquement des URLs .php inexistantes déjà vues comme 404.

Pourquoi renvoyer 403 plutôt que 404

403 exprime explicitement un refus d’accès et est souvent plus dissuasif pour les scanners automatisés.

Ce module remplace-t-il un WAF

Non. Il complète votre stratégie de sécurité applicative côté WordPress.