Prompts & workflows prêts à l'emploi.

Des prompts et des workflows IA conçus et testés par Mosagix — certains gratuits, d'autres sur demande.

SCAN_360 — Audit de sécurité ultra-complet pour l'ère des agents IA

# SCAN360 — Audit de sécurité ultra-complet pour l'ère des agents IA > **Un scan d'intrusion en boîte blanche, méthodique et sans angle mort.** > Donnez le kit à un agent IA : il cartographie votre app, cherche les failles > sur **tous** les fronts, et produit un rapport actionnable `SCAN360REPORT.md`. --- ## Pourquoi SCAN360 existe Aujourd'hui, le vibe coding et les agents IA (Cursor, Claude Code, Copilot, générateurs d'apps…) permettent de sortir une application en production en quelques heures. C'est puissant. C'est aussi dangereux. On constate de plus en plus : | Symptôme | Conséquence | |---|---| | Applications exposées trop tôt | Surface d'attaque publique non revue | | Clés API / secrets laissés dans le code | Compromission cloud, facturation abusive, vol de données | | Auth « qui marche en local » | IDOR, comptes admin ouverts, JWT faibles | | Failles oubliées (XSS, SSRF, CSRF, deep links…) | Exploitation silencieuse après release | | Config permissive générée par défaut | CORS *, debug on, webhooks non signés | | Dépendances tirées vite | CVE, supply chain, typosquatting | Les outils classiques (linters, npm audit seul, checklist mentale) ne suffisent pas : ils ratent la logique métier, les chaînes d'attaque, le mobile, la CI, et les artefacts typiques du code généré. SCAN_360 est conçu pour combler ce vide : un chef-d'œuvre de revue d'intrusion en boîte blanche, découpé en modules experts, exécutable par un agent IA sur n'importe quel dépôt. --- ## Ce que c'est Un kit de prompts Markdown (scann_360/) qui transforme un agent de code en équipe AppSec / red team en lecture seule : 1. Détecte automatiquement la stack (web, API, mobile, devops…). 2. Parcourt 13 domaines de risques — rien n'est laissé au hasard. 3. Prouve chaque faille dans le code (fichier:ligne + extrait). 4. Corréle les findings en chaînes d'attaque. 5. Livre un unique rapport : `SCAN_360_REPORT.md`. Il ne modifie pas votre application. Il documente. Vous gardez le contrôle des correctifs. --- ## Ce qu'il couvre (360°) | Module | Domaine | Exemples de risques | |---|---|---| | 01 | Cartographie | Stack, surface d'attaque, données sensibles | | 02 | Secrets | Clés API, .env commités, tokens, credentials cloud | | 03 | Auth & accès | Sessions, JWT, IDOR, élévation de privilèges | | 04 | Injections | SQL/NoSQL, XSS, SSTI, RCE, upload, XXE | | 05 | API | BOLA, mass assignment, webhooks, GraphQL, SSRF | | 06 | Web | CSRF, CORS, headers, debug, open redirect | | 07 | Mobile | Stockage, TLS, deep links, WebViews, secrets client | | 08 | Données & crypto | PII, hash faibles, privacy, isolation tenant | | 09 | Logique métier | Prix client, skip paiement, races, abus de quotas | | 10 | Supply chain | CVE, lockfiles, CDN, dependency confusion | | 11 | CI/CD & cloud | Secrets CI, Docker root, buckets publics, IAM | | 12 | Runtime | Logs sensibles, metrics ouvertes, cache cross-user | | 13 | Ère IA | Artefacts vibe coding, agents LLM, prompt injection | Référentiels : OWASP Top 10, OWASP API Security Top 10, OWASP MASVS / Mobile Top 10, principes ASVS et défense en profondeur. --- ## Pourquoi l'utiliser ### 1. Ne rien oublier Une checklist humaine fatigue. Un agent sans méthode tourne en rond. SCAN360 impose une **couverture modulaire exhaustive** + une matrice de couverture dans le rapport : chaque domaine est ✅ traité ou ➖ N/A justifié. ### 2. Pensé pour le code généré par IA Le module **13 — AI Era** cible spécifiquement les patterns du vibe coding : TODOs sécurité, stubs d'auth, secrets « pour tester », CRUD sans ownership, outils d'agents trop puissants, clés LLM côté client. ### 3. Preuves, pas d'opinions Pas de « probablement vulnérable ». Chaque finding a une **preuve dans le code**, un scénario d'exploitation, un correctif recommandé, une gravité justifiée. ### 4. Chaînes d'attaque Une faille moyenne + un secret exposé = parfois un **critique combiné**. SCAN360 corréle au lieu de lister des tickets isolés. ### 5. Rapport prêt à publier en interne Résumé exécutif pour le décideur, détail technique pour le développeur, feuille de route priorisée (bloquant prod → durcissement). ### 6. Ultra-moderne, multi-stack Web, API, mobile, serverless, Docker, GitHub Actions, apps AI-powered — le même kit s'adapte à ce qu'il détecte dans le dépôt. ### 7. Accélérateur avant un vrai pentest Ce n'est pas une certification. C'est le filtre qui évite d'envoyer en audit payant une app encore pleine de clés en clair et d'IDOR évidents. --- ## Comment ça fonctionne ``text Votre dépôt │ ▼ 00_SCAN_360.md ──► charge la méthode + tous les modules │ ├─ Phase 1 Cartographie (01) ├─ Phase 2 Scan domaines (02 → 13) ├─ Phase 3 Corrélation des chaînes d'attaque └─ Phase 4 Écriture de SCAN_360_REPORT.md ` ### Lancement rapide (one-shot) Placez le dossier scann360/` dans votre projet (ou indiquez son chemin), puis : ```bash claude -p "$(cat scann360/00MASTER/00SCAN360.md)" ``` Équivalent avec d'autres agents : ouvrez le dépôt et fournissez le fichier `00MASTER/00SCAN360.md comme prompt principal. L'agent doit **lire les modules** référencés avant de scanner. ### Mode modulaire (optionnel) Pour un focus ciblé (ex. secrets seulement), vous pouvez aussi lancer un module isolé — mais le **mode recommandé** reste le one-shot via 00SCAN360.md pour garantir la couverture 360°. --- ## Arborescence du kit `text scann_360/ ├── README.md ← vous êtes ici ├── 00_MASTER/ │ ├── 00_SCAN_360.md ← point d'entrée (lancer celui-ci) │ ├── 01_METHODE.md ← règles, gravité, principes │ └── 02_FORMAT_RAPPORT.md ← structure exacte du rapport ├── 01_RECON/ 01_CARTOGRAPHIE_SURFACE.md ├── 02_SECRETS/ 02_SECRETS_CLES_EXPOSEES.md ├── 03_AUTHZ/ 03_AUTH_SESSION_AUTORISATION.md ├── 04_INJECTION/ 04_INJECTIONS_ET_XSS.md ├── 05_API/ 05_SECURITE_API.md ├── 06_WEB/ 06_WEB_CONFIG_CSRF_HEADERS.md ├── 07_MOBILE/ 07_MOBILE_CLIENT.md ├── 08_DATA/ 08_DONNEES_CRYPTO_RGPD.md ├── 09_BUSINESS/ 09_LOGIQUE_METIER_ABUS.md ├── 10_SUPPLY/ 10_DEPENDANCES_SUPPLY_CHAIN.md ├── 11_DEVOPS/ 11_CICD_DOCKER_CLOUD.md ├── 12_RUNTIME/ 12_LOGGING_MONITORING_FUITES.md └── 13_AI_ERA/ 13_VIBE_CODING_AGENTS_IA.md ` --- ## Livrable Fichier généré : **SCAN360REPORT.md** Contient notamment : - résumé exécutif + verdict publication ; - tableau de bord par gravité (Critique → Info) ; - top risques + chaînes d'attaque ; - détail de chaque faille (preuve, scénario, correctif) ; - matrice de couverture des 13 modules ; - incertitudes & contrôles hors-repo à confirmer ; - feuille de route priorisée. --- ## Règles d'or pour l'utilisateur 1. **Lecture seule** — le scan ne doit pas « corriger » pendant l'audit ; relisez d'abord le rapport. 2. **Masquez les vrais secrets** si vous recopiez le rapport (le prompt le demande déjà à l'agent). 3. **Tounez immédiatement** tout secret trouvé exposé — le retirer du code ne suffit pas. 4. **Relisez les findings critiques** avant de publier sur un store ou Internet. 5. **Enjeu finance / santé / paiement** → enchaînez avec un pentest humain autorisé. --- ## Ce que SCAN_360 n'est pas - Pas une certification OWASP / ISO / SOC2 - Pas un pentest dynamique runtime (instrumentation appareil, fuzzing réseau externe) - Pas une autorisation à attaquer des systèmes tiers - Pas un substitut à une revue humaine sur les apps critiques C'est un **accélérateur d'expertise** : la méthode d'un pentester senior, packagée pour un agent IA, pour que plus aucune app « vibe-codée » ne parte en prod sans avoir été regardée en face. --- ## En une phrase > **SCAN_360 transforme « ça marche » en « on sait exactement ce qui est exposé, > ce qui est dangereux, et quoi corriger avant que quelqu'un d'autre ne le trouve ».** --- ## Démarrer maintenant 1. Copiez scann360/` à la racine de votre projet. 2. Lancez `00MASTER/00SCAN360.md avec votre agent. 3. Ouvrez SCAN360REPORT.md`. 4. Corrigez dans l'ordre : 🔴 → 🟠 → 🟡 → durcissement. 5. Relancez un scan pour mesurer le delta. Bonne chasse. 🛰️

