EXPO_PUBLIC_OPENAI_API_KEY=... place votre clé OpenAI en clair dans chaque copie de votre app, car Expo copie dans le bundle JavaScript chaque valeur EXPO_PUBLIC_ lue par votre code. Un profil de build de production avec "developmentClient": true envoie le client de développement aux utilisateurs du store, et "disableAntiBrickingMeasures": true dans app.json désactive le filet de sécurité des mises à jour pour chaque build, production comprise. Ce skill détecte ces erreurs et quatorze autres erreurs de configuration Expo et EAS avant la livraison, et vous indique comment corriger chacune d'elles.

Votre agent lance un scanner sur app.json, app.config.js et app.config.ts, eas.json (les commentaires et virgules finales ne posent pas de problème), credentials.json, les fichiers .env, package.json et .gitignore, ainsi que sur les références process.env.EXPO_PUBLIC_ de votre code JavaScript et TypeScript. Il sait quelles parties de la configuration de l'app Expo exclut de la configuration publique, suit les profils eas.json à travers extends, lit les règles .gitignore comme le fait git, distingue les clés client publiables (clés publiables Firebase, Supabase, Stripe et Clerk, RevenueCat, Mapbox, PostHog) des clés secrètes et fonctionne dans les monorepos contenant plusieurs apps. Il n'exécute jamais Expo, EAS CLI, la configuration de votre app ni votre code. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la livraison)

• E01 : une variable EXPO_PUBLIC_ qui contient un secret (dans les fichiers .env, l'env de build d'eas.json ou le code) : une valeur ayant la forme d'une clé secrète (clés secrètes Stripe, OpenAI, Anthropic, GitHub, AWS, une clé service_role Supabase et d'autres), un nom se terminant par _SECRET, _SECRET_KEY, _PASSWORD, _PRIVATE_KEY, _SERVICE_ROLE_KEY ou _AUTH_TOKEN, ou la clé d'API d'un fournisseur d'IA, d'e-mail ou de SMS réservé au serveur, comme EXPO_PUBLIC_OPENAI_API_KEY (les noms de clés de stockage comme EXPO_PUBLIC_AUTH_TOKEN_STORAGE_KEY ne sont pas signalés)
• E02 : un secret dans app.json ou app.config : une valeur ayant la forme d'un secret ou un mot de passe ou paramètre secret littéral dans extra, les options de plugins ou hooks, un mot de passe dans une URL, ou ...process.env étalé dans la configuration
• E03 : un secret dans eas.json : une variable env de profil de build dont le nom se termine par un terme de secret (ou qui est une clé de fournisseur réservé au serveur) définie sur un littéral, un nom de clé d'API ou de jeton défini sur une longue valeur générée, ou toute valeur ayant la forme d'un secret
• E04 : credentials.json, un keystore ou certificat de distribution qu'il désigne, une clé App Store Connect ou Google Play désignée par submit dans eas.json, ou la clé privée de signature de code expo-updates, présents dans le projet sans aucune règle .gitignore qui les couvre
• E05 : un profil de build production, release ou store (pas internal) qui produit un build de développement : developmentClient true (y compris via extends), une configuration de build iOS Debug ou une commande Gradle Debug
• E06 : updates.url en http simple vers un hôte public, non signé, dans une configuration d'app qui autorise aussi le http simple (usesCleartextTraffic ou NSAllowsArbitraryLoads)
• E07 : disableAntiBrickingMeasures true dans app.json, ce qui s'applique à chaque build

REVIEW (à vérifier avant la publication)

• E11 : usesCleartextTraffic true (expo-build-properties)
• E12 : NSAllowsArbitraryLoads true dans ios.infoPlist (App Transport Security désactivé)
• E13 : un serveur de mises à jour auto-hébergé sans updates.codeSigningCertificate
• E14 : updates.url défini mais sans runtimeVersion, si bien qu'expo-updates reste désactivé
• E15 : expo-secure-store avec configureAndroidBackup false alors que les sauvegardes Android sont autorisées
• E16 : une variable EXPO_PUBLIC_ ou une valeur de configuration de l'app nommée comme une clé d'API et contenant un long littéral généré qui n'est pas une clé publiable connue
• E17 : app.config qui copie une variable d'environnement contenant un secret ou une clé d'API (comme OPENAI_API_KEY) dans extra ou les options de plugins, où elle est livrée avec l'app
• E18 : disableAntiBrickingMeasures true écrit dans app.config
• E19 : newArchEnabled false sous Expo SDK 55 ou ultérieur, où ce paramètre est ignoré
• E20 : tout autre updates.url en http simple vers un hôte non local : iOS et Android 9 et versions ultérieures le refusent par défaut, donc les mises à jour échouent généralement

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, l'approche plus sûre et un lien vers la documentation officielle d'Expo ou d'Apple pour chaque règle
• Un monorepo d'exemple risqué et un sûr (trois apps), ainsi que le rapport réel produit par le scanner sur le monorepo risqué

Limites

Il lit le texte des fichiers et n'exécute jamais app.config.js ni app.config.ts, donc les valeurs construites par des fonctions ou des imports ne sont pas suivies, et les variables d'environnement sont jugées sur leur nom, pas sur leur valeur. E04 se fonde sur le texte de .gitignore, pas sur l'historique git, donc un fichier déjà commité n'est pas détecté. Les variables d'environnement EAS stockées sur les serveurs d'Expo ne sont pas vérifiées, et les projets EAS Update sans signature de code ne sont pas signalés, car Expo ne propose la signature de code pour EAS Update que dans les offres payantes. Les fichiers natifs ios et android ne sont pas lus. Le client d'exemple officiel custom-expo-updates-server autorise le trafic en clair pour son serveur localhost et est volontairement signalé en E11 REVIEW. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP contenant 31 fichiers : SKILL.md, le scanner dans scripts/ (8 fichiers Python), references/rules.md (chaque règle avec sa raison et une approche plus sûre) et examples/ (20 fichiers d'exemple plus report.md, la sortie réelle du scanner sur l'exemple risqué).

Utilisation : il s'agit d'un skill d'agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi de manière autonome avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.