Endpoints exposés, API et webhooks

“Rénover la vitrine mais laisser l'ancienne porte de derrière déverrouillée, et absente du plan.”

Les endpoints que vous avez oublié avoir livrés

Changer l'UI ne supprime pas l'API derrière elle. Vous retirez un bouton, l'écran a l'air propre, et la route que ce bouton appelait est toujours en ligne et répond toujours. Au fil des itérations, une app construite par IA en accumule : anciennes versions d'endpoints, routes de debug et de test ajoutées « juste pour vérifier un truc », actions admin jamais protégées. Elles sont invisibles dans l'app et pleinement accessibles à quiconque connaît, ou devine, l'URL.

Le changement de perspective : votre frontière de sécurité est l'ensemble des routes auxquelles votre serveur répondra, pas l'ensemble des liens de votre interface. Un attaquant lit votre bundle JavaScript pour énumérer les routes, ignore complètement votre UI et les appelle directement. Retiré de l'écran n'est pas retiré du serveur.

Webhooks : n'importe qui peut envoyer ce POST

Un webhook est une URL publique sur votre serveur qu'un fournisseur (Stripe, GitHub, un service de mail) appelle pour vous signaler qu'un événement s'est produit. Le hic : l'URL est publique, donc n'importe qui peut l'appeler, y compris un attaquant envoyant un faux « paiement réussi » ou « abonnement amélioré » pour débloquer gratuitement des fonctionnalités payantes. Le fournisseur signe chaque appel réel avec un secret partagé ; si vous ne vérifiez pas cette signature, vous faites confiance aux affirmations d'inconnus sur votre propre activité. Les signatures arrêtent la falsification ; les horodatages arrêtent le rejeu.↗

// Verify the signature BEFORE trusting anything in the payload.
const sig = req.headers.get("stripe-signature");
let event;
try {
  event = stripe.webhooks.constructEvent(rawBody, sig, process.env.STRIPE_WEBHOOK_SECRET);
} catch {
  return new Response("bad signature", { status: 400 }); // forged or tampered
}
// Only now is it safe to act on event.type

CORS et limites de débit

Deux réglages que les outils IA ratent parce que la version permissive fait disparaître les erreurs. CORS contrôle quels scripts d'autres sites web peuvent appeler votre API depuis un navigateur ; un outil bloqué sur une erreur cross-origin le réglera souvent pour tout autoriser, ce qui, combiné aux identifiants, peut permettre à n'importe quel site d'agir comme votre utilisateur. Verrouillez-le sur vos propres origines. Et la limitation de débit : sans elle, la connexion et l'inscription sont ouvertes à la force brute, les endpoints coûteux sont ouverts aux abus qui gonflent la facture, et vos données sont ouvertes au scraping.

• CORS : n'autorisez que vos vraies origines, jamais '*' combiné aux identifiants.
• Limitez le débit par utilisateur et par IP, surtout sur l'authentification, l'inscription, la réinitialisation de mot de passe et tout ce qui coûte de l'argent à exécuter.
• Placez d'abord les endpoints coûteux ou sensibles derrière l'authentification ; la limitation de débit est un filet de secours, pas la première ligne.

L'inventaire dont vous avez besoin

Vous ne pouvez pas sécuriser une surface que vous n'avez pas cartographiée. Une fois, avant le lancement, énumérez-la :

• Listez chaque route que le serveur sert réellement, à partir du code et du bundle, pas du menu.
• Pour chacune : est-elle censée être publique ? Sinon, authentifie-t-elle et autorise-t-elle (chapitre 4) ?
• Supprimez les routes mortes, de debug et d'anciennes versions ; la plus petite surface est la plus sûre.
• Pour chaque webhook entrant, confirmez la vérification de signature, puis confirmez qu'il rejette un appel non signé.

Cet inventaire est aussi l'entrée de la checklist de lancement du prochain chapitre. Vous ne pouvez pas cocher « chaque endpoint est autorisé » avant de savoir ce qu'est chaque endpoint.