GRILLE DE NOTATION PUBLIQUE · v1.1 · MISE À JOUR 2026-10-10

Méthodologie du scanner

Chaque note zn Scan est une fraction pondérée des contrôles applicables. Cette page définit le catalogue complet des contrôles, les poids des niveaux et les règles qui gardent la mesure neutre et reproductible. La grille est versionnée ; chaque modification figure avec sa date dans le journal des modifications ci-dessous, et chaque rapport indique la version de la grille utilisée pour sa note.

1. Passif uniquement

Les analyses distantes effectuent le handshake MCP (initialize, notifications/initialized) et tools/list via Streamable HTTP, en 15 secondes maximum et uniquement sur les ports 443, 80 ou 8443. Aucun outil n’est jamais invoqué et aucun payload adversarial n’est envoyé à la cible. Si tools/list exige une authentification, les contrôles d’outils sortent du dénominateur au lieu d’échouer, et le rapport indique combien de contrôles ont été notés.

2. Applicabilité

Un contrôle que la cible ne peut pas satisfaire par conception (pas d’outils de mutation, serveur en lecture seule) est exclu du dénominateur au lieu d’être noté comme un échec. Note = poids obtenu / poids applicable. Une note en lettre exige au moins un contrôle au niveau des outils : sinon le rapport est Non noté.

3. Neutralité produit

Aucun contrôle ne récompense un produit spécifique. zn-gate n’apparaît que comme l’une de plusieurs options de remédiation, toujours à côté d’une alternative open source. Toutes les notes de A+ à F sont atteignables sans aucun achat.

Tranches de notes

NoteScoreSignification
A+95–100Très résilient
A85–94Base solide
B70–84Risque modéré
C50–69Risque élevé
F< 50Vulnérabilité critique
NR—Non noté : aucun contrôle au niveau des outils n’a pu être noté (endpoint protégé par authentification, ancien transport SSE ou aucun schéma d’outils). Les contrôles observés restent affichés.

Niveau Essentiel

12 pts chacun

Sécurité de base. Les contrôles absents sont comptés comme des échecs.

Chiffrement du transport TLS 1.2+

RFC 5246 / RFC 8446tls_transport

Endpoints accessibles en HTTPS avec une chaîne de certificats valide pour le nom d’hôte. Un transport HTTP en clair échoue.

Correctif : Terminez TLS en bordure avec un certificat géré et redirigez toutes les requêtes en clair.
Alternative open source : Let's Encrypt + Caddy ou certbot pour Nginx avec HSTS.

Frontière de transport authentifiée

MCP Authorizationauth_boundary

Les endpoints MCP qui exposent des outils capables de mutation imposent une frontière d’authentification (OAuth 2.1 avec PKCE ou bearer tokens signés) avant de les servir.

Correctif : Exigez le flux authorization code d’OAuth 2.1 avec PKCE sur chaque endpoint de transport MCP.
Alternative open source : Les fournisseurs d’identité open source (Keycloak, Ory Hydra, oauth2-proxy) proposent les mêmes flux.

Bornes d’entrée et limites de payload

OWASP LLM10input_bounds

Les paramètres string déclarés incluent des longueurs maximales, des enums ou des patterns, afin qu’un seul appel ne puisse pas transporter de payload illimité.

Correctif : Contraignez les paramètres string avec maxLength, enum ou pattern et rejetez les corps trop volumineux au niveau du transport.
Alternative open source : maxLength de JSON Schema plus des limites de taille du corps au niveau du framework (p. ex. les limites de body-parser dans express).

Hygiène des descriptions d’outils

OWASP LLM01tool_desc_hygiene

Les descriptions d’outils et de paramètres sont analysées à la recherche d’impératifs adversariaux et d’Unicode invisible cachés dans les docstrings (empoisonnement indirect d’outils).

Correctif : Réécrivez les descriptions comme des énoncés neutres de capacité ; supprimez les propositions impératives et les caractères invisibles.
Alternative open source : mcp-scan (Invariant Labs) et LlamaFirewall signalent tous deux les descriptions empoisonnées.

Aucune primitive shell non contrainte

OWASP LLM06shell_primitives

Les outils qui exposent un shell arbitraire, eval ou l’exécution de commandes sur l’hôte sans sandbox sont critiques par conception.

