OWASP Top 10:2025 et WordPress : les dix risques expliqués

L’OWASP Top 10 est la liste de risques de sécurité des applications web la plus connue, et son édition 2025 remplace celle de 2021. Appliquée à WordPress, elle se lit comme une carte de la façon dont les sites sont réellement piratés : contrôles d’autorisation absents dans les extensions, configuration négligée, composants obsolètes ou abandonnés.

Ce guide traduit chacun des dix risques en termes WordPress, montre ceux que les propriétaires de sites peuvent vérifier dès aujourd’hui et ceux que seuls les développeurs peuvent corriger dans le code.

Ce qu’est l’OWASP Top 10, et ce qu’il n’est pas

La liste est publiée par la fondation OWASP, une communauté à but non lucratif consacrée à la sécurité des logiciels. L’OWASP la présente comme « a standard awareness document for developers and web application security » (un document de sensibilisation de référence pour les développeurs et la sécurité des applications web) : un classement des catégories de risques les plus critiques, établi à partir de données sur les vulnérabilités et d’une enquête menée auprès de la communauté.

Ce n’est pas une certification, et aucun site n’est « conforme OWASP ». Servez-vous-en pour décider où regarder en premier. S’il vous faut une liste détaillée d’exigences vérifiables, l’OWASP publie pour cela l’Application Security Verification Standard (ASVS).

Ce qui a changé en 2025

Par rapport à 2021, l’OWASP Top 10:2025 compte deux nouvelles catégories et quelques changements de place :

• A03 Software Supply Chain Failures (défaillances de la chaîne d’approvisionnement logicielle) est nouvelle. Elle élargit l’ancienne catégorie « Vulnerable and Outdated Components » (composants vulnérables et obsolètes) à tout ce qui vous sert à développer et à mettre à jour.
• A10 Mishandling of Exceptional Conditions (mauvaise gestion des situations exceptionnelles) est nouvelle, elle aussi : gestion des erreurs défaillante, erreurs de logique et systèmes qui restent ouverts en cas d’échec (« fail open »).
• La falsification de requêtes côté serveur (server-side request forgery, SSRF) n’est plus une catégorie à part entière : elle est désormais rattachée à A01 Broken Access Control.
• Security Misconfiguration (mauvaise configuration de sécurité) passe de la cinquième à la deuxième place.
• A09 s’appelle désormais Security Logging and Alerting Failures, pour rappeler que des journaux que personne ne lit ne servent à rien.

Les dix risques en termes WordPress

Le contrôle d’accès défaillant arrive aussi en tête pour WordPress : le rapport de Patchstack State of WordPress Security in 2026 en fait la catégorie de vulnérabilités la plus exploitée en 2025. Patchstack étant un éditeur de solutions de sécurité, considérez ce rapport comme une source bien informée parmi d’autres.

Cinq risques que les propriétaires de sites peuvent vérifier dès aujourd’hui

Inutile de lire du code pour ceux-là. Chaque contrôle prend quelques minutes avec le tableau de bord ou WP-CLI.

A03 : connaître et mettre à jour vos composants

La plupart des vulnérabilités WordPress se trouvent dans les extensions et les thèmes, pas dans le cœur. Tenez un inventaire, installez rapidement les mises à jour de sécurité et supprimez ce que vous n’utilisez pas. Cette commande liste les extensions pour lesquelles une mise à jour est en attente :

wp plugin list --update=available --fields=name,version,update_version

Notre guide sur les extensions WordPress vulnérables traite en détail des extensions abandonnées et « nulled ».

A02 et A10 : masquer les erreurs aux visiteurs

Un site en production ne doit jamais afficher d’erreurs ni d’avertissements PHP : ils révèlent des chemins de fichiers et parfois des détails sur la base de données. Dans wp-config.php, laissez le débogage désactivé en production :

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

Vérifiez aussi que votre serveur n’affiche pas le contenu des répertoires et qu’aucun fichier de sauvegarde ou d’export n’est accessible sous la racine web.

A07 : protéger chaque connexion

Activez l’authentification à deux facteurs pour tous les administrateurs et éditeurs, et limitez les tentatives de connexion échouées. Notre guide de l’authentification à deux facteurs pour WordPress présente les options, des applications d’authentification aux passkeys.

A08 : vérifier que les fichiers sont d’origine

WP-CLI compare vos fichiers avec les sommes de contrôle officielles de WordPress.org :

