WordPress headless piraté : le front Next.js a l'air propre

Pourquoi le front « clean » rassure à tort

Vous ouvrez le site vitrine : pages statiques, CDN, pas de `/wp-admin` visible. Donc « ce n'est pas WordPress », donc « ce n'est pas grave ». Pendant ce temps `wp-json` sert des posts injectés, les uploads hébergent un PHP, un webhook de preview pousse le spam à chaque build. Le front n'est qu'un rendu. L'origine est le CMS.

Les visiteurs et Googlebot voient souvent le rendu. L'attaquant, lui, vise `wp-login`, l'API, le bucket média, le secret de preview. Votre impression « chez moi ça marche » est encore plus trompeuse qu'en monolithique : vous n'ouvrez jamais l'admin.

Le guide WordPress s'applique à l'origine. Cet article ajoute le pipeline. Omettre l'un des deux, c'est nettoyer la vitrine et garder la cuisine.

Ce qui est encore WordPress dans un headless

L'admin, les utilisateurs, les extensions (SEO, formulaires, WooCommerce parfois), `wp-cron` ou son remplaçant, la base, `wp-content/uploads`. Un WordPress 6 à jour ne change rien si ACF, Yoast ou un plugin de preview a une faille. WordPress récent et piratages actuels.

L'API REST et GraphQL (WPGraphQL) exposent plus de surface qu'une vitrine classique. Des routes d'écriture mal protégées, des application passwords oubliés, un utilisateur `editor` créé pour le front. Relisez ces comptes comme des admins.

Le média : le CDN d'images peut proxy un chemin qui n'est pas une image. Purge et règles. CDN et PHP.

API, médias, et le HTML que Google voit

Selon l'architecture, Googlebot hit le front (SSG/SSR) ou, plus rarement, des URL WP encore publiques. Inspectez les deux origines si elles répondent. Un cloaking côté WP peut se retrouver « cuit » dans le HTML statique au prochain build — et y rester jusqu'au suivant.

Des pages spam IA en base deviennent des routes Next (`/blog/[slug]`) parfaitement « uniques ». Le générateur n'est plus un PHP à la racine : c'est un post. Coupez l'entrée WP, puis rebuild, puis 410 sur les slugs déjà déployés. Pages spam IA.

Search Console doit connaître l'hôte que voient les gens (souvent `www`) et, si elles existent encore, les URL `cms.` ou `api.`. Une propriété domaine évite l'angle mort.

Webhooks de build et jetons

Vercel, Netlify, un GitHub Action, un bouton « Deploy » : un secret qui déclenche un build. S'il fuit (log, `.env` exposé, repo public), n'importe qui republie. Tournez ces jetons comme des mots de passe de panel. `.env` exposé.

Un webhook WordPress « on publish, build » déclenché par l'attaquant pousse le spam en production à chaque article fantôme. Désactivez le trigger le temps du constat, pas seulement le plugin SEO.

Les tokens d'API (preview, application passwords, clés CI) survivent au mot de passe admin. Listez-les, révoquez les inconnus. C'est le pendant headless des application passwords oubliés.

• Secrets de deploy et de preview : rotation.
• Webhooks CMS → CI : off le temps du nettoyage.
• Comptes Git (org) : 2FA, invitations, deploy keys.

Rebuild, cache edge, et le malware qui revient

Rebuilder « pour être sûr » pendant que l'API est sale cuit le malware dans le HTML statique et dans l'edge. Vous avez alors un front infecté même après avoir nettoyé WP — jusqu'au build suivant, ou plus si personne ne purge.

L'ordre : figer, nettoyer l'origine, tourner les jetons, puis rebuild depuis une branche saine, puis purge CDN / edge large. Une purge d'une URL ne suffit pas si 10 000 slugs ont été générés.

Un cache objet Redis côté WP ressert des options injectées au front via l'API. Flush. Redis / object cache.

Où chercher sans tout casser le pipeline

Copie de WP (fichiers + base) hors serveur, comme un monolithique. Copie des variables d'environnement (hors prod). Journaux de build. Liste des derniers déploys et qui les a déclenchés. Ne « cassez pas » Vercel pour vous rassurer : vous perdez la chronologie.

Comparez le cœur et les extensions WP aux zips. Relisez mu-plugins. Relisez les routes API ouvertes à l'anonyme. Relisez `uploads` pour du PHP. Le front : dépendances npm, scripts postinstall, une librairie de tracking ajoutée sans vous.

Ne videz pas le dossier `uploads` : vous cassez les médias du SSG. Isolez les exécutables. Interdisez PHP dans ce dossier côté origine.

Refermer : CMS, CI, et le front

WP : mêmes fermetures qu'un site classique (comptes, clés, extensions portes). CI : nouveaux secrets, webhooks signés, moins de gens qui peuvent déployer. Front : dépendances relues, variables tournées, preview protégée.

L'admin WP ne doit pas être sur le même hôte public que le front sans nécessité. S'il l'est, restreignez (IP, auth). Ce n'est pas une « refonte » : c'est une clôture. La refonte globale attend.

Surveillance : nouveaux posts, nouveaux déploys hors horaires, fichiers WP, invitations Git. Trois signaux, adaptés au pipeline. Surveillance.

Décider qui nettoie quoi

L'agence front et le nettoyeur WP ne sont pas interchangeables. Deux devis, deux accès : panel/CMS d'un côté, org Git / projet Vercel de l'autre. Un seul prestataire qui « s'occupe de tout » sans lister les deux origines vend une moitié.

Vous pouvez nous confier l'origine et garder votre équipe front pour le rebuild, une fois que nous disons que l'API est tenable. C'est souvent le découpage le plus sain.

Si personne dans l'équipe ne sait où vit WordPress (« c'est plus Next maintenant »), commencez par cette carte. Sans elle, tout le monde rebuild, personne ne compare un fichier à son zip.