PromptSecuritè

Audit de sécurité (pentester mobile expert, boîte blanche)

# Pourquoi auditer la sécurité de votre application mobile avant de la publier > Une app mobile n’est pas un serveur protégé derrière un firewall. > C’est un binaire livré dans la poche de l’utilisateur — et donc potentiellement dans celle d’un attaquant. Ce guide explique pourquoi la sécurité mobile est critique, ce que couvre le prompt `AUDIT-MOBILE`, et pourquoi l’utiliser avant de mettre votre application sur les stores. --- ## Le problème que personne ne voit assez tôt Beaucoup d’applications mobiles « marchent » en démo : login, sync, paiement, push… Pourtant, dès qu’elles quittent votre machine de développement, elles vivent dans un environnement hostile : | Réalité terrain | Conséquence | |---|---| | L’utilisateur (ou l’attaquant) possède le téléphone | Il peut rooter, jailbreaker, instrumenter l’app | | Le binaire est public (APK / IPA) | Il peut être décompilé, analysé, patché | | Le trafic peut être intercepté | Tokens et données transitent sous le nez de l’attaquant | | Les deep links / WebViews ouvrent des portes | Une URL mal formée peut déclencher une action sensible | | Les secrets dans le client ne sont jamais secrets | Une clé API « cachée » dans le code finit sur GitHub ou dans un dump | Règle d’or : rien dans le client n’est secret. Toute règle métier critique (droits, paiements, données) doit être imposée côté serveur. Les protections locales (obfuscation, anti-root) ne sont que de la défense en profondeur. Ignorer ça, c’est publier avec un faux sentiment de sécurité. --- ## Pourquoi c’est important (concrètement) Une faille mobile ne se limite pas à un « bug UX ». Elle peut entraîner : 1. Vol de comptes — tokens stockés en clair, auth décidée côté app, biométrie décorative. 2. Fuite de données personnelles — PII dans SharedPreferences / UserDefaults, logs, backups, notifications. 3. Interception réseau (MITM) — HTTP clair, validation TLS désactivée, pinning absent sur une app à fort enjeu. 4. Abus via deep links / WebViews — contournement d’auth, phishing intégré, pont JS ↔ natif trop permissif. 5. Extraction de secrets — clés API, tokens, clés privées embarqués dans le binaire. 6. Surface plateforme élargie — composants Android exportés, permissions excessives, intents détournables. 7. Conformité & confiance — RGPD, exigences stores, image de marque : une faille publique coûte plus cher qu’un audit anticipé. Pour une app finance, santé, identité ou paiement, ne pas auditer avant publication n’est plus une option raisonnable. --- ## Ce que fait AUDIT-MOBILE AUDIT-MOBILE est un prompt d’audit en boîte blanche conçu pour un agent de code (Claude Code, Cursor, etc.). Vous le donnez à la racine de votre projet mobile. L’agent joue un pentester mobile senior et : 1. Cartographie l’app (plateforme, architecture, backend, données sensibles, points d’entrée). 2. Parcourt méthodiquement le code selon 10 familles de risques (alignées OWASP MASVS / Mobile Top 10). 3. Documente chaque faille prouvable : gravité, extrait de code, scénario d’exploitation, correctif. 4. Produit un seul rapport : audit.md — clair, priorisé, actionnable. Important : il n’audite qu’en lecture seule. Il ne modifie pas votre code. Il documente. ### Les 10 familles couvertes | ID | Famille | Exemple de risque | |---|---|---| | M1 | Stockage local non sécurisé | Tokens / PII en clair sur l’appareil | | M2 | Communication réseau | HTTP clair, TLS désactivé, pas de pinning | | M3 | Authentification / autorisation | Droits décidés côté client | | M4 | Cryptographie faible | Clés en dur, MD5, ECB, IV réutilisé | | M5 | Secrets embarqués | Clés API / secrets dans le binaire | | M6 | Surface plateforme | Composants exportés, permissions excessives | | M7 | Deep links & WebViews | Liens non validés, pont JS dangereux | | M8 | Résilience / reverse | App débogable, pas d’obfuscation | | M9 | Fuites à l’exécution | Logs sensibles, captures d’écran, notifications | | M10 | Qualité & SDK tiers | Dépendances CVE, SDK trop gourmands | Chaque finding est classé sur une échelle Critique → Info, avec justification (impact × exploitabilité). --- ## Pourquoi l’utiliser (et pas « juste checker à la main ») ### 1. Méthode, pas intuition Sans grille, on regarde ce qu’on connaît déjà (auth, un peu de TLS) et on oublie le reste : backups, presse-papiers, PendingIntent, pont WebView, permissions de SDK… AUDIT-MOBILE force un parcours exhaustif M1–M10. ### 2. Preuves dans le code, pas des avis vagues Chaque faille doit être prouvée (fichier:ligne + extrait). Pas de « probablement vulnérable ». Les doutes vont dans une section dédiée (« à vérifier manuellement »). ### 3. Pensé pour le mobile réel Android, iOS, Flutter, React Native : le prompt s’adapte à la techno détectée, avec les motifs dangereux typiques de chaque plateforme. ### 4. Rapport prêt pour l’équipe Le livrable audit.md contient : - un résumé exécutif compréhensible par un non-technicien ; - un tableau de bord par gravité ; - le détail de chaque faille (preuve, scénario, correctif) ; - les contrôles serveur à confirmer (parce que le client seul ne suffit jamais) ; - une feuille de route priorisée (bloquant publication → durcissement). ### 5. Gain de temps avant un vrai pentest Ce n’est pas un substitut à un audit professionnel sur une app critique. C’est un filtre de maturité : vous corrigez l’évidence (secrets en dur, TLS cassé, tokens en clair) avant de payer un pentest — et vous arrivez mieux préparé. ### 6. Idéal pour le vibe coding / MVPs qui grandissent Vous avez généré l’app vite. Elle tourne. La question n’est plus « est-ce que ça marche ? », mais « est-ce que je peux la mettre entre les mains d’utilisateurs réels ? ». AUDIT-MOBILE répond à cette question avec un rapport structuré. --- ## Quand l’utiliser | Moment | Intérêt | |---|---| | Avant la première soumission store | Éviter de publier avec des failles bloquantes | | Avant une feature sensible (paiement, identité, santé) | Mesurer le nouveau risque | | Après un gros refactor / migration (RN → Flutter, etc.) | Les protections se perdent souvent en route | | Avant un audit / pentest payant | Nettoyer l’évidence, maximiser la valeur du pentest | | En revue périodique (trimestrielle) | Les SDK et dépendances dérivent vite | --- ## Comment l’utiliser (en 30 secondes) 1. Placez AUDIT-MOBILE.md à la racine de votre projet mobile. 2. Lancez votre agent de code avec le prompt entier, par exemple : ``bash claude -p "$(cat AUDIT-MOBILE.md)" ` 3. Lisez le fichier généré audit.md. 4. Traitez d’abord les **critiques** et **élevées**, puis le reste. 5. Relancez après corrections pour vérifier ce qui reste. **Rappel** : ne collez jamais de vrais secrets (clés, mots de passe) dans le chat. Le prompt demande déjà de masquer les valeurs exposées dans le rapport. --- ## Ce que ce prompt n’est pas Soyez lucides sur le périmètre : - Ce n’est **pas** une certification OWASP / ISO. - Ce n’est **pas** un pentest dynamique (runtime, binaire instrumenté, appareil rooté). - Ce n’est **pas** une garantie que le backend est sûr — le rapport liste justement ce qu’il faut **confirmer côté serveur**. - C’est un **accélérateur d’audit en boîte blanche** : rigoureux, prouvé par le code, orienté correction. Pour une app à fort enjeu (banque, santé, paiement), enchaînez ensuite avec un **pentest professionnel**. --- ## En une phrase > **AUDIT-MOBILE transforme « on a une app qui marche » en « on sait exactement ce qui est dangereux, pourquoi, et quoi corriger avant de publier ».** La sécurité mobile n’est pas un luxe de fin de projet. C’est la différence entre une app qui inspire confiance… et une app qui fuit ses utilisateurs au premier reverse engineering sérieux. --- ## Ressources associées - Prompt : [AUDIT-MOBILE.md](./AUDIT-MOBILE.md) - Référentiels : [OWASP MASVS](https://mas.owasp.org/MASVS/), [OWASP Mobile Top 10](https://owasp.org/www-project-mobile-top-10/) - Cousin web : [AUDIT-WEB.md`](./AUDIT-WEB.md) (même approche pour les apps web / API)

