Révoquer clés API, applications et webhooks après un incident

Pourquoi ça survit au nouveau mot de passe

Une application password, une clé REST, un webhook signé, un token OAuth : émis une fois, valides jusqu'à révocation. L'admin CMS peut avoir un secret neuf et l'attaquant un jeton ancien. C'est le même principe que la règle de transfert et que la session. Trois persistances, trois gestes.

Les dossiers « on a tout changé » sans cette liste se réinfectent par WooCommerce REST, par un Zapier, par un SMTP Brevo. Cause 2 des 48 h, version API.

On ne montre pas comment forger un jeton. On montre où les *révoquer* dans les consoles que vous payez.

La liste à dérouler, sans folklore

CMS : utilisateurs applicatifs, REST, webhooks boutique, cron URL secrètes, « connection keys ». Paiement : Stripe, PayPal, modules banque, clés de test *et* live. Pub et mesure : Google, Meta, TikTok, Search Console, Analytics, GTM. Mail : SMTP, ESP, webhooks d'événements. Infra : panel, DNS, Cloudflare, GitHub / GitLab, S3 backups. Support : chat, helpdesk. Autres : Calendly, ERP, marketplace.

Cochez « n'existe pas » plutôt que d'oublier la ligne. L'inventaire des pixels recoupe celui-ci.

Les `.env`, `wp-config`, fichiers d'intégration Prestashop : lisez-les *en copie isolée*. Ils sont le plan. Tournez ce qu'ils citent.

• CMS / boutique.
• Paiement, pub, mail.
• Infra, Git, backups, saisie.

CMS : apps, REST, webhooks

WordPress : application passwords par utilisateur, éventuels JWT, WooCommerce REST (cles consumer), webhooks de commandes. Magento : integrations, tokens admin. Prestashop : clés webservice. Chaque écran a un « révoquer / régénérer ». Tous les utilisateurs, pas seulement le vôtre.

Une URL de cron `?token=` dans un plugin : changez le secret, pas seulement le mot de passe admin. Les « secret keys » dans la config : régénérer *une* fois, documenté, comme les sels de session.

xmlrpc et apps mobiles : retirez ce qui ne sert pas. Moins de tuyaux, moins d'oublis.

Paiement, pub, Search Console

Stripe : clés restreintes, webhooks, utilisateurs dashboard, applications connectées. Un webhook pirate crée des faux événements ou lit les objets. Restricted keys > clés secrètes trop larges, à froid. Search Console / Ads : utilisateurs, « propriétaires », liens API. Un compte Google encore « proprio » après un freelance de 2021 est une porte de comm' et parfois de DNS.

Si un skimmer a tourné, le PSP a *son* incident en plus. Coordonnez. Ce n'est pas seulement « régénérer la clé du plugin ».

Meta Business : admins, pixels, catalogues. Un pixel inconnu : retirez *et* révoquez l'accès qui pouvait le poser.

Mail et automatisations

SMTP du CMS, ESP (Brevo, Mailchimp, SES), inbound parse, webhooks « email ouvert ». Une clé SMTP oubliée continue le spam après WordPress « propre ». Zapier / Make / n8n : connexions, scénarios. Un scénario « à chaque commande, POST vers URL » est une exfil.

OAuth « se connecter avec Google » côté site : révisez les apps autorisées dans le compte Google *du site*, pas seulement le wp-admin.

Les files : pause pendant la révocation, puis un envoi test. Pas un rattrapage de masse. Réchauffer.

CDN, Git, backups, chat

Cloudflare : tokens API, workers, membres. Git : deploy keys, tokens CI, webhooks qui tirent sur le prod. Une clé CI pousse un thème sale. Backups S3 : access key dans le plugin — révoquez, nouvelle clé *restreinte au bucket*, plus dans un ticket Slack. Chat / helpdesk : tokens bots.

Registrar / DNS API : prioritaire si le MX a bougé. Un token OVH / Gandi vaut un panel.

Les webhooks « Slack #commandes » vers un canal que l'attaquant a rejoint : changez l'URL, pas seulement le mot de passe Slack du gérant.

L'ordre : inventaire, révocation, remplacement

1) Liste et captures (qui avait quoi). 2) Révoquer l'inconnu et tout ce qui a pu être lu (config). 3) Recréer *ce dont le métier a besoin*, secrets nouveaux, droits minimaux. 4) Tester un paiement, un mail, un déploiement. Inverser 3 et 2, c'est laisser l'ancien jeton vivre « encore une heure ».

Prévenez la compta / le marketing : la pub et les factures peuvent tousser. Mieux qu'une surprise + un jeton pirate encore valide.

Panel et FTP *avant* si ce n'est pas fait : sinon l'attaquant relit le nouveau `.env` et vous recommencez. Backdoor d'abord ou en parallèle serré.

Preuve et oubli à J+30

Cochez les lignes, datez. Pièce assurance et constat (accès API = accès données parfois). Une clé Stripe lue n'est pas un dump SQL ; c'est un autre périmètre, à écrire.

J+30 : parcourir les consoles, nouveaux tokens inconnus. Journalisation ne voit pas Stripe. Un rappel calendrier, si.

Créer un espace pour les fichiers. Joignez la liste « déjà révoqué / pas encore » : ça évite qu'on casse Stripe deux fois ou qu'on l'oublie.

• Liste écrite, tous les silos.
• Révoquer, puis recréer le minimum.
• Relire les consoles à 30 jours.