MonCashConnect
EN
Référentiel de sécurité•Version 1.0•Maintenu par MonCashConnect

SHIP-SAFE

La checklist de sécurité pour les applis créées avec l'IA.

8Catégories
33Contrôles
9Prompts IA
GratuitPour toujours
À LIRE

Avant de vous y fier

L'IA vous aide à créer vite — mais elle peut discrètement laisser votre appli exposée aux fuites, à la fraude ou au piratage de compte. SHIP-SAFE repère les failles les plus courantes. Elle ne garantit pas que vous êtes en sécurité, et elle ne remplace pas un audit professionnel. Voyez-la comme un plancher, pas un plafond — et revérifiez à chaque fois que vous publiez un changement.

Comment l'utiliser

Deux façons de faire la checklist

Parcourez les 33 contrôles vous-même — ou confiez le travail à l'IA avec laquelle vous avez créé l'appli. Chaque catégorie a un prompt à copier-coller, plus un prompt maître qui fait tout.

01 — À la main

Cochez au fur et à mesure

Allez catégorie par catégorie et cochez chaque point. Votre progression est enregistrée sur cet appareil, vous pouvez y revenir.

02 — Avec votre IA

Collez un prompt

Déposez le prompt maître (ou un prompt de catégorie) dans Claude, Cursor, Lovable ou l'assistant de votre éditeur, et demandez-lui d'auditer votre code et de rapporter réussite / échec avec les correctifs.

S
Catégorie 1 sur 8

Secrets

Les clés n'ont rien à faire dans le navigateur.
  • S1Aucun secret dans le code frontend ni votre dépôt.Clés d'API, jetons, clés service/admin, URL de base de données — rien de tout ça ne part dans le navigateur ni ne reste dans git.
  • S2Renouvelez toute clé un jour exposée.Commit une fois = fuite pour toujours. Renouvelez toute clé passée par l'historique git, une capture d'écran ou un log.
  • S3Clés à privilèges minimaux, par environnement.Séparez les clés dev et prod. Le navigateur ne détient qu'une clé publique/anon — jamais la clé service.
H
Catégorie 2 sur 8

Renforcer l'accès

L'authentification, c'est là que commencent les piratages.
  • H1Utilisez un fournisseur d'auth éprouvé — n'en codez pas un.Supabase Auth, Auth0, Clerk, etc. Le login maison et la crypto artisanale, c'est là que se cachent les failles subtiles.
  • H2Mots de passe forts + vérification de fuite.Imposez une longueur minimale et refusez les mots de passe déjà compromis (HaveIBeenPwned).
  • H3MFA sur les actions admin et argent.Un mot de passe volé ne devrait jamais suffire à déplacer des fonds ou à atteindre un panneau admin.
  • H4Sessions sécurisées.Cookies HttpOnly + Secure + SameSite ; les jetons expirent ; pas de jetons longue durée dans le localStorage.
  • H5Réinitialisations & liens magiques à l'épreuve des abus.À usage unique, expiration courte, avec limitation de débit — sinon le piratage de compte n'est qu'à un e-mail.
I
Catégorie 3 sur 8

Entrées & sorties

Ne jamais faire confiance à ce qui entre ; échapper ce qui sort.
  • I1Validez chaque entrée côté serveur.Type, plage et longueur imposés côté serveur — pas seulement dans le formulaire que l'utilisateur peut contourner.
  • I2Uniquement des requêtes paramétrées.Ne construisez jamais du SQL ou des commandes shell en concaténant des entrées. C'est comme ça qu'arrive l'injection.
  • I3Échappez vos sorties.Tout contenu fourni par l'utilisateur affiché sur une page est échappé ou nettoyé. C'est comme ça qu'arrive le XSS.
  • I4Téléversements de fichiers sûrs.Limitez le type et la taille, stockez hors de la racine web, et n'exécutez jamais un fichier téléversé.
P
Catégorie 4 sur 8

Permissions & accès aux données