Correctif : Remplacez les outils shell ouverts par des opérations granulaires et circonscrites, ou exécutez-les dans un sandbox (Docker, Firecracker).
Alternative open source : MicroVM Firecracker, gVisor ou Docker avec rootfs en lecture seule et capabilities retirées.

Mutation du système de fichiers bornée

OWASP LLM06fs_mutation

Les outils d’écriture ou de suppression de fichiers doivent borner leurs paramètres de chemin (pattern, longueur ou racine de sandbox déclarée). Les chemins non bornés échouent.

Correctif : Liez le serveur à une seule racine d’espace de travail en respectant les exclusions de fichiers cachés.
Alternative open source : Le serveur MCP filesystem de référence circonscrit ses racines de la même façon.

Aucun paramètre d’identifiants en clair

OWASP LLM02credentials_exposure

Les paramètres des outils ne doivent pas accepter de clés d’API, mots de passe ou tokens comme arguments visibles par le modèle.

Correctif : Injectez les identifiants à l'exécution depuis l'environnement ou un gestionnaire de secrets, jamais via les arguments des outils.
Alternative open source : Vault, AWS Secrets Manager ou Doppler avec injection limitée à l’environnement.

Niveau Recommandé

6 pts chacun

Bonne pratique pour les serveurs exposés. Les échecs retirent du poids.

Typage strict du schéma des paramètres

OWASP LLM05param_typing

Chaque outil déclare un inputSchema de type object et chaque paramètre déclaré a un type explicite. Les outils sans arguments réussissent ; les schémas absents ou typés comme des sacs ouverts échouent.

Correctif : Déclarez les types (string, integer, boolean) et les champs requis dans l’inputSchema de chaque outil.
Alternative open source : Zod, Pydantic ou JSON Schema natif génèrent des schémas stricts de la même façon.

Validation humaine des mutations à fort enjeu

OWASP LLM06financial_human_gate

Les actions irréversibles (remboursement, virement, débit, déploiement) exigent une étape d’approbation humaine auditable. Non observable passivement : signalé pour vérification manuelle, jamais noté.

Correctif : Ajoutez un flux de confirmation en deux étapes avec des jetons d’approbation côté serveur pour les outils de mutation.
Alternative open source : Toute file d’approbation basée sur des webhooks (bot Slack, flux Linear) met en œuvre la même barrière.

Capacité de filtrage des sorties d’outils

OWASP LLM01output_filter_capacity

La cible doit présenter un mécanisme pour inspecter ou filtrer le contenu renvoyé par les outils avant qu’il n’atteigne le modèle, quel que soit le fournisseur.

Correctif : Filtrez les sorties d’outils en ligne (gate neuronal, politique regex ou middleware du framework) avant de les réinjecter dans le contexte.
Alternative open source : LlamaFirewall, LLM Guard ou Azure Prompt Shield offrent une capacité équivalente.

Isolation de l’espace de noms des outils

OWASP LLM01namespace_isolation

Le contexte ne peut pas redéfinir, masquer ou remplacer des noms d’outils enregistrés depuis des documents non fiables.

Correctif : Reconstruisez le registre des outils à chaque tour et rejetez les noms masqués.
Alternative open source : Le SDK MCP de référence garde immuables les noms d’outils contrôlés par le client.

Niveau Bonus

2 pts chacun

Points en plus. S’il est absent par conception, le contrôle est exclu du dénominateur : il ne retire jamais de points.

Politique de rétention zéro des données publiée

OWASP LLM02zdr_policy

Une déclaration publiée et accessible par lien sur ce que le serveur conserve des appels d’outils ou des conversations.

Correctif : Publiez une déclaration de rétention des données sur le site.
Alternative open source : Une page de documentation publique ou un rapport de confiance y satisfait sans aucun fournisseur.

Piste d’audit cryptographique

OWASP LLM06audit_trail

Les verdicts et les mutations produisent des enregistrements de preuve chaînés par hash ou signés.

Correctif : Journalisez les verdicts avec chaînage par hash ou stockage en ajout seul.
Alternative open source : Des journaux chaînés par hash avec OpenSSL ou un journal Merkle en ajout seul mettent en œuvre ce modèle.

