Metodología del escáner
Cada puntuación de zn Scan es una fracción ponderada de los controles aplicables. Esta página define el catálogo completo de controles, los pesos de cada nivel y las reglas que mantienen la medición neutral y reproducible. La rúbrica está versionada; cada cambio figura con su fecha en el registro de cambios de abajo, y cada informe indica la versión de la rúbrica con la que se puntuó.
1. Solo pasivo
Los escaneos remotos hacen el handshake MCP (initialize, notifications/initialized) y tools/list sobre Streamable HTTP, en un máximo de 15 segundos y solo en los puertos 443, 80 u 8443. Nunca se invoca ninguna herramienta ni se envía ningún payload adversarial al objetivo. Si tools/list requiere autenticación, los controles de herramientas salen del denominador en lugar de fallar, y el informe muestra cuántos controles se puntuaron.
2. Aplicabilidad
Un control que el objetivo no puede cumplir por diseño (sin herramientas de mutación, servidor de solo lectura) se excluye del denominador en lugar de puntuarse como fallo. Puntuación = peso obtenido / peso aplicable. Una nota con letra necesita al menos un control a nivel de herramienta: si no, el informe queda Sin nota.
3. Neutralidad de producto
Ningún control premia un producto concreto. zn-gate aparece solo como una de varias opciones de remediación, siempre junto a una alternativa open source. Todas las notas de A+ a F se pueden alcanzar sin comprar nada.
Rangos de nota
| Nota | Puntuación | Significado |
|---|---|---|
| A+ | 95–100 | Muy resiliente |
| A | 85–94 | Base sólida |
| B | 70–84 | Riesgo moderado |
| C | 50–69 | Riesgo elevado |
| F | < 50 | Vulnerabilidad crítica |
| NR | — | Sin nota: no se pudo puntuar ningún control a nivel de herramienta (endpoint con autenticación, transporte SSE antiguo o sin esquema de herramientas). Los controles observados se siguen mostrando. |
Nivel Esencial
12 pts cada unoSeguridad básica. Los controles ausentes cuentan como fallos.
Cifrado de transporte TLS 1.2+
RFC 5246 / RFC 8446tls_transportEndpoints accesibles por HTTPS con una cadena de certificados válida para el nombre de host. El transporte HTTP en claro falla.
Solución: Termina TLS en el borde con un certificado gestionado y redirige todas las peticiones en claro.
Alternativa open source: Let's Encrypt + Caddy o certbot para Nginx con HSTS.
Frontera de transporte autenticada
MCP Authorizationauth_boundaryLos endpoints MCP que exponen herramientas capaces de mutar imponen una frontera de autenticación (OAuth 2.1 con PKCE o bearer tokens firmados) antes de servirlas.
Solución: Exige el flujo authorization code de OAuth 2.1 con PKCE en cada endpoint de transporte MCP.
Alternativa open source: Los proveedores de identidad open source (Keycloak, Ory Hydra, oauth2-proxy) ofrecen los mismos flujos.
Límites de entrada y de payload
OWASP LLM10input_boundsLos parámetros de tipo string declarados incluyen longitudes máximas, enums o patrones, de modo que una sola llamada no pueda llevar payloads sin límite.
Solución: Restringe los parámetros string con maxLength, enum o pattern y rechaza los cuerpos demasiado grandes a nivel de transporte.
Alternativa open source: maxLength de JSON Schema más límites de tamaño del cuerpo a nivel de framework (p. ej. los límites de body-parser en express).
Higiene de las descripciones de herramientas
OWASP LLM01tool_desc_hygieneSe analizan las descripciones de herramientas y parámetros en busca de imperativos adversariales y Unicode invisible ocultos en los docstrings (envenenamiento indirecto de herramientas).
Solución: Reescribe las descripciones como declaraciones neutrales de capacidad; elimina las cláusulas imperativas y los caracteres invisibles.
Alternativa open source: mcp-scan (Invariant Labs) y LlamaFirewall señalan descripciones envenenadas.
Sin primitivas de shell sin restricciones
OWASP LLM06shell_primitivesLas herramientas que exponen shell arbitraria, eval o ejecución de comandos en el host sin sandbox son críticas por diseño.
Solución: Sustituye las herramientas de shell abiertas por operaciones granulares y acotadas, o ejecútalas dentro de un sandbox (Docker, Firecracker).
Alternativa open source: MicroVM de Firecracker, gVisor o Docker con rootfs de solo lectura y capabilities eliminadas.
Mutación del sistema de archivos acotada
OWASP LLM06fs_mutationLas herramientas de escritura o borrado de archivos deben acotar sus parámetros de ruta (pattern, longitud o una raíz de sandbox declarada). Las rutas sin acotar fallan.
Solución: Limita el servidor a una única raíz de espacio de trabajo y respeta las exclusiones de archivos ocultos.
Alternativa open source: El servidor MCP de sistema de archivos de referencia acota las raíces de la misma forma.
Sin parámetros de credenciales en texto plano
OWASP LLM02credentials_exposureLos parámetros de las herramientas no deben aceptar API keys, contraseñas ni tokens como argumentos visibles para el modelo.
Solución: Inyecta las credenciales en tiempo de ejecución desde el entorno o un gestor de secretos, nunca a través de argumentos de herramientas.
Alternativa open source: Vault, AWS Secrets Manager o Doppler con inyección acotada por entorno.
Nivel Recomendado
6 pts cada unoBuena práctica para servidores expuestos. Los fallos restan peso.
Tipado estricto del esquema de parámetros
OWASP LLM05param_typingCada herramienta declara un inputSchema de tipo object y cada parámetro declarado tiene un tipo explícito. Las herramientas sin argumentos superan el control; los esquemas ausentes o tipados como bolsas abiertas fallan.
Solución: Declara tipos (string, integer, boolean) y campos obligatorios en el inputSchema de cada herramienta.
Alternativa open source: Zod, Pydantic o JSON Schema puro generan esquemas estrictos de la misma forma.
Aprobación humana en mutaciones de alto impacto
OWASP LLM06financial_human_gateLas acciones irreversibles (reembolso, transferencia, cobro, despliegue) requieren un paso de aprobación humana auditable. No es observable de forma pasiva: se reporta para verificación manual, nunca se puntúa.
Solución: Añade un flujo de confirmación en dos pasos con tokens de aprobación del lado del servidor para las herramientas de mutación.
Alternativa open source: Cualquier cola de aprobación basada en webhooks (bot de Slack, flujo de Linear) implementa la misma barrera.
Capacidad de filtrado de la salida de herramientas
OWASP LLM01output_filter_capacityEl objetivo debe mostrar algún mecanismo para inspeccionar o filtrar el contenido que devuelven las herramientas antes de que llegue al modelo, sea cual sea el proveedor.
Solución: Filtra las salidas de las herramientas en línea (gate neuronal, política de regex o middleware del framework) antes de reinyectarlas en el contexto.
Alternativa open source: LlamaFirewall, LLM Guard o Azure Prompt Shield ofrecen una capacidad equivalente.
Aislamiento del espacio de nombres de herramientas
OWASP LLM01namespace_isolationEl contexto no puede redefinir, suplantar ni sobrescribir nombres de herramientas registrados desde documentos no fiables.
Solución: Reconstruye el registro de herramientas en cada turno y rechaza los nombres suplantados.
Alternativa open source: El SDK MCP de referencia mantiene inmutables los nombres de herramientas controlados por el cliente.
Nivel Extra
2 pts cada unoPuntos extra. Si falta por diseño, el control se excluye del denominador: nunca resta.
Política de retención cero de datos publicada
OWASP LLM02zdr_policyUna declaración publicada y enlazable sobre lo que el servidor conserva de las llamadas a herramientas o de las conversaciones.
Solución: Publica una declaración de retención de datos en el sitio.
Alternativa open source: Una página pública de documentación o un informe de confianza lo cumple sin ningún proveedor.
Registro de auditoría criptográfico
OWASP LLM06audit_trailLos veredictos y las mutaciones generan registros de evidencia encadenados por hash o firmados.
Solución: Registra los veredictos con encadenamiento por hash o almacenamiento de solo anexado.
Alternativa open source: Logs encadenados por hash con OpenSSL o un log Merkle de solo anexado implementan este patrón.
Funcionamiento del escaneo remoto
- La resolución DNS se valida antes de cada conexión; las peticiones fijan una única dirección resuelta (sin ventana de DNS rebinding).
- Los rangos privados, de loopback, link-local (incluida 169.254.169.254), CGNAT, multicast y de documentación se rechazan al resolver el DNS y de nuevo en cada salto de redirección.
- Máximo 2 redirecciones, como mucho 8 segundos por petición, 15 segundos para todo el escaneo y un límite de respuesta de 512 KB por petición.
- Un HTTP 401 o 403 cuenta como desafío de autenticación MCP solo con una cabecera WWW-Authenticate: Bearer, metadatos de recurso protegido según RFC 9728 o un cuerpo de error JSON-RPC. Los servidores con autenticación se reportan como Sin nota, nunca como A+ solo por el transporte.
- Límite: 20 escaneos por hora por IP de origen.
- Los objetivos que no responden como servidor MCP (inaccesibles, o respuestas HTTP que no son MCP) solo se comunican al usuario; no se publica nada.
- Los certificados TLS deben validar contra el nombre de host escaneado (SNI, cadena completa).
- Cada informe incluye evidencia por control y su propia URL (scan.usezn.com/r/{id}/) con variantes JSON, Markdown e insignia, de modo que cualquier puntuación se puede volver a verificar repitiendo el mismo escaneo. Los informes no se indexan en buscadores y se borran a los 90 días.
Modo estático (artefactos pegados)
Los system prompts y esquemas de herramientas pegados se analizan en el navegador y nunca se suben. Se aplican los mismos léxicos y pesos por nivel; los controles de transporte se excluyen del denominador porque los artefactos pegados no pueden contenerlos. Un system prompt pegado sin esquema de herramientas queda Sin nota. Este modo demuestra lo que declaran los propios artefactos, nada más.
Referencias normativas
- 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.
Registro de cambios
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.
Los informes conservan la versión de la rúbrica con la que se puntuaron. Vuelve a lanzar el escaneo para obtener una puntuación con la versión actual. El registro de cambios se publica en inglés.
Reclamaciones y correcciones
¿Crees que un control es incorrecto para tu servidor? Escribe a security@usezn.com con el id del escaneo (scan_…, visible en cada informe) y lo que consideras inexacto. Los errores de la rúbrica confirmados se corrigen en una nueva versión de la rúbrica que figura en el registro de cambios de arriba. Los propietarios de servidores también pueden pedir que se retire un informe publicado sobre su servidor. security@usezn.com