Un bouton caché n'est pas de la sécurité.
  • P1Row-level security sur chaque table.Chaque utilisateur ne lit et n'écrit que ses propres lignes. Activé par défaut, partout.
  • P2Aucune politique publique / USING(true) sur des données sensibles.Une politique toujours vraie, c'est une base de données publique avec un cadenas qui n'est pas fermé.
  • P3Autorisez côté serveur, pas dans l'UI.Chaque action sensible revérifie la permission côté serveur ou base de données, quoi qu'affiche le front-end.
  • P4Verrouillez fonctions & endpoints à un rôle.Rien qui déplace de l'argent ou des données admin n'est appelable par un utilisateur anonyme. Attention aux droits publics par défaut.
  • P5Le client utilise une clé restreinte.Le navigateur ne détient jamais la clé service ou admin — seulement une clé publique et limitée.
S$
Catégorie 5 sur 8

Protéger l'argent

Calculez les montants là où l'utilisateur n'a pas accès.
  • $1Montants et soldes calculés côté serveur.Ne faites jamais confiance à un prix, un total ou un solde venu du client.
  • $2Protégez-vous contre la double dépense et le double crédit.Clés d'idempotence, contraintes d'unicité et verrous de ligne — pour qu'un renvoi ou une course ne paie pas deux fois.
  • $3Les plafonds par défaut sont la valeur sûre.Une limite absente doit signifier le palier restrictif — jamais « illimité ».
  • $4Ne faites jamais confiance à la propriété fournie par le client.Le serveur décide qui possède quoi — il ne le lit pas dans un champ de la requête.
A
Catégorie 6 sur 8

Abus & limitation

Tout ce qui n'est pas plafonné sera abusé.
  • A1Limitez le débit sur ce qui est sensible.Connexions, réinitialisations de mot de passe et actions argent — plafonnées par utilisateur et par IP.
  • A2Encadrez vos fonctionnalités d'IA.Si un utilisateur peut déclencher un modèle payant, plafonnez le coût et protégez-vous contre l'injection de prompt qui fuite des données ou déclenche des actions.
  • A3Protégez les formulaires publics & inscriptions.Limitez le débit ou ajoutez un défi (CAPTCHA) pour que les bots ne créent pas des comptes en masse ou ne vous inondent pas.
F
Catégorie 7 sur 8

Fortifier vos connexions

Chaque appel entrant ou sortant est une porte.
  • F1Vérifiez vos webhooks.Contrôlez la signature, rejetez les rejeux, et échouez en mode fermé si le secret de signature est absent.
  • F2Bloquez le SSRF.Si votre serveur va chercher une URL fournie par l'utilisateur, refusez les adresses internes et de métadonnées.
  • F3Pas de CORS en * sur les endpoints privés.Reflétez une liste d'origines autorisées explicite, pas « n'importe quel site sur Internet ».
  • F4HTTPS & en-têtes sécurisés partout.Aucun trafic en clair, et aucune protection de transport ou de type de contenu manquante.
E
Catégorie 8 sur 8

Toujours surveiller

La sécurité est une habitude, pas une tâche de lancement.
  • E1Mettez à jour vos dépendances.Suivez et corrigez les paquets présentant des vulnérabilités connues, au lieu de les figer et de les oublier.
  • E2Aucun endpoint de debug en production.Retirez les routes de test, de diagnostic et les portes dérobées avant de lancer — elles ne restent jamais secrètes.
  • E3Journalisez les événements de sécurité — jamais les secrets ni les données personnelles.Enregistrez les événements suspects et assurez-vous qu'au moins l'un d'eux parvienne à un humain.
  • E4Sauvegardes + un plan de secours.Sachez exactement comment révoquer et renouveler les identifiants dès qu'une fuite survient.
  • E5Relancez SHIP-SAFE à chaque publication.Chaque nouvelle fonctionnalité est une nouvelle surface d'attaque. La checklist ne vaut quelque chose que si vous y revenez.
Les prompts

Confiez-la à votre IA

Collez le prompt maître pour tout auditer d'un coup, ou ouvrez une seule catégorie ci-dessous. Ils sont écrits en lecture seule — l'IA rapporte et recommande, elle ne touche pas à vos données.

Prompt maître — lance les 33 contrôles
Tu es un relecteur sécurité qui audite mon application selon SHIP-SAFE, un référentiel de sécurité pour les applis créées avec l'IA. Passe en revue le code selon les 8 catégories et 33 contrôles ci-dessous. Pour CHAQUE contrôle, indique : RÉUSSITE / ÉCHEC / N-A, la preuve précise (fichier, ligne ou config) et — en cas d'ÉCHEC — le correctif exact.