Fonctionnement de l’analyse distante

  • La résolution DNS est validée avant chaque connexion ; les requêtes épinglent une seule adresse résolue (aucune fenêtre de DNS rebinding).
  • Les plages privées, loopback, link-local (y compris 169.254.169.254), CGNAT, multicast et de documentation sont rejetées à la résolution DNS, puis de nouveau à chaque redirection.
  • 2 redirections au maximum, 8 secondes au plus par requête, un budget de 15 secondes pour toute l’analyse, réponse plafonnée à 512 Ko par requête.
  • Un HTTP 401 ou 403 ne compte comme challenge d’authentification MCP qu’avec un en-tête WWW-Authenticate: Bearer, des métadonnées de ressource protégée RFC 9728 ou un corps d’erreur JSON-RPC. Les serveurs protégés par authentification sont signalés comme Non noté, jamais comme A+ sur la seule base du transport.
  • Limite : 20 analyses par heure et par IP source.
  • Les cibles qui ne répondent pas comme un serveur MCP (injoignables, ou réponses HTTP qui ne sont pas MCP) sont signalées uniquement à l’utilisateur ; rien n’est publié.
  • Les certificats TLS doivent être valides pour le nom d’hôte analysé (SNI, chaîne complète).
  • Chaque rapport contient une preuve par contrôle et sa propre URL (scan.usezn.com/r/{id}/) avec des variantes JSON, Markdown et badge, afin que toute note puisse être revérifiée en relançant la même analyse. Les rapports ne sont pas indexés par les moteurs de recherche et sont supprimés après 90 jours.

Mode statique (artefacts collés)

Les system prompts et schémas d’outils collés sont analysés dans le navigateur et ne sont jamais envoyés. Les mêmes lexiques et poids de niveaux s’appliquent ; les contrôles de transport sont exclus du dénominateur, car des artefacts collés ne peuvent pas les porter. Un system prompt collé sans schéma d’outils est Non noté. Ce mode prouve ce que les artefacts eux-mêmes déclarent, rien de plus.

Références normatives

  • TLS 1.2 (RFC 5246) / TLS 1.3 (RFC 8446).
  • Model Context Protocol (2025-06-18): initialize, tools/list, Streamable HTTP, Authorization (OAuth 2.1).
  • OAuth 2.0 Protected Resource Metadata: RFC 9728.
  • OWASP Top 10 for LLM Applications (2025): LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM10 Unbounded Consumption.

Journal des modifications

v1.1

2026-10-10
  • Not rated (NR): a letter grade now requires at least one tool-level check. Auth-gated endpoints, legacy SSE servers and empty tool lists are reported as Not rated instead of earning A+ on transport alone.
  • Auth detection: an HTTP 401/403 counts as an MCP auth challenge only with a WWW-Authenticate: Bearer header, RFC 9728 protected-resource metadata or a JSON-RPC error body; a bare 403 from a firewall is not an MCP server and is not published.
  • Fewer false positives: credential parameters are matched on whole name segments (author, max_tokens and page_token no longer match); tools without arguments pass schema typing; filesystem checks only apply to file-shaped tools; shell detection needs a shell/eval/command-execution name, or a description of arbitrary command or code execution.
  • Tool description hygiene also inspects parameter descriptions and flags invisible Unicode (zero-width, bidirectional and tag characters).
  • References corrected to the OWASP Top 10 for LLM Applications 2025 (LLM01, LLM02, LLM05, LLM06, LLM10) and the MCP authorization spec.
  • Duplicate auth and transport rows removed from reports.

v1.0

2026-09-30
  • First public rubric: 13 checks in three tiers, applicability exclusions, passive remote mode and in-browser static mode.

Les rapports conservent la version de la grille utilisée pour leur note. Relancez l’analyse pour obtenir une note selon la version actuelle. Le journal des modifications est publié en anglais.

Contestations et corrections

Vous pensez qu’un contrôle est erroné pour votre serveur ? Écrivez à security@usezn.com avec l’identifiant de l’analyse (scan_…, affiché sur chaque rapport) et ce que vous jugez inexact. Les erreurs de grille confirmées sont corrigées dans une nouvelle version de la grille, listée dans le journal des modifications ci-dessus. Les propriétaires de serveurs peuvent aussi demander le retrait d’un rapport publié sur leur serveur. security@usezn.com

La version actuelle est la v1.1, mise à jour le 2026-10-10. Pour demander un nouveau contrôle, écrivez à la même adresse.