WordPress sécurité

Confirmez WordPress avant de tester

VICE vérifie le domaine vérifié pour les marqueurs de page WordPress, d'en-tête et d'actifs publics avant d'exécuter des sondes ciblées. Cela maintient le résultat lié au comportement observé du CMS au lieu d'une étiquette technologique devinée.

Si WordPress ne peut pas être confirmé, l'audit signale une limitation de couverture au lieu d'inventer un score de sécurité ou une vulnérabilité.

Examiner l’exposition de l’identité publique

WordPress peut révéler les noms de comptes via les redirections d'auteur et le point de terminaison public des utilisateurs REST. VICE enregistre le comportement observé afin que vous puissiez le comparer avec le modèle de publication prévu par le site.

• Auteur de redirections d'archives qui exposent un identifiant ou un nom d'affichage.
• Réponses publiques du point de terminaison des utilisateurs REST.
• Marqueurs de preuves qui identifient le chemin testé sans stocker le contenu de réponse sensible.

Inspecter XML-RPC, la connexion et cron

L’accessibilité à elle seule ne prouve pas l’exploitation. Chaque problème détecté doit décrire le comportement plus fort observé, sa confiance et le contrôle recommandé.

• Comportement XML-RPC accessible qui peut augmenter l'efficacité des tentatives de mot de passe.
• Le chemin de connexion WordPress par défaut et son comportement public.
• Accès public HTTP au point de terminaison cron WordPress.

Lancer l’audit ciblé

Ouvrez WordPress dans un espace de travail de domaine vérifié et démarrez l'analyse. L'exécution apparaît dans la liste d'audit centrale avec le même statut et le même historique que chaque audit géré.

Les problèmes exploitables sont ajoutés à la vue des problèmes détectés par le domaine. WordPress reste également disponible dans le cadre d'audits de sécurité complets et personnalisés.

Lire l'exposition dans son contexte

Un nom d'auteur public peut être intentionnel sur un site de publication, tandis qu'un identifiant de connexion réutilisé ailleurs crée plus de risques. Examinez les preuves par rapport au modèle de compte, aux contrôles d’authentification et aux exigences opérationnelles.

Une demande ayant échoué ou un site inaccessible constitue une limitation de couverture. Il ne s’agit pas d’un problème critique détecté par WordPress.

Corriger et retester

Réexécutez l'audit WordPress ciblé à partir du même espace de travail et comparez la couverture équivalente avant de marquer un problème détecté comme résolu.

• Restreindre l’énumération publique des utilisateurs lorsque le site ne l’exige pas.
• Désactivez XML-RPC lorsqu'il n'est pas utilisé ou protégez les méthodes requises avec une authentification forte et des limites de débit.
• Protégez les flux de connexion avec des limites de débit, des informations d'identification solides et une authentification multifacteur lorsque cela est disponible.
• Préférez un planificateur de serveur pour WordPress cron lorsque le déclenchement public HTTP n'est pas nécessaire.