Règles : travaille en LECTURE SEULE. N'exécute rien qui modifie des données, supprime des enregistrements ou déplace de l'argent. Classe les constats par gravité (exposition d'argent et de données d'abord). Termine par une liste de correctifs priorisée.

S — SECRETS : (S1) aucune clé/jeton/clé service dans le frontend ou le dépôt ; (S2) renouveler tout ce qui a été committé ; (S3) clés à privilèges minimaux par environnement, le navigateur ne détient qu'une clé publique.
H — RENFORCER L'ACCÈS : (H1) fournisseur d'auth éprouvé, pas de crypto maison ; (H2) longueur minimale + vérification des mots de passe compromis ; (H3) MFA sur admin/argent ; (H4) cookies HttpOnly+Secure+SameSite, sessions qui expirent ; (H5) réinitialisations/liens magiques à usage unique, expirants, à débit limité.
I — ENTRÉES/SORTIES : (I1) validation côté serveur de toutes les entrées ; (I2) requêtes paramétrées uniquement ; (I3) sorties échappées (pas de XSS) ; (I4) téléversements limités par type/taille, jamais exécutés.
P — PERMISSIONS : (P1) RLS sur chaque table ; (P2) pas de public/USING(true) sur des données sensibles ; (P3) autorisation côté serveur, pas dans l'UI ; (P4) fonctions & endpoints argent/admin non appelables en anonyme ; (P5) le client utilise une clé restreinte.
S($) — PROTÉGER L'ARGENT : ($1) montants/soldes calculés côté serveur ; ($2) protections contre double dépense/crédit (idempotence, clés uniques, verrous) ; ($3) plafonds par défaut à la valeur sûre ; ($4) le serveur dérive la propriété, ne fait jamais confiance à un champ client.
A — ABUS : (A1) limiter le débit des connexions/réinitialisations/actions argent par utilisateur et par IP ; (A2) plafonner le coût IA + défense contre l'injection de prompt ; (A3) limiter/CAPTCHA sur formulaires publics & inscriptions.
F — FORTIFIER LES CONNEXIONS : (F1) vérifier les signatures de webhook, rejeter les rejeux, échouer fermé ; (F2) bloquer le SSRF vers adresses internes/métadonnées ; (F3) pas de CORS en `*` sur les endpoints privés ; (F4) HTTPS + en-têtes sécurisés.
E — TOUJOURS SURVEILLER : (E1) mettre à jour les dépendances ; (E2) aucun endpoint de debug/test en prod ; (E3) journaliser les événements de sécurité (sans secrets/données perso) + alerter ; (E4) sauvegardes + plan de révocation/renouvellement ; (E5) rappeler que ceci doit être relancé à chaque changement.
SSecrets
Scanne tout mon dépôt ET le bundle frontend compilé à la recherche de secrets en dur : clés d'API, jetons d'accès, clés service/admin, URL de base de données, clés privées, secrets de signature. Liste chaque occurrence avec fichier et ligne, dis-moi lesquelles partent dans le navigateur, et donne-moi une façon sûre de déplacer chacune vers une variable d'environnement côté serveur. Scanne aussi l'historique git et signale tout ce qui a été committé pour que je le renouvelle.
HRenforcer l'accès
Passe en revue mon authentification et mes sessions. Confirme : j'utilise un fournisseur d'auth éprouvé (pas de login/crypto maison) ; les mots de passe ont une longueur minimale et refusent les mots de passe compromis ; les actions admin et argent exigent une MFA ; les cookies de session sont HttpOnly + Secure + SameSite avec une expiration raisonnable et sans jeton longue durée dans le localStorage ; les réinitialisations et liens magiques sont à usage unique, expirants et à débit limité. Rapporte chaque point en RÉUSSITE/ÉCHEC avec le correctif exact.
IEntrées & sorties
Vérifie la sécurité des entrées et sorties. Confirme que chaque entrée utilisateur est validée et bornée côté serveur (pas seulement dans le formulaire) ; que tous les accès base de données sont paramétrés (pas de SQL ni de shell construit à partir d'entrées) ; que tout contenu utilisateur affiché en HTML est échappé ou nettoyé (pas de XSS) ; et que les téléversements sont limités par type et taille, stockés hors de la racine web et jamais exécutés. Liste chaque endpoint ou composant qui échoue et comment le corriger.
PPermissions
Audite l'autorisation. Si j'utilise Supabase/Postgres : confirme que la RLS est activée sur CHAQUE table, qu'aucune politique n'utilise USING(true) sur des données sensibles, et que les utilisateurs ne lisent/écrivent que leurs propres lignes. Puis confirme que chaque action sensible est autorisée côté serveur/base (pas juste cachée dans l'UI), que chaque RPC/fonction/endpoint touchant à l'argent ou aux données admin est verrouillé au bon rôle (pas appelable en anonyme — attention aux droits PUBLIC par défaut), et que le navigateur utilise une clé restreinte, jamais la clé service. RÉUSSITE/ÉCHEC + correctif pour chaque point.
SProtéger l'argent
Passe en revue la gestion de l'argent. Confirme que les montants et soldes sont calculés côté serveur et jamais fournis par le client ; qu'il y a des protections contre la double dépense et le double crédit (clés d'idempotence, contraintes d'unicité, verrous de ligne/consultatifs) ; que les limites et plafonds par défaut prennent la valeur sûre et restrictive (jamais illimité sur une config absente) ; et qu'aucun code serveur ne fait confiance à un champ client de propriétaire, de prix ou d'identité. Parcours chaque chemin d'argent et montre-moi ses protections, ou là où elles manquent.
AAbus & limitation
Vérifie la limitation de débit et les protections contre l'abus. Confirme que les connexions, réinitialisations de mot de passe, actions argent et tout appel d'IA payant sont limités par utilisateur ET par IP (et que la source de l'IP ne peut pas être facilement usurpée ou concentrée derrière un proxy). Si mon appli a une fonctionnalité d'IA, confirme qu'elle ne peut pas être détournée par injection de prompt pour fuiter des données ou déclencher des actions non autorisées, et que son coût est plafonné. Confirme que les formulaires publics et inscriptions sont limités ou protégés par un défi. Liste tout ce qui n'est pas plafonné.
FFortifier les connexions
Passe en revue les intégrations et les bords réseau. Confirme que chaque webhook entrant vérifie sa signature, rejette les rejeux et échoue en mode fermé quand le secret est absent ; que le serveur ne peut pas être poussé à aller chercher des URL internes ou de métadonnées (SSRF) à partir de liens fournis par l'utilisateur ; que le CORS n'est pas « * » sur les endpoints authentifiés et utilise une liste d'origines explicite ; et que HTTPS ainsi que les en-têtes de réponse sécurisés sont imposés. RÉUSSITE/ÉCHEC + correctif pour chaque point.
EToujours surveiller
Vérifie l'hygiène continue. Liste les dépendances obsolètes ou présentant des vulnérabilités connues et la mise à jour sûre. Trouve tout endpoint de debug, test, diagnostic ou admin encore accessible en production. Confirme que les événements liés à la sécurité sont journalisés sans journaliser de secrets ni de données personnelles, et que les événements suspects alerteraient réellement un humain. Confirme que des sauvegardes existent et qu'il y a une procédure documentée pour révoquer et renouveler chaque identifiant en cas de fuite.

Le contrôle le plus important

SHIP-SAFE n'est pas une barrière qu'on passe une fois et qu'on oublie. L'habitude la plus importante, c'est E5 : relancer les 33 à chaque fonctionnalité publiée. L'IA écrit du nouveau code vite, et chaque nouveau endpoint, table ou bouton est une nouvelle surface d'attaque. Une checklist faite une seule fois, il y a six versions, protège une version de votre appli qui n'existe plus.

Aucune garantie. SHIP-SAFE est un référentiel de sécurité gratuit et communautaire, ni une certification ni une promesse. Réussir tous les contrôles réduit vos risques les plus probables — cela ne rend pas votre appli « sécurisée », et cela ne remplace pas un audit de sécurité ou un test d'intrusion professionnel, surtout si vous gérez de l'argent ou des données personnelles. Vous êtes responsable de vos propres systèmes. Utilisez-la comme un point de départ, continuez à apprendre, et quand les enjeux sont élevés, faites appel à un expert.

SHIP-SAFE est gratuite et le restera toujours. Si elle a sauvé votre appli d'une mauvaise journée, vous pouvez offrir un café aux mainteneurs.

☕ Offrez-moi un café