Étape 5 · Mettre en ligne

/pulse:security

Sécurité du projet : audit complet S1 à S13 et test du cambrioleur, contrôle rapide, en-têtes de sécurité, préparation d'un audit outillé.

    Description

    Cette commande vérifie que votre appli est bien protégée. L'audit complet passe tout le projet au crible de la liste de sécurité Pulse, en 13 points (S1 à S13) : les clés secrètes, l'accès aux données, les pages réservées, les saisies, les fichiers déposés, les bibliothèques, les données personnelles, les abus, les messages d'erreur, les protections du navigateur et les sessions. Un assistant spécialisé fait ce travail en lecture seule : vos fichiers restent intacts.

    Vient ensuite le test du cambrioleur : une liste de tests à faire vous-même, adaptée à votre appli, un test à la fois. Par exemple : connectée comme une cliente, puis-je voir les rendez-vous d'une autre ? La règle à retenir : « Seul ce que le serveur bloque est vraiment interdit. » Pulse propose enfin de corriger, par ordre de priorité.

    🛡️ Contrôle rapide – carnet-reservations
    Score : 7/10
    
      Dépendances            ✅
      Fichiers sensibles     ✅
      Secrets dans le code   ✅
      Validation des saisies ⚠️ formulaire de réservation
      En-têtes de sécurité   ⚠️ 2 en-têtes manquants
      Connexion et droits    ✅
      Limitation des appels  ⚠️ envoi d'e-mail sans limite

    Le résultat de /pulse:security rapide : un aperçu en 2 minutes, sans rien modifier.

    Pourquoi l'utiliser

    • Vous trouvez les failles avant les autres. C'est exactement le but : chaque point bloquant est expliqué en une phrase, avec ce qu'un inconnu pourrait faire.
    • Vous vérifiez par vous-même. Le test du cambrioleur vous fait essayer, dans votre appli, ce qu'un visiteur malintentionné tenterait.
    • Un bilan rapide à tout moment. rapide répond en 2 minutes à « suis-je dans les clous ? ».
    • Les protections du navigateur sont posées pour vous. entetes écrit la configuration, commentée en français, après vous l'avoir montrée.

    Quand l'utiliser

    1. 1 Démarrer
    2. 2 Décrire
    3. 3 Préparer
    4. 4 Construire
    5. 5 Mettre en ligne
    6. 6 Être trouvé
    7. 7 À tout moment
    • Avant une mise en ligne, à la fin de la première version ou d'un groupe de user stories : l'audit complet.
    • Juste après la première mise en ligne : /pulse:deploy vous le propose, car le site est désormais ouvert à tous.
    • À tout moment, pour un aperçu : /pulse:security rapide. /pulse:deploy le lance aussi avant la première mise en ligne.
    • Quand des en-têtes manquent, ou avant de confier le projet à un développeur pour un audit plus poussé.

    Comment la lancer

    /pulse:security [audit | rapide | entetes | preparer]

    Entre crochets [ ] : facultatif. Entre chevrons < > : à remplacer par votre valeur. La barre | sépare les choix possibles. Par défaut : audit.

    • audit (par défaut) : l'audit complet en 13 points, enregistré dans docs/securite.md, puis le test du cambrioleur et les corrections.
    • rapide : 7 contrôles en 2 minutes, en lecture seule, avec un score sur 10. Rien n'est écrit.
    • entetes : les en-têtes de sécurité, des consignes envoyées au navigateur avec chaque page (« n'affiche pas ce site dans un cadre », « charge les scripts seulement depuis ces adresses »). Pulse repère les services que votre appli utilise, puis montre la configuration avant de l'écrire.
    • preparer : deux fichiers pour un audit outillé : la liste des points d'entrée de votre appli et la configuration d'un outil qui cherche les clés dans tout l'historique Git.
    /pulse:security
    /pulse:security rapide
    /pulse:security entetes

    Ce qu'elle produit

    FichierActionÀ quoi il sert
    docs/securite.mdauditLe niveau global (🟢, 🟠 ou 🔴), les 13 points avec constat et correction, la fiche du cambrioleur avec vos résultats, le plan de correction. Il remplace l'audit précédent, gardé dans l'historique Git.
    La configuration des en-têtes (serveur, hébergeur ou framework)entetesLes 7 en-têtes attendus, un commentaire en français au-dessus de chacun.
    endpoints.txtpreparerLes points d'entrée réellement trouvés, avec des valeurs de test fictives.
    .gitleaks.toml (ou l'équivalent)preparerLa configuration de la recherche de clés dans l'historique, si l'outil est disponible.

    rapide affiche son rapport sans écrire de fichier.

    Risques et précautions

    • L'audit et le contrôle rapide ne modifient rien. Ils lisent seulement.
    • Chaque correction attend votre choix : les points bloquants maintenant, tout corriger, ou plus tard. Une mise à jour qui change de version majeure d'une bibliothèque se fait seulement avec votre accord : elle peut casser l'appli.
    • Une clé trouvée dans le code passe en premier, avec /pulse:secrets fuite : révocation chez le fournisseur d'abord, puis remplacement, sans que la valeur passe par la conversation.
    • Certaines corrections se font à la main, dans la base ou chez un fournisseur : Pulse vous guide pas à pas, d'après la documentation officielle.

    Problèmes et solutions

    « L'audit attendra les premiers fichiers de code »

    Le projet ne contient pas encore de code à vérifier. Réalisez une première tâche avec /pulse:implement, puis relancez l'audit.

    Un test du cambrioleur me paraît trop technique

    Répondez « J'ai besoin d'aide pour ce test » : Pulse vous le décrit pas à pas. Les tests se font un à la fois, et chaque résultat est noté dans docs/securite.md.

    Après entetes, une partie de la page ne s'affiche plus

    Ouvrez la console du navigateur (touche F12) : une erreur « Content Security Policy » nomme la source bloquée. Pulse ajoute précisément cette source légitime à la liste autorisée, jamais un passe-partout.

    L'audit signale une clé dans le code ou dans l'historique

    Traitez-la en premier avec /pulse:secrets fuite. Une clé passée un jour dans Git reste lisible dans l'historique : seule la révocation la rend inutile.

    L'outil de recherche de clés n'est pas installé

    preparer écrit quand même sa configuration. En attendant, le contrôle de Pulse couvre les fichiers actuels, sans l'historique.

    Exemples

    /pulse:security

    L'audit se fait en lecture seule : vos fichiers restent intacts.

    pulse-aidd secrets historique · pulse-aidd secrets inventaire --sans-hebergeur

    Niveau global : 🟠 À améliorer · 1 point bloquant. ⛔ S3 Contrôle d'accès : une cliente connectée peut ouvrir le rendez-vous d'une autre en changeant le numéro dans l'adresse. Correction proposée : vérifier côté serveur que le rendez-vous lui appartient. Faisons le test du cambrioleur ensemble, un test à la fois. Test 1 : connectez-vous avec le compte de test « Léa », ouvrez un de ses rendez-vous, puis remplacez le numéro à la fin de l'adresse par celui d'un rendez-vous de « Sam ».

    Faille ❌

    C'est noté dans docs/securite.md. Corriger les points bloquants maintenant ? (Recommandé) · Tout corriger · Plus tard

    /pulse:security entetes

    Voici les services que votre appli utilise : une police de caractères et le service d'envoi d'e-mails. Ils seront autorisés, tout le reste sera bloqué. Voici la configuration, un commentaire en français au-dessus de chaque en-tête. Je l'écris ?

    Oui.

    pulse-aidd sonder http://localhost:3000 --entetes

    🛡️ En-têtes : ✅ les 7 sont envoyés. Parcourez maintenant vos écrans avec la console ouverte (F12) : elle doit rester sans erreur « Content Security Policy ».

    Commandes liées