PromptApplication Web et Mobile

Prompts de sécurisation pour applications V2

# 🛡️ Prompts de sécurisation pour applications « vibe codées » Cette bibliothèque contient un ensemble de prompts prêts à l'emploi à donner à Claude Code (ou tout agent de code) pour auditer et corriger la sécurité d'une application web ou mobile après sa génération. L'idée : tu as vibe codé ton app, elle marche… mais elle n'a probablement aucune défense sérieuse. Tu fais passer ces prompts un par un, chacun couvre une grande classe de vulnérabilités, Claude Code audite puis corrige. --- ## 📁 Organisation `` secu-prompts-vibecoding/ ├── web/ → applications web (frontend + backend + API) ├── mobile/ → applications mobiles (Android / iOS / Flutter / React Native) └── divers/ → transversal : conformité, checklist pré-prod, secrets, etc. ` Chaque fichier .md **est** le prompt. Tu peux : - le **copier-coller** directement dans Claude Code, ou - le passer en entrée : claude -p "$(cat web/02-xss.md)", ou - l'utiliser comme fichier de contexte dans ton IDE. --- ## ✅ Ordre recommandé ### Web 1. 00-audit-global-web.md — cartographie et priorisation (à lancer en premier) 2. 04-authentification-session.md 3. 05-controle-acces-idor.md 4. 01-injections-sql-nosql-commande.md 5. 02-xss.md 6. 03-csrf.md 7. 10-securite-api-rate-limiting.md 8. 06-ssrf.md 9. 09-upload-fichiers.md 10. 07-headers-cors-securite.md 11. 08-donnees-sensibles-cryptographie.md 12. 11-configuration-secrets.md 13. 12-dependances-supply-chain.md 14. 13-logging-monitoring.md ### Mobile 1. 00-audit-global-mobile.md (en premier) 2. 04-secrets-cles-api.md 3. 01-stockage-local-securise.md 4. 02-communication-reseau-tls-pinning.md 5. 03-authentification-mobile.md 6. 07-deep-links-webview.md 7. 06-permissions-plateforme.md 8. 08-cryptographie-mobile.md 9. 05-anti-tampering-reverse.md ### Divers (transversal, quand tu veux) - prompt-divers-securite.md - logging-rgpd-conformite.md - checklist-avant-mise-en-prod.md` --- ## ⚠️ Règles d'usage importantes - Un prompt à la fois. Laisse Claude Code finir un domaine avant de passer au suivant, sinon les corrections se marchent dessus. - Fais un commit git avant chaque prompt. Tu pourras revenir en arrière. - Relis les diffs. Ces prompts sont des accélérateurs, pas une signature de conformité. Une correction de sécurité mal comprise peut casser une fonctionnalité. - Ne colle jamais de vrais secrets (clés API, mots de passe) dans le chat. - Ces prompts sont défensifs : ils servent à protéger ton application. Ils ne remplacent pas un audit professionnel / pentest avant une mise en production critique (banque, santé, paiement…). --- ## 🎯 Cadre de référence Les prompts s'appuient sur les référentiels reconnus : - OWASP Top 10 (web) - OWASP API Security Top 10 - OWASP MASVS / Mobile Top 10 (mobile) - OWASP ASVS (checklist de vérification) Bon durcissement 🔒

