Comment auditer et securiser son CMS headless contre les exploits ClickFix en 7 etapes

— Pourquoi les CMS headless sont devenus des cibles prioritaires

La campagne ClickFix contre Ghost CMS en mai 2026, avec plus de 700 sites compromis via CVE-2026-26980, a mis en lumiere un angle mort de la securite web : les CMS headless. Ces plateformes — Ghost, Strapi, Directus, Payload, KeystoneJS — offrent une flexibilite architecturale remarquable mais exposent une surface d'API beaucoup plus large que les CMS traditionnels.

Le probleme est structurel. Un CMS headless separe le back-office (API) du front-end (site public). Cette separation est un avantage architectural, mais elle cree un vecteur d'attaque specifique : si l'API Admin est compromise, l'attaquant peut injecter du contenu malveillant dans toutes les pages servies par le front-end, sans jamais toucher un fichier sur le serveur. C'est exactement ce qui s'est passe avec la campagne Ghost CMS/ClickFix.

Ce guide vous donne les 7 etapes concretes pour auditer votre posture actuelle et mettre en place les defenses necessaires. Chaque etape est applicable a Ghost, Strapi, Directus, et la majorite des CMS headless du marche. Pour le contexte complet sur la campagne ClickFix, consultez notre guide sur la securisation de site web et notre guide sur les tests de securite web.

— Etape 1 : Cartographier toutes vos instances CMS headless

Avant de securiser quoi que ce soit, vous devez savoir ce qui existe. La premiere etape consiste a inventorier toutes les instances CMS headless en production, staging, et developpement. C'est souvent la ou les surprises commencent : des instances Ghost oubliees pour un projet client termine il y a 6 mois, un Strapi de test encore accessible sur Internet, un Directus installe par un developpeur sans passer par l'equipe infra.

Comment inventorier : scannez vos ranges IP internes et externes pour les ports typiques des CMS headless : 2368 (Ghost), 1337 (Strapi), 8055 (Directus). Utilisez nmap ou Shodan pour identifier les instances exposees. Verifiez egalement vos configurations Docker/Kubernetes pour les conteneurs CMS. Pour chaque instance, documentez : version, responsable, URL d'acces, dernier patch applique, et nombre de sites/tenants heberges.

Metrique de succes : couverture de 100% des instances identifiees, avec une fiche d'identite complete pour chacune. Aucune instance « orpheline » sans responsable designe.

— Etape 2 : Hardener l'API Admin de chaque instance

L'API Admin est le talon d'Achille des CMS headless. C'est par elle que les attaquants ont compromis les 700+ sites Ghost : en accedant a l'endpoint /ghost/api/admin/settings/ sans authentification valide. Le hardening de l'API Admin est la mesure de protection la plus impactante que vous puissiez mettre en place.

Mesures de hardening par CMS :

Regle universelle : l'interface d'administration d'un CMS headless ne devrait jamais etre accessible directement depuis Internet. Utilisez un reverse proxy avec restriction IP, un VPN, ou une solution zero-trust (Cloudflare Access, Tailscale, etc.) pour limiter l'acces aux seules personnes autorisees.

— Etape 3 : Deployer une Content Security Policy (CSP) stricte

La Content Security Policy est votre dernier filet de securite. Meme si un attaquant parvient a injecter du JavaScript via l'API Admin (comme dans la campagne Ghost CMS), une CSP bien configuree empechera le navigateur du visiteur d'executer ce code. C'est la defense la plus efficace contre ClickFix cote client.

CSP minimale anti-ClickFix :

Points critiques : n'utilisez jamais 'unsafe-inline' pour script-src (cela anéantit la protection contre les scripts injectes). Si votre theme ou vos analytics necessitent des scripts inline, utilisez des nonces (script-src 'nonce-...') ou des hashes specifiques. Deployez d'abord en mode Content-Security-Policy-Report-Only pendant 2 semaines pour identifier les violations legitimes avant de passer en mode enforce.

— Etape 4 : Monitorer les modifications de contenu et les injections

Les outils classiques de file integrity monitoring (OSSEC, Tripwire) ne detectent pas les injections via base de donnees, qui sont le vecteur principal de la campagne ClickFix. Il faut mettre en place un monitoring specifique au CMS, au niveau de la base de donnees et de l'API.

Trois niveaux de monitoring a implementer :

