Seguridad de MCP: Lo que aprendí tras 95 caídas en producción
Pensaba que la seguridad era sencilla. Actualizar dependencias. Usar HTTPS. No incluir secretos directamente en el código.
Me equivocaba.
Tras 95 caídas en producción y 1.800 horas de desarrollo, aprendí que la seguridad del Model Context Protocol (MCP) es diferente. No es como la seguridad estándar de una API REST.
MCP crea nuevos riesgos porque el cliente es un LLM, no un humano.
Esto es lo que debes saber para mantener seguro tu servidor MCP.
1. El modelo de amenazas de MCP
En REST, sabes exactamente quién está llamando a tu API. En MCP, el LLM actúa como intermediario. Esto lo cambia todo:
- Los LLM pueden alucinar llamadas a herramientas o parámetros.
- Los usuarios no llaman a las herramientas directamente. Hablan con el LLM, y el LLM habla con tu servidor.
- Los clientes maliciosos pueden sondear tu servidor en busca de herramientas ocultas durante el proceso de descubrimiento.
Tu mayor amenaza no es solo un hacker. Es un LLM con buenas intenciones cometiendo un error accidental que bloquea tu sistema.
2. Gestión de claves de API
Muchos desarrolladores pasan las claves de API en los parámetros de consulta para facilitar las cosas. Esto es un error. Los parámetros de consulta aparecen en cada registro del servidor y en cada proxy.
Sigue estas reglas:
- Usa autenticación por cabecera (
Authorization: Bearer). - Evita pasar claves en el cuerpo JSON.
- Asigna una clave de API diferente para cada cliente. Esto te ayuda a rastrear el uso y revocar el acceso sin romperlo todo.
3. Validación estricta de entradas
Los LLM se equivocarán al adivinar. Enviarán tipos incorrectos y parámetros adicionales. Debes validar cada llamada:
- Primero, comprueba si el nombre de la herramienta existe en tu lista.
- Rechaza las llamadas con parámetros adicionales. No te limites a ignorarlos.
- Coincide exactamente con los tipos de parámetros. No realices conversiones automáticas de tipos de datos.
- Establece límites de tamaño estrictos para cadenas y arrays para evitar bloqueos de memoria.
- Sanea todas las rutas de archivos para evitar el salto de directorio (directory traversal).
4. Limitación de tasa por capas
Un solo prompt de usuario puede activar diez llamadas a herramientas a la vez. Esto puede agotar tu pool de conexiones en segundos.
Usa tres capas de defensa:
- Límites por clave de API para controlar el uso del cliente.
- Límites por IP para detener ataques de fuerza bruta.
- Límites de conexiones concurrentes para mantener tu servidor vivo durante picos de actividad.
5. Riesgos de inyección de prompts
Un usuario puede engañar a un LLM para que llame a una herramienta destructiva. Si un usuario le dice al LLM que borre todas las notas, el LLM podría hacerlo realmente.
Protégete:
- Separa las operaciones de lectura y escritura.
- Requiere confirmación manual del usuario para cualquier acción de eliminación o actualización.
- Utiliza el principio de mínimo privilegio para el usuario de tu base de datos.
La seguridad es un proceso continuo. Empieza con una mejor gestión de claves y una validación estricta. Estos pasos resuelven la mayoría de los problemas.
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi