Vercel déploie ton appli avec un git push, et c'est merveilleux, mais chaque commodité cache une décision de sécurité que tu prends sans t'en rendre compte. Voici les points à surveiller quand tu lances là-bas.
Variables d'environnement et le préfixe public
Vercel distingue les variables serveur et client. Dans des frameworks comme Next.js, tout ce qui porte un préfixe public (par exemple NEXT_PUBLIC_) est intégré dans le bundle et voyage jusqu'au navigateur. N'y garde que ce que ça ne te dérange pas de montrer. Les clés privées vont sans préfixe et ne servent que sur le serveur. Un faux pas ici fait fuiter des jetons de façon permanente.
Les déploiements de preview sont publics
Chaque branche et chaque pull request génère une URL de preview. Par défaut, ces URL sont accessibles à quiconque les connaît, et elles pointent souvent vers de vraies données ou des clés d'environnements de test. Ne les traite pas comme privées : si ta preview se connecte à une base de données contenant des données sensibles, protège l'accès ou utilise de fausses données.
En-têtes de sécurité
Vercel sert du HTTPS d'office, mais il n'ajoute pas d'en-têtes défensifs à ta place. Configure dans ton projet Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options et une Content-Security-Policy. Sans eux, ton appli est plus exposée au clickjacking et à l'injection de scripts, même si le cadenas du navigateur paraît vert.
Des source maps qui révèlent ton code
Beaucoup de builds envoient des source maps en production. Ça permet à n'importe qui de reconstruire ton code d'origine depuis le navigateur, commentaires et structure interne compris. Parfois ça révèle des endpoints ou une logique que tu croyais cachés. Décide sciemment si tu veux les publier ; pour la plupart des applis, désactive-les en production.
Fichiers et endpoints qui ne devraient pas être là
Vérifie que .env, .git, les sauvegardes ou des manifestes comme package.json ne sont pas accessibles. Vérifie aussi les endpoints de debug ou les routes d'API sans authentification que tu as laissés pour tester et oublié d'enlever. Ce qui marche en local continue de marcher en production, pour toi comme pour n'importe qui.
Scanaris le vérifie en 30 secondes
Scanaris scanne ton déploiement Vercel de façon non intrusive : en-têtes HTTP, cookies, TLS, fichiers sensibles accessibles, secrets dans le JavaScript et CORS. Il ne lit que ce qui est déjà public, il n'attaque rien. Chaque trouvaille vient avec un prompt prêt à coller dans ton IA pour la corriger. Lance-le après chaque déploiement important et lance-toi l'esprit tranquille.