Audit de Pré-lancement

Que fait Audit de Pré-lancement ?

Auditez une application pour éviter qu'elle ne soit piratée ou poursuivie. Le travail est divisé en quatre fichiers de référence — lisez uniquement ceux (et les sections) qui s'appliquent à la pile que vous avez sous les yeux :

Fichier	À utiliser pour
references/prelaunch-checklist.md	Le feu vert/rouge en 20 points. Commencez ici pour une vérification rapide.
references/security.md	Revue de sécurité complète : secrets, auth, contrôle d'accès, injection, navigateur/transport, chaîne d'approvisionnement, fonctionnalités IA, opérations.
references/legal-compliance.md	Politiques, consentement, droits à la vie privée, marketing honnête, enfants, e-mail, propriété intellectuelle, accessibilité.
references/stack-notes.md	Pièges spécifiques à la plateforme : Supabase, Firebase, Next.js, Express, Django, Rails, Laravel, mobile, Stripe, applications LLM.

Chaque élément de la checklist a un ID (SEC-*, LEG-*, A11Y-*). Utilisez ces ID dans le rapport pour que les résultats soient traçables.

Choisir le mode

• Rapide ("checklist de lancement", "suis-je prêt à lancer ?", peu de temps) → prelaunch-checklist.md uniquement.
• Sécurité ("audit de sécurité", "éviter de se faire pirater", "est-ce sécurisé ?") → security.md + sections pertinentes de stack-notes.md.
• Juridique ("éviter de se faire poursuivre", "RGPD", "bannière de cookies", "politique de confidentialité") → legal-compliance.md.
• Complet (par défaut lorsque l'utilisateur dit simplement "audite mon application" avant le lancement) → tout ce qui précède.

Flux de travail

1. Périmètre — en grande partie automatique

Déterminez ces éléments à partir du dépôt avant de poser des questions :

• Pile : framework, langage, backend/BaaS (Supabase, Firebase, serveur propre), base de données, fournisseur d'auth, hébergement, web vs mobile vs les deux. Regardez package.json, lockfiles, requirements.txt/pyproject.toml, Gemfile, composer.json, pubspec.yaml, supabase/, firebase.json, vercel.json, Dockerfile, fichiers CI.
• Inventaire des données : quelles données personnelles sont collectées (formulaires, champs d'inscription, analytics), où elles sont stockées, quels SDK/services tiers les reçoivent (analytics, publicités, rapports de crash, paiements, e-mail, API IA).
• Argent : paiements, abonnements, essais, achats intégrés.
• Surface : pages publiques, routes API, actions serveur, fonctions edge/cloud, webhooks, zones d'administration, téléversements de fichiers, fonctionnalités IA/LLM.

Puis demandez à l'utilisateur — en un seul message, uniquement pour ce que le code ne peut pas vous dire : marchés cibles (UE/UK/US/Brésil/autre), si des mineurs peuvent l'utiliser, l'URL en direct ou de staging (si elle existe), et s'il veut des correctifs appliqués ou seulement un rapport.

Si l'utilisateur n'est pas disponible, supposez UE + US, adultes uniquement, rapport en premier, et précisez-le en haut du rapport.

2. Passage automatisé

python3 scripts/scan.py <chemin-du-depot>              # arbre de travail
python3 scripts/scan.py <chemin-du-depot> --history    # scanne aussi l'historique git pour les secrets
python3 scripts/check_live.py https://staging.example.com   # en-têtes en direct, cookies, CORS, fichiers exposés

Les deux scripts utilisent uniquement la bibliothèque standard Python 3. check_live.py envoie quelques requêtes GET inoffensives — exécutez-le uniquement contre des sites que l'utilisateur possède ou est autorisé à tester.

Exécutez également l'auditeur de dépendances de l'écosystème lorsqu'il est disponible (npm audit, pnpm audit, pip-audit, osv-scanner, bundle audit, composer audit, cargo audit) ; scan.py affiche les commandes appropriées pour les manifestes qu'il trouve.

Considérez la sortie du script comme des pistes, pas des verdicts. Confirmez chaque résultat en lisant le code ; supprimez les faux positifs. Un scan propre ne signifie pas sûr : les bugs les plus dommageables (contrôle d'accès défaillant, vérifications côté serveur manquantes, fuites entre locataires) sont des bugs de logique que seule la lecture permet de trouver.

3. Revue manuelle

Lisez, dans cet ordre :

1. Configuration de l'auth et middleware ; comment le serveur sait qui est l'appelant.
2. Chaque route API, action serveur, fonction edge/cloud et gestionnaire de webhook.
3. Règles d'accès à la base de données : politiques RLS, règles Firebase, portées ORM, privilèges des utilisateurs de la base.
4. Tout ce qui construit du SQL, des commandes shell, du HTML, des chemins de fichiers ou des URLs à partir d'une entrée.
5. Gestionnaires de téléversement et de téléchargement de fichiers.
6. Fonctionnalités IA/LLM : quel texte non fiable atteint le modèle et quels outils le modèle peut appeler.
7. Pages juridiques, bannière de cookies, flux d'inscription et de paiement, contenu marketing, e-mails.

Pour chaque point de terminaison, répondez à quatre questions : Qui appelle ? Est-ce vérifié sur le serveur ? L'enregistrement est-il le leur (ou celui de leur locataire) ? Quels champs peuvent-ils écrire ? Un "non" ou "je ne sais pas" est un résultat.

4. Classifier

Statut par élément : FAIL · WARN · PASS · MANUAL (nécessite un humain : révision de texte juridique, exercice de restauration, avocat) · N/A. Ne marquez jamais PASS pour quelque chose que vous n'avez pas réellement vérifié — utilisez MANUAL.

Gravité des échecs :

• Critique — exploitable maintenant ou déjà exposé : secret en direct dans le dépôt/bundle/historique, base de données lisible ou modifiable sans auth, RLS désactivée sur une table avec des données utilisateur, contournement d'auth, IDOR sur des données personnelles, injection SQL/commande, RCE.
• Élevée — sérieux avec une petite précondition : limitation de débit manquante sur la connexion/réinitialisation, XSS stocké, vérification de signature de webhook manquante, hachage de mot de passe faible, CORS permissif avec identifiants, mode débogage activé en production, pas de sauvegardes. Juridique : une exigence forte pour un marché déclaré qui est absente (pas de politique de confidentialité alors que des données personnelles sont collectées ; suivi non essentiel avant consentement dans l'UE/UK ; pas de suppression de compte dans une application de l'App Store).
• Moyenne — lacunes de défense en profondeur : en-têtes de sécurité manquants, messages d'erreur verbeux, pas de journal d'audit, dépendances obsolètes non exploitables. Juridique : contenu de politique incomplet, problèmes d'UX de consentement, échecs d'accessibilité.
• Faible — hygiène et polissage.

5. Rapport

Remplissez templates/report.md. Commencez par le verdict :

• 🔴 Pas prêt — tout élément Critique, ou Élevé qui touche aux données personnelles ou à l'argent.
• 🟡 Prêt avec correctifs — Élevés/Moyens avec un plan pour corriger cette semaine.
• 🟢 Prêt — aucun Critique/Élevé ; Moyens suivis.

Chaque résultat : ID, gravité, preuve (fichier:ligne ou URL + en-tête), une ligne sur le risque, un correctif concret (du code quand il est court). Groupez par gravité, pas par ordre de checklist. Gardez les éléments PASS dans un tableau compact.

Ne collez jamais un secret complet dans le rapport ou le chat. Affichez les 4 premiers caractères et masquez le reste (sk_l****).

6. Corriger

Proposez de corriger par ordre de gravité. Modifiez le code uniquement si l'utilisateur a demandé des correctifs ou accepte. Après correction, réexécutez scan.py (et check_live.py après le déploiement) et mettez à jour le rapport.

Secret divulgué, toujours dans cet ordre : révoquer/faire tourner la clé chez le fournisseur → la supprimer du code et la déplacer dans des variables d'environnement côté serveur → la purger de l'historique git (git filter-repo ou BFG) et forcer le push. Purger seul ne sert à rien : la clé est déjà dans les clones, forks, journaux CI et caches.

Règles de base

• Pas de conseils juridiques. Vous pouvez rédiger des politiques de confidentialité, conditions d'utilisation, politiques de cookies et de remboursement, mais un projet doit décrire ce que l'application fait réellement (les données, SDK et processeurs trouvés dans les étapes 1 à 3), ne doit pas être copié d'une autre entreprise, et doit être signalé pour révision par un avocat pour les marchés cibles.
• Uniquement défensif. Testez uniquement les systèmes que l'utilisateur possède ou est autorisé à tester. Expliquez les vulnérabilités et les correctifs ; ne construisez pas d'exploits fonctionnels contre des tiers.
• Pas de code source, seulement une URL ? Exécutez check_live.py, inspectez le site (liens juridiques en pied de page ; si les traceurs se déclenchent avant le consentement ; si "Refuser" est aussi facile que "Accepter" ; formulaires et paiement), et marquez les éléments de code comme MANUAL.
• Applications mobiles : tout ce qui est livré dans le binaire de l'application est public. Les secrets dans une application mobile sont des secrets divulgués.
• Préférez les correctifs natifs de la plateforme (politiques RLS, middleware du framework, paramètres du fournisseur) plutôt que des solutions faites maison.