Durcissement avant le lancement

“La checklist pré-vol existe parce que la mémoire faillit et que le coût de l'oubli est l'avion tout entier.”

La checklist pré-lancement

Avant le lancement, parcourez ceci une fois, délibérément, comme le ferait un attaquant. C'est tout le cours sous forme de liste. Si vous ne faites rien d'autre, faites ceci :

• Accès aux données : chaque table a Row-Level Security avec une vraie politique ; un second utilisateur et une requête anonyme sont tous deux bloqués (ch. 2).
• Secrets : aucune clé secrète dans le bundle client ni dans git ; tout ce qui a fuité a été tourné ; les clés vivent côté serveur (ch. 3).
• Autorisation : chaque endpoint portant un id vérifie la propriété sur le serveur ; vous avez essayé de changer un id et avez été refusé (ch. 4).
• Surface exposée : endpoints inventoriés, routes mortes supprimées, CORS verrouillé sur vos origines, limites de débit sur l'auth et les routes coûteuses (ch. 5).
• Webhooks : chaque webhook entrant vérifie sa signature et rejette un appel non signé (ch. 5).

Configurez les en-têtes que l'outil a sautés

Les en-têtes de sécurité sont quelques lignes de configuration qui activent des protections au niveau du navigateur, et les outils IA ne les ajoutent presque jamais parce que rien ne casse sans eux. C'est une assurance peu coûteuse contre des classes entières d'attaques :

• Content-Security-Policy : restreint quels scripts et ressources peuvent se charger, émoussant le cross-site scripting. Le plus rentable et le plus délicat à bien régler.
• Strict-Transport-Security (HSTS) : force HTTPS pour qu'un utilisateur ne puisse pas être rétrogradé vers une connexion interceptable.
• X-Content-Type-Options: nosniff et X-Frame-Options / frame-ancestors arrêtent les astuces de type de contenu et le clickjacking par intégration.
• Et le socle sous tous ceux-là : servez tout en HTTPS, sans contenu mixte.

Une Content-Security-Policy raisonnable est celle dans laquelle investir vraiment : c'est la différence entre un script égaré rendu inerte et ce même script s'exécutant avec les sessions de vos utilisateurs. Commencez en mode rapport seul pour voir ce qu'elle bloquerait avant de l'appliquer. Ce qu'un scan automatisé attrape, et ce qu'il ne peut pas attraper.↗

Vos dépendances font partie de votre surface d'attaque

Un outil IA ajoute des packages librement, et chaque dépendance est du code auquel vous faites confiance et que vous livrez. L'écosystème IA/JS, qui évolue vite, est un terrain fertile pour les vulnérabilités connues, les typosquats et les bibliothèques abandonnées. L'hygiène est standard et mérite d'être automatisée : auditez ce dont vous dépendez, épinglez les versions et corrigez les problèmes connus avant qu'ils ne soient exploités.

• Exécutez un scan de vulnérabilités (npm audit, ou un outil comme Dependabot/Snyk) et corrigez les critiques avant le lancement.
• Épinglez les versions pour qu'une dépendance ne puisse pas changer sous vos pieds, et examinez ce qu'est réellement un nouveau package avant de l'ajouter.
• Gardez l'habitude de mettre à jour ; une dépendance non maintenue est une vulnérabilité au ralenti.

Erreurs et logs : ne racontez pas les entrailles

Les apps construites par IA adorent renvoyer l'erreur brute à l'écran : traces de pile, messages SQL, chemins de fichiers. Chacun est une carte gratuite de vos entrailles pour un attaquant. Montrez aux utilisateurs un message générique ; loguez le détail côté serveur, où vous seul pouvez le lire. Et pendant que vous y êtes, assurez-vous de loguer assez pour remarquer une attaque : connexions échouées, refus d'autorisation, déclenchements de limite de débit.

Quand faire appel à de l'aide

Ce cours rend les trous graves et courants détectables par la personne qui a construit l'app, et pour beaucoup de projets, exécuter la checklist honnêtement suffit à lancer de manière responsable. Mais plus vous manipulez de choses (vrais paiements, données de santé ou financières, informations sensibles d'autrui), plus le coût du trou auquel vous n'avez pas pensé est élevé, et plus il vaut la peine de faire réviser l'app par quelqu'un dont le métier à plein temps est de trouver ces trous.

C'est le travail de SDEN : durcir et réviser les applications construites par IA contre exactement ces modes de défaillance, avec le cadrage SOC 2 / CCPA / PIPEDA que les clients nord-américains attendent. Si vous avez construit quelque chose avec l'IA et que vous vous apprêtez à y placer les données de vrais utilisateurs, une revue de sécurité avant le lancement coûte bien moins cher que l'incident après. Associez ce cours au cours AI Security pour les menaces propres aux modèles, et vous aurez le tableau complet.