wp core verify-checksums
wp plugin verify-checksums --all

Tout fichier modifié ou inconnu dans le cœur mérite un examen. Les extensions qui ne proviennent pas de WordPress.org ne peuvent pas être vérifiées de cette façon ; comparez-les avec une copie fraîchement téléchargée chez l’éditeur.

A09 : garder une trace et recevoir des alertes

Journalisez les connexions, les nouveaux utilisateurs, les changements de rôle, les installations d’extensions et les modifications de fichiers, et veillez à ce que quelqu’un soit alerté. Sans ces traces, impossible de savoir ce qui s’est passé après un incident, ni de respecter le délai de notification de 72 heures prévu par le RGPD, que décrit notre guide sur les violations de données.

Trois risques que seuls les développeurs peuvent corriger

Si vous développez des extensions ou des thèmes, A01, A05 et A10 se résument surtout à quelques fonctions WordPress utilisées systématiquement.

• Contrôle d’accès (A01) : appelez current_user_can() avant chaque action privilégiée, vérifiez les nonces avec check_ajax_referer() ou wp_verify_nonce(), et dotez chaque route REST d’un permission_callback. Depuis WordPress 5.5, une route qui n’en a pas déclenche un avertissement (notice) ; pour les routes censées être publiques, WordPress recommande __return_true.
• SSRF (désormais dans A01) : quand vous récupérez une URL fournie par un utilisateur, utilisez wp_safe_remote_get(). Cette fonction valide l’adresse et chaque redirection, et refuse par défaut les réseaux locaux et privés.
• Injection (A05) : construisez vos requêtes avec $wpdb->prepare(), nettoyez les entrées dès leur arrivée (sanitize_text_field(), absint()) et échappez les sorties au dernier moment (esc_html(), esc_attr(), esc_url()).
• Situations exceptionnelles (A10) : testez is_wp_error() après chaque appel susceptible d’échouer, et faites en sorte que les contrôles de sécurité échouent en position fermée (« fail closed ») : si une vérification d’autorisation ou de licence ne peut pas aboutir, refusez l’action.

Voici à quoi ressemble une route REST qui respecte ces règles :

register_rest_route( 'myplugin/v1', '/report', array(
    'methods'             => 'POST',
    'callback'            => 'myplugin_save_report',
    'permission_callback' => function () {
        return current_user_can( 'manage_options' );
    },
) );

Le chapitre consacré à la sécurité du manuel du développeur WordPress explique chaque fonction avec des exemples.

OWASP, RGPD et NIS2

L’OWASP Top 10 n’est pas une loi, mais c’est une référence courante pour définir « l’état de l’art » en sécurité web. L’article 32 du RGPD exige des mesures techniques appropriées ainsi qu’une procédure visant à tester, à analyser et à évaluer régulièrement leur efficacité. Passer un site WordPress au crible des dix catégories est une façon concrète de démontrer cette procédure.

Pour les organisations soumises à NIS2, l’article 21, paragraphe 2, range la sécurité de l’acquisition, du développement et de la maintenance, y compris le traitement des vulnérabilités, parmi les mesures minimales. A03 et A05 correspondent directement à cette obligation.

Notre extension Security Audit & Compliance rattache chaque constat à une catégorie de l’OWASP Top 10:2025, en plus de l’article 32 du RGPD et de l’article 21 de NIS2 : un rapport montre ainsi à quel risque appartient chaque problème. Elle détecte et signale ; la décision de corriger vous revient. Voir ce qu’elle vérifie.

FAQ

L’OWASP Top 10 est-il une obligation légale ?

Non. C’est un document de sensibilisation. Des textes comme le RGPD exigent une sécurité appropriée, et le Top 10 vous aide à déterminer ce que cela signifie pour un site web.

Faut-il refaire ma revue de sécurité à cause de l’édition 2025 ?

Inutile de repartir de zéro. La plupart des risques sont toujours là ; mettez à jour vos notes pour les nouvelles catégories A03 et A10 et pour la nouvelle numérotation.

Le cœur de WordPress représente-t-il en soi un risque OWASP important ?

Rarement. Patchstack a recensé six vulnérabilités dans le cœur en 2025, toutes de faible priorité, contre des milliers dans les extensions et les thèmes. C’est dans votre liste d’extensions que se trouve le risque.

Cet article est une information générale et ne constitue pas un conseil juridique.