PromptApplication Web et Mobile

Claude Security Prompt Kit

# Claude Security Prompt Kit Pack de prompts Markdown destiné à Claude Code ou à un autre agent de codage chargé de durcir une application existante après développement. ## Arborescence - 00_MASTER/ : prompt maître + workflow. - 01_WEB/ : vulnérabilités web et logique métier. - 02_API/ : sécurité des API, JWT, GraphQL, webhooks et abus. - 03_MOBILE/ : Android, iOS, Flutter, React Native. - 04_SHARED/ : secrets, CI/CD, Docker, DB, dépendances et IaC. ## Utilisation recommandée Ouvre le dépôt de l’application avec Claude Code puis fournis d’abord : 00_MASTER/00_CLAUDE_SECURITY_MASTER.md Ensuite exécute les prompts spécialisés qui correspondent à la stack. Pour une application full-stack avec mobile, exécute les quatre familles. Le but n’est pas seulement de « scanner » le code. Les prompts demandent à l’agent de : 1. comprendre la stack ; 2. identifier la cause racine ; 3. prioriser ; 4. corriger le code ; 5. ajouter des tests de sécurité ; 6. produire SECURITY_AUDIT_REPORT.md. ## Référentiels couverts Le kit est conçu autour des grandes familles de risques OWASP : - OWASP Top 10 Web 2021 ; - OWASP API Security Top 10 2023 ; - OWASP Mobile Top 10 2024 ; - principes de défense en profondeur, sécurité CI/CD, supply chain, conteneurs et infrastructure-as-code. ## Important Ce kit aide au durcissement applicatif mais ne remplace pas : - une revue humaine de sécurité ; - un pentest autorisé ; - l’analyse de l’infrastructure réelle ; - une politique de gestion/rotation des secrets ; - un programme de patch management et de monitoring continu. Aucune protection ne doit dépendre uniquement du frontend, de l’obfuscation ou du fait qu’un identifiant soit difficile à deviner.