Architecture sans secrets : comment minimiser votre surface d'attaque

La première question qu'un ingénieur sécurité devrait poser à toute équipe technique n'est pas « avez-vous un WAF ? » ni « quelle est votre politique MFA ? », mais simplement : « combien de secrets votre équipe détient-elle, et où sont-ils ? ». Le nombre est révélateur. Chaque clé d'API, chaque mot de passe de service, chaque jeton de déploiement, chaque certificat privé est un vecteur de compromission : un endroit où il peut fuiter (repo public, log, capture d'écran, employé sortant), un endroit où il doit être tourné, audité, restreint en portée.

Une startup SaaS classique cumule rapidement vingt à cinquante secrets : clé Stripe secrète, identifiants de base de données de production et de staging, clés Mailgun ou SendGrid, clés Twilio, clés Segment ou Mixpanel, clés DNS chez le registrar, jetons GitHub Actions, clés AWS IAM, certificats TLS, secrets OAuth. Chacun de ces secrets est inoffensif individuellement, mais la masse crée une dette opérationnelle latente : qui sait où chacun vit ? Qui sait quand il a été tourné pour la dernière fois ? Que se passe-t-il si l'ingénieur qui l'a configuré quitte l'entreprise ?

L'approche Pillar consiste à renverser la question. Au lieu de chercher à mieux gérer les cinquante secrets, on conçoit l'architecture pour n'en générer que six. Cela ne résout pas tous les problèmes de sécurité, mais cela réduit drastiquement la surface d'attaque et libère du temps opérationnel pour les enjeux qui restent.

Le paiement est le cas d'usage le plus instructif. L'intégration Stripe « classique » récupère une clé secrète côté serveur et instancie un client Stripe dans le backend. Cette clé a un pouvoir étendu (créer des charges, rembourser, lister des clients) et doit être protégée en conséquence. L'alternative est Stripe Payment Links : vous créez chaque lien depuis le Dashboard Stripe, vous intégrez le lien comme une simple URL HTML dans votre site, et Stripe héberge la page de checkout. Aucune clé API ne quitte le Dashboard. La seule pièce qui revient chez vous est l'événement webhook quand un paiement aboutit ; ce webhook est signé avec un secret partagé, isolé dans un Cloudflare Worker dédié.

Pour les formulaires, l'archétype classique est : une route backend reçoit le POST, valide les champs, stocke en base, envoie un mail via SendGrid ou Mailgun. Trois à quatre secrets potentiels en jeu (clé SMTP, clé d'API courriel, identifiants base de données). La substitution sans secret : Formspree (ou un équivalent comme Basin, Getform) reçoit le POST directement depuis le navigateur, applique sa propre couche anti-spam, et réexpédie par courriel. Le formulaire pointe vers un endpoint public ; il n'y a strictement aucune clé à protéger côté Pillar.

Pour l'authentification administrative, plutôt que de gérer un système d'identifiants applicatifs (et donc une base utilisateurs, un système de hash de mots de passe, des jetons de session, éventuellement un fournisseur OAuth tiers), Pillar s'appuie sur Cloudflare Access, qui délègue l'authentification au fournisseur SSO de l'organisation. La gestion des comptes vit au niveau Cloudflare ; le site lui-même ne stocke ni mot de passe, ni clé de session, ni jeton OAuth.

Cette approche a des limites qu'il faut nommer. D'abord, vous cédez du contrôle sur l'expérience utilisateur : la page de checkout est celle de Stripe, pas la vôtre ; le rendu du courriel de notification est celui de Formspree. Si votre produit exige une expérience de paiement entièrement custom, ou un workflow de formulaire avec logique conditionnelle complexe, le compromis ne tient plus. Pour un site éditorial, une boutique d'infoproduits, un portfolio professionnel, l'expérience standard suffit largement ; pour un SaaS produit dont le checkout fait partie de la marque, la décision est plus nuancée.

Ensuite, vous dépendez davantage d'un nombre restreint de fournisseurs. Stripe pour le paiement, Cloudflare pour l'hébergement et l'authentification, Formspree pour les formulaires. Si l'un de ces fournisseurs tombe, votre service tombe avec lui. C'est un arbitrage classique entre risque de fournisseur (centralisé) et risque opérationnel (distribué sur de nombreux secrets que vous gérez vous-même). Pour la grande majorité des petites équipes, le risque opérationnel domine : une clé mal gérée ou un employé négligent cause plus d'incidents que les pannes de Stripe.

Enfin, certaines fonctionnalités sont simplement inaccessibles sans backend. La personnalisation profonde, les recommandations algorithmiques, les tableaux de bord client riches, la connexion temps réel à des services tiers : tout cela demande un serveur d'application. The Zero-Secret Stack ne prétend pas remplacer ces architectures ; il offre un point de départ radicalement simplifié pour les cas d'usage où le serveur n'est pas indispensable, et un modèle mental pour minimiser les secrets même lorsqu'un serveur reste nécessaire.

Même en poussant l'approche zero-secret au maximum, il restera presque toujours un ou deux secrets inévitables. Dans le cas Pillar, le webhook secret de Stripe est l'exemple type : il faut bien que quelqu'un vérifie la signature des notifications de paiement entrantes pour confirmer qu'elles viennent réellement de Stripe et pas d'un attaquant. La discipline consiste alors à donner à ce secret le périmètre le plus restreint possible.

Concrètement, Pillar isole ce secret dans un Cloudflare Worker dédié à cette seule fonction. Le Worker est déployé via wrangler deploy et le secret est injecté via wrangler secret put STRIPE_WEBHOOK_SECRET ; il ne quitte jamais l'infrastructure Cloudflare et n'apparaît dans aucun fichier versé au repo. Le Worker n'a aucune autre responsabilité que de vérifier la signature et d'enregistrer l'événement ; il n'a pas accès au reste du système. Si le secret fuit, l'attaquant ne peut que falsifier des webhooks Stripe sur ce point d'entrée : il ne peut pas pivoter vers une base de données, vers une clé de paiement, vers le DNS.

La rotation est planifiée trimestriellement : on régénère le webhook secret depuis le Dashboard Stripe, on met à jour la variable d'environnement du Worker, et on documente la date dans un journal d'opérations. Cette discipline ne supprime pas le risque, mais elle le borne et le rend audible.