Je dirige une agence WordPress. Seahawk Media a déployé plus de 12 000 sites WordPress et en maintient actuellement des milliers sur des plans de maintenance. Donc quand je dis que les sites headless construits avec Next.js, Astro ou Nuxt sont matériellement plus sécurisés que même un site WordPress bien géré, ce n'est pas un avis écrit depuis les mauvaises places. C'est une observation de terrain de quelqu'un qui a passé douze ans à l'intérieur du modèle de sécurité WordPress et qui déploie maintenant les deux architectures chaque semaine.
Le cadrage honnête pour ce post : la sécurité WordPress est gérable. Avec un hôte géré, Cloudflare en frontal, l'authentification à deux facteurs sur chaque connexion, un régime strict de plugins, et quelqu'un qui y prête réellement attention, WordPress fonctionne bien. La plateforme elle-même n'est pas non sécurisée. Elle nécessite simplement une gestion active pour rester ainsi. Les sites headless ne nécessitent pas cette gestion. La surface d'attaque est structurellement différente, et cette différence structurelle est tout l'argument.
À quoi ressemble réellement la surface d'attaque de WordPress ?
Un site WordPress standard au moment de la requête exécute un processus PHP, se connecte à une base de données MySQL, exécute du code de plugin, exécute du code de thème, expose /wp-admin, expose /wp-login.php, expose l'API REST à /wp-json, expose XML-RPC à /xmlrpc.php (toujours activé par défaut dans de nombreuses installations), accepte les uploads de fichiers par les gestionnaires de médias, et stocke les entrées utilisateur dans la base de données. Chacune de ces surfaces a été à l'origine d'une CVE majeure ces cinq dernières années.
Les incidents WordPress les plus coûteux auxquels nous avons répondu chez Seahawk remontaient à l'une de quatre causes racines : une vulnérabilité de plugin connue qui n'a pas été patchée à temps, une attaque par force brute sur /wp-login.php qui a réussi contre un mot de passe administrateur faible, un thème obsolète contenant un bug d'upload arbitraire de fichiers, ou une chaîne d'approvisionnement compromise sur un plugin populaire où le compte du mainteneur lui-même a été détourné. Aucune de celles-ci n'est théorique. Le XSS Yuzo Related Posts, le RCE File Manager, l'escalade de privilèges Elementor Pro, et les vulnérabilités récurrentes dans les plugins populaires de constructeur de formulaires sont des exemples concrets de ces dernières années qui ont affecté des millions de sites.
Vous pouvez vous défendre contre chacune de ces attaques. Nous le faisons, chaque jour. Mais vous devez vous défendre activement. Il n'y a aucun moment où une installation WordPress est sûre et reste sûre sans attention opérationnelle continue.
À quoi ressemble vraiment la surface d'attaque headless ?
Un site Next.js ou Astro rendu statiquement sert à la demande des fichiers HTML, CSS et JavaScript pré-construits depuis un CDN. Il n'y a pas de processus PHP. Il n'y a pas de connexion à la base de données. Il n'y a pas de panneau d'administration. Il n'y a pas de répertoire de plugins. Il n'y a pas de point de terminaison de téléchargement de fichiers sur le site public. Il n'y a pas de /wp-login.php à forcer par énumération. Il n'y a pas de XML-RPC. Il n'y a pas de formulaire de commentaire écrivant les données utilisateur dans une base de données à chaque chargement de page.
Le CMS où le contenu est rédigé, qu'il s'agisse de Sanity, Contentful, Supabase, Strapi ou d'une installation WordPress headless, se trouve sur une origine distincte derrière un accès API authentifié. Même si un attaquant compromet entièrement votre site statique servi par CDN, il n'obtient pas la base de données. La couche données nécessite des identifiants API qui ne sont stockés nulle part sur le site public.
Quand l'équipe de contenu publie du nouveau contenu, le pipeline de construction récupère les données du CMS, crée des fichiers statiques neufs et les déploie sur le CDN. La construction s'exécute dans un environnement isolé, pas sur votre serveur en production. Le résultat est un ensemble frais de fichiers statiques. Il n'y a pas d'exécution persistante à compromettre.
L'écart visuel entre les deux architectures ressemble à peu près à ceci :
À droite, chaque couche de cette pile est un endroit où une exploitation au moment de la demande peut atterrir. À gauche, le chemin de demande est un simple succès du cache de bord sur un fichier pré-rendu. Cette différence structurelle est tout le sujet.
Quelles attaques le modèle headless exclut-il structurellement ?
L'injection SQL au moment de la demande a disparu. Il n'y a pas de requête de base de données quand un visiteur charge une page. Les données ont déjà été récupérées et rendues en HTML au moment de la construction.
L'exécution de code distant de plugin et de thème au moment de la demande a disparu. Il n'y a pas de surface d'exécution PHP à exploiter sur le site public. Les dépendances de temps de construction sont une question distincte que j'aborderai ci-dessous.
Les attaques par force brute sur les identifiants du site public ont disparu. Il n'y a pas de panneau d'administration exposé à une URL publique. Le point d'accès d'authentification du CMS est sur une origine distincte et utilise généralement OAuth ou une authentification par lien magique, pas le formulaire nom d'utilisateur/mot de passe qui se fait brute-forcer trente mille fois par jour sur une installation WordPress typique.
Les exploits de téléchargement de fichiers ont disparu. Le site public n'a pas de point de terminaison de téléchargement. Les médias sont téléchargés via l'interface du CMS vers la couche de stockage du CMS, qui valide et traite les ressources dans un pipeline isolé avant qu'elles n'atteignent un CDN.
Les cross-site scripting via contenu soumis par l'utilisateur sont drastiquement réduits. Il n'y a pas de formulaires de commentaires, de formulaires de contact ou de soumissions d'utilisateurs écrivant dans une base de données runtime qu'un autre visiteur voit au prochain chargement de page. Les formulaires sur un site headless envoient des données à une API distincte (une fonction Netlify, une edge function Supabase, ou un service tiers comme Formspree) qui dispose de sa propre couche d'authentification et de validation.
La falsification de requête inter-serveur, l'inclusion de fichier local et la plupart des entrées de l'OWASP Top 10 qui dépendent d'un runtime côté serveur ne s'appliquent simplement pas à un site rendu statiquement. Les modèles d'attaque nécessitent un serveur qui exécute du code en réponse à une entrée utilisateur. Il n'existe pas de tel serveur.
Et les attaques de la chaîne d'approvisionnement sur les packages npm ?
C'est l'argument contre-courant honnête et il mérite une véritable attention. Un projet Next.js ou Astro est livré avec des centaines de dépendances npm. Si un package populaire est compromis (l'incident event-stream en 2018, le compromis ua-parser-js en 2021, l'attaque de la chaîne d'approvisionnement Polyfill.io en 2024), du code malveillant peut se retrouver dans votre sortie de build et être servi aux visiteurs.
Trois choses rendent ce risque significativement plus petit que l'équivalent WordPress en pratique. Premièrement, le code malveillant ne s'exécute que lors du prochain build et déploiement. Un compromis de plugin WordPress peut envoyer du comportement malveillant aux visiteurs en direct quelques minutes après une mise à jour automatique du plugin. Deuxièmement, les compromis de packages npm tendent à être détectés en quelques heures par des scanners automatisés, Dependabot et la communauté de recherche en sécurité, parce que beaucoup d'outils de production dépendent des mêmes packages. Troisièmement, les configurations headless conscientes de la sécurité épinglent les versions de dépendances et utilisent des lockfiles, donc vous ne récupérez pas une version malveillante jusqu'à ce que vous choisissez explicitement de mettre à jour.
Ce que je recommanderais quand même pour headless : épinglez les dépendances, exécutez npm audit à chaque build, abonnez-vous aux avis de sécurité GitHub pour vos packages majeurs, et traitez tout déploiement non programmé comme un déclencheur d'examen de sécurité.
Comment le hack WordPress typique se produit-il réellement ?
En regardant les incidents auxquels nous avons répondu chez Seahawk Media au cours des vingt-quatre derniers mois, voici la distribution approximative. À peu près quarante pour cent tracés à un plugin obsolète avec une CVE connue et correctif. À peu près vingt-cinq pour cent tracés à un compte administrateur compromis, presque toujours des mots de passe faibles sans 2FA. À peu près quinze pour cent tracés à des versions obsolètes de WordPress core ou PHP. À peu près dix pour cent tracés à une vulnérabilité dans un thème personnalisé. Les dix pour cent restants c'est tout le reste : compromis du compte d'hébergement, détournement DNS, accès développeur malveillant, chaîne d'approvisionnement d'un responsable de plugin.
Remarquez comment bon nombre de ces causes profondes n'existent simplement pas sur un site headless. Il n'y a pas de plugin à corriger. Il n'y a pas de compte administrateur sur le site public. La version PHP est sans pertinence parce qu'il n'y a pas de PHP. Le thème personnalisé s'exécute dans le pipeline de compilation, pas sur le serveur en direct.
Cela signifie-t-il que headless est infaillible ?
Non. Les vecteurs d'attaque restants sont réels et méritent d'être nommés. L'hameçonnage des identifiants CMS d'un éditeur de contenu fonctionne toujours. Le CMS lui-même peut avoir des vulnérabilités (Sanity, Contentful, Strapi et Payload ont tous eu des CVE). La compromission du compte d'hébergement sur Vercel ou Netlify donne à un attaquant les clés. L'usurpation DNS redirige le trafic indépendamment de la façon dont le site est construit. Un commit malveillant dans votre dépôt git reconstruira et déploiera tout ce que l'attaquant souhaite.
Ce qui change, c'est la courbe du coût d'attaque. Les attaques opportunistes et automatisées qui scannent Internet et frappent chaque installation WordPress quotidiennement ne ciblent simplement pas les sites headless parce qu'il n'y a pas d'empreinte digitale à scanner et pas de playbook qui fonctionne. Les attaques qui réussissent contre les sites headless sont ciblées, délibérées et nécessitent soit un vol d'identifiants, soit un accès à la chaîne d'approvisionnement. Ce sont des menaces réelles. Ce sont aussi des menaces auxquelles une installation WordPress bien gérée fait face en plus des menaces opportunistes, pas à la place de celles-ci.
Pourquoi WordPress est-il toujours assez sécurisé pour la plupart des entreprises ?
Parce que la discipline opérationnelle pour le maintenir sécurisé est bien comprise et largement pratiquée. Utilisez un hébergeur géré qui gère les mises à jour du cœur, le durcissement du serveur et l'isolement de la base de données. Placez Cloudflare ou un WAF comparable devant l'origine. Activez l'authentification à deux facteurs pour chaque connexion administrateur. Limitez les comptes administrateur au plus petit nombre de personnes possible et auditez-les trimestriellement. Maintenez un régime strict de plugins, dix ou moins de plugins bien maintenus d'auteurs réputés. Mettez à jour tout hebdomadairement. Effectuez des sauvegardes quotidiennes et testez la restauration au moins une fois par trimestre. Utilisez un scanner de malware qui s'exécute quotidiennement.
Ce régime, appliqué régulièrement, rend WordPress aussi sûr que le site headless moyen pour l'entreprise moyenne. Le piège, c'est la régularité. Les sites WordPress qui se font pirater ne sont pas ceux qui appliquent ce régime. Ce sont ceux où l'agence s'est désengagée il y a deux ans, les mises à jour de plugins se sont arrêtées, le mot de passe du compte administrateur a été défini en 2019, et personne ne s'est connecté au panneau de contrôle de l'hébergeur depuis des mois. Les sites headless sont tolérants envers ce genre de négligence. Les sites WordPress ne le sont pas.
Qu'est-ce que le delta de sécurité signifie pour les clients des agences en 2026 ?
Mon cadre de travail pour les conversations avec les clients : WordPress est la bonne réponse quand la vélocité du contenu, l'exploitation de l'écosystème de plugins, ou l'expérience de l'éditeur non technique sont les exigences principales, et le client est disposé à financer la maintenance continue de la sécurité. Headless est la bonne réponse quand le client souhaite une posture de sécurité sans maintenance, l'équipe a la maturité technique pour gérer un pipeline de compilation, et le modèle de contenu est suffisamment bien défini pour qu'un CMS structuré ait du sens.
En pratique, cela signifie : les sites marketing, les sites de présentation, les sites de documentation et les pages de propriété de grande valeur où les temps d'arrêt sont coûteux tendent à mieux fonctionner en headless. Les sites ayant une forte dépendance à l'écosystème de plugins (adhésion, e-commerce avec des exigences fiscales régionales spécialisées, LMS complexe, communauté de style BuddyPress) tendent à mieux fonctionner en WordPress parce que l'exploitation des plugins l'emporte sur la surcharge de sécurité.
La décision porte rarement sur quelle architecture est plus sûre en termes absolus. Il s'agit de savoir quelle architecture correspond à la maintenance de sécurité que le client est réalistement disposé à financer.
Qu'est-ce que je construirais si la sécurité était le seul critère ?
Un site Astro ou Next.js rendu statiquement, construit en CI à chaque changement de contenu, déployé sur Vercel ou Netlify avec des tokens API réservés au déploiement, contenu provenant de Supabase ou Sanity derrière RLS ou permissions au niveau du document, formulaires postés vers une fonction edge séparée avec limitation de débit, tous les secrets dans l'environnement du fournisseur d'hébergement (jamais validés), DNS du domaine chez Cloudflare avec DNSSEC activé, authentification à deux facteurs requise sur chaque compte de la chaîne (CMS, hébergement, DNS, git, registre de paquets), et dependabot configuré pour signaler chaque changement de dépendance. Cette configuration est véritablement quasi impossible à craquer sans une opération ciblée d'un État-nation, ce qui n'est pas le modèle de menace pour le site marketing moyen.
En résumé
WordPress est gérable. Headless est pardonnable. La différence honnête est que vous pouvez ignorer un site headless pendant six mois et le retrouver toujours sûr à votre retour. Vous ne pouvez pas faire cela avec WordPress. Pour une entreprise choisissant entre architectures en 2026, l'argument de sécurité porte moins sur « quelle est la plus sûre » et davantage sur « quelle posture de sécurité correspond à ma discipline opérationnelle réelle ». Si la réponse est « nous ne porterons pas une attention particulière à ce site », headless est le pari le plus sûr avec une marge réelle.
Nous livrons toujours plus de WordPress que n'importe quoi d'autre, parce que la plupart des clients ont toujours besoin de ce que WordPress offre uniquement. Mais pour tout client dont la conversation commence par « nous voulons juste que ça continue de fonctionner sans que nous y pensions », je recommande de plus en plus headless en premier et j'explique pourquoi.
Lectures associées
Headless WordPress en 2026 : le guide pratique complet
WordPress vs Next.js en 2026 : ma comparaison honnête
La maintenance WordPress, c'est surtout une question de rigueur