Une route Flask qui répond au challenge url_verification de Slack mais ne vérifie jamais X-Slack-Signature accepte de faux événements et clics de boutons de la part de quiconque trouve l'URL, et un seul signatureVerification: false dans une application Bolt produit le même effet. Cette skill détecte ces erreurs et onze autres erreurs d'applications Slack avant le déploiement, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur les fichiers JavaScript, TypeScript et Python qui utilisent Slack (Bolt, slack_sdk, @slack/web-api, tokens Slack, URL, en-têtes ou champs de requête que seul Slack envoie), sur les manifestes d'applications Slack en JSON ou YAML, et sur les fichiers env, de configuration et de CI pour y chercher des tokens et des URL de webhooks. Il connaît les valeurs par défaut de Bolt (la vérification de signature est active tant que vous ne la désactivez pas, Socket Mode n'en a pas besoin), les helpers de vérification de slack_sdk et @slack/bolt, les frameworks edge qui vérifient par défaut, et sait quand un contrôle peut se trouver dans un middleware, un hook, un décorateur ou un helper qu'il ne peut pas lire (il indique alors REVIEW, et non BLOCK). Il lit .gitignore, de sorte qu'un token dans un fichier .env ignoré par git est compté sur une seule ligne au lieu d'être signalé. Les placeholders de la documentation Slack sont ignorés, les commentaires et fichiers de test sont sautés, et rien n'est exécuté ni envoyé à Slack. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les tokens, secrets et URL de webhooks ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en ligne)

• K01 : tokens Slack (xoxb, xoxp, xapp, tokens rotatifs et de rafraîchissement) dans le code, les manifestes, les fichiers env, de configuration ou de CI que git committerait
• K02 : signing secrets, client secrets ou verification tokens écrits comme littéraux ou comme valeurs de repli littérales dans le code
• K03 : URL d'incoming webhooks ou de webhooks de workflow dans le code, les fichiers env, de configuration ou de CI que git committerait
• K04 : un fichier contenant tout un serveur qui traite des événements Slack, des commandes slash ou de l'interactivité sans rien qui puisse vérifier X-Slack-Signature
• K05 : vérification de signature de Bolt désactivée (signatureVerification: false, request_verification_enabled=False) en dehors de Socket Mode

REVIEW (à contrôler avant la publication)

• K11 : une vérification de signature faite maison sans limite de cinq minutes sur l'horodatage
• K12 : une vérification de signature faite maison qui compare avec == au lieu d'une fonction à temps constant
• K13 : un handler de requêtes Slack dont la vérification de signature, s'il y en a une, se trouve dans des middlewares, hooks, décorateurs, helpers ou fichiers que l'analyse ne peut pas lire
• K14 : handlers qui font confiance au verification token obsolète
• K15 : scopes admin et scopes d'historique ou de recherche pour les tokens utilisateur (y compris les scopes optionnels) dans les manifestes et les paramètres OAuth
• K16 : URL de redirection OAuth, d'Events, d'interactivité et de commandes slash en http (et non https)
• K17 : messages @channel, @here ou @everyone, ou link_names, dont l'appel contient du texte de l'utilisateur ou de la requête
• K18 : vérification du state OAuth désactivée ou secret du state écrit dans le code

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, une approche plus sûre et un lien vers la documentation Slack pour chaque règle
• Une application Slack d'exemple à risque et une sûre (application Bolt, manifeste, service Flask et routes Express), ainsi que le rapport réel produit par le scanner sur celle à risque

Limites

Il lit chaque fichier tel qu'il est écrit : les paramètres définis dans les pages de configuration de l'application Slack, les valeurs issues de variables d'environnement ou d'autres modules, et ce que font réellement les middlewares ou helpers d'autres fichiers ne sont pas vus. Un handler qui ne mentionne jamais Slack n'est pas vérifié. Seul le code JavaScript, TypeScript et Python est lu ; Bolt pour Java et les applications en Go, Ruby ou PHP ne sont pas vérifiés. Les fichiers env, de configuration et de CI ne sont lus que pour les tokens et les URL de webhooks. Un seul résultat est affiché par règle et par ligne. Les fichiers de test sont ignorés. NOT FLAGGED n'est pas une garantie.

Contenu

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

Mode d'emploi : Il s'agit d'une skill pour 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 seuls avec Python 3.9 ou une version plus récente, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.