• •Niveau 1 — Base de donnees : configurez des triggers SQL ou des hooks sur les tables sensibles (settings, posts) pour alerter sur toute modification des champs codeinjection_head, codeinjection_foot, et les champs HTML contenant des balises <script>.
• •Niveau 2 — API Admin : loguez toutes les requetes PUT/POST/PATCH vers les endpoints d'administration. Alertez sur les modifications effectuees depuis des IP inconnues ou en dehors des heures de bureau.
• •Niveau 3 — DOM public : mettez en place un scan periodique (toutes les heures) du DOM de vos pages publiques pour detecter la presence de scripts inattendus. Un simple curl | grep -i "eval\|atob\|clipboard\|powershell" sur vos pages cles peut suffire comme premiere couche d'alerte.

— Etape 5 : Configurer un WAF adapte aux CMS headless

Un Web Application Firewall (WAF) place devant votre CMS headless peut bloquer les tentatives d'exploitation de vulnerabilites connues et inconnues. Cependant, la configuration par defaut de la plupart des WAF n'est pas adaptee aux API REST des CMS headless. Il faut des regles specifiques.

Regles WAF essentielles :

• •Bloquer les requetes a l'API Admin depuis des IP non autorisees. Configurez une whitelist d'IP pour tous les endpoints /ghost/api/admin/, /admin/ (Strapi), /admin/ (Directus).
• •Rate limiting sur les endpoints d'authentification. Maximum 5 tentatives par minute par IP sur /ghost/api/admin/session/ et equivalents.
• •Inspection du corps des requetes PUT/PATCH. Alertez ou bloquez les requetes contenant des patterns ClickFix (eval(, atob(, powershell, clipboard) dans les champs de contenu.
• •Geo-blocking si applicable. Si vos administrateurs sont tous en France, bloquez l'acces a l'API Admin depuis les autres pays.

Solutions recommandees : Cloudflare WAF (gratuit pour les regles de base, Pro pour les regles custom), AWS WAF (si vous hebergez sur AWS), ou ModSecurity avec des regles OWASP CRS adaptees.

— Etape 6 : Former les equipes editoriales et techniques

Les equipes editoriales (qui publient du contenu via le CMS) et les equipes techniques (qui administrent l'infrastructure) doivent comprendre les risques specifiques aux CMS headless et aux attaques ClickFix. La formation couvre deux axes : la reconnaissance des signaux d'alerte et la reaction en cas d'incident.

Contenu de formation pour les equipes editoriales :

• •Reconnaitre un popup ClickFix : aucun site web legitime ne demande de copier-coller une commande dans un terminal
• •Signaler immediatement tout contenu suspect apparu dans le CMS sans action editoriale
• •Ne jamais partager les credentials CMS par email ou messagerie non chiffree
• •Verifier systematiquement l'URL du back-office avant de se connecter (phishing du panel admin)

Contenu de formation pour les equipes techniques :

• •Comprendre la chaine d'attaque CVE + injection + ClickFix et les points de detection a chaque etape
• •Savoir auditer manuellement la base de donnees du CMS pour des injections (requetes SQL de verification)
• •Procedure de patch d'urgence : tester en staging, deployer en production, verifier le fonctionnement
• •Procedure de response a incident CMS : isolation, nettoyage, notification, forensic

— Etape 7 : Mettre en place un programme d'audit continu

La securite d'un CMS headless n'est pas un projet ponctuel. Les vulnerabilites sont decouvertes en continu, les configurations derivent, et les nouvelles fonctionnalites introduisent de nouvelles surfaces d'attaque. Un programme d'audit regulier est indispensable pour maintenir votre posture de securite.

Cadence d'audit recommandee :

Documentation : chaque audit doit produire un rapport documente avec les constatations, les actions correctives, et les metriques d'evolution. Pour les entreprises soumises a NIS2, cette documentation est obligatoire et doit etre conservee au minimum 3 ans. Notre guide sur comment securiser un site web et notre article sur comment tester la securite de son site web fournissent des cadres complementaires pour structurer vos audits.

— Synthese : construire une defense en profondeur pour votre CMS headless

Les 7 etapes de ce guide forment une defense en profondeur : meme si une couche echoue, les autres compensent. La cartographie (etape 1) et le hardening API (etape 2) reduisent la surface d'attaque. La CSP (etape 3) neutralise les injections cote client. Le monitoring (etape 4) et le WAF (etape 5) detectent et bloquent les tentatives d'exploitation. La formation (etape 6) et l'audit continu (etape 7) assurent la perennite de la posture.

Commencez par les etapes 1 et 2 cette semaine : elles apportent 80% de la reduction de risque. Deployez la CSP (etape 3) dans les 2 semaines suivantes. Les etapes 4 a 7 construisent la resilience sur le moyen terme et doivent etre en place dans le mois.

— FAQ