Referencia de seguridad del servidor MCP

Qué es esto

Esta página documenta el modelo de seguridad para el servidor MCP de ComStack: las amenazas que está diseñado para mitigar, los controles en capas sobre operaciones destructivas y los ganchos de monitorización operativa disponibles para los administradores del proyecto.

Modelo de amenazas

Amenaza	Mitigación
Recorrido de ruta o inyección mediante IDs suministrados por el llamador	Todos los identificadores suministrados se validan contra un patrón de lista blanca estricto en cada punto de entrada
Radio de explosión de proyecto incorrecto (publicar en el proyecto equivocado)	(a) `project_id` por herramienta con verificación de rol; (b) eco de `project_name` requerido en herramientas destructivas; (c) simulacro de `publish` + token `publish-confirm` vinculado a un hash de manifiesto
Reutilización de un token de actualización comprometido	Revocación de la familia de tokens de actualización tras uso duplicado: toda la familia se invalida si se reutiliza un token
Reutilización de una confirmación de publicación	Los tokens de confirmación son de un solo uso, con TTL de 5 minutos, vinculados a `(usuario, proyecto, hash_manifiesto)`. El servidor reconstruye el manifiesto al confirmar y rechaza si los borradores han cambiado
Escalada de privilegios mediante caché de roles obsoleta	El TTL de la caché de roles es de 30s; la caché de lista de herramientas filtradas es de 30s. Las revocaciones de roles surten efecto en un ciclo de caché
Fuga de argumentos sensibles al registro de auditoría	El registrador de auditoría redacta argumentos que coinciden con patrones de secreto, token, contraseña y clave, incluyendo `confirmation_token`, de forma recursiva
XSS mediante inyección en `metadata.head`	Lista blanca de etiquetas, atributos y protocolos; las entradas no permitidas se rechazan directamente
Exfiltración de CSS mediante `custom_css`	`@import`, `url()` fuera de origen, `:visited` y `expression()` se bloquean mediante una lista blanca de propiedades y fuentes
DoS por tamaño de cuerpo	Límite de 1 MB en todas las rutas API y MCP; límite de 10 MB en carga de imágenes
Fuerza bruta ante fallos de autenticación	Limitador de fallos por IP (10 por minuto)
Abuso de CORS	Lista blanca de orígenes explícita; los orígenes no permitidos no reciben cabeceras CORS
Llamadores Cloud-to-server suplantando un Origin de navegador	Validación explícita de `Origin` en `POST /mcp`. Las peticiones sin `Origin` pasan (servidor a servidor). Los orígenes no permitidos devuelven HTTP 403 antes de la autenticación
LLM escribe en la página incorrecta (colisión de slug)	`create-page` rechaza (a) un ID de documento existente y (b) otra página con el mismo `(slug, idioma)`. Ambos errores incluyen la ruta conflictiva y la acción de recuperación
Página publicada con metadatos mal formados	Validador de una sola pasada en cada `create-page` / `update-page`. Devuelve TODOS los problemas a la vez con valores permitidos, ejemplos y cadenas de corrección
Publicaciones concurrentes corrompiendo documentos	Bloqueo de publicación consultivo con TTL de 60s dentro de la transacción de promoción
Borradores traducidos publicados sin validar	La traducción escribe borradores; se ejecuta una validación de segunda pasada antes de la promoción
Claves API personales en servicios de larga duración	Las claves personales se rechazan en `/mcp` tras un periodo de gracia de 60 días; las claves de servicio son la ruta correcta a largo plazo para llamadores headless
Necesidad de revertir una mala publicación	`revert-publish` restaura el sitio desde la instantánea de publicación en menos de 1 hora

Defensa en profundidad: la ruta de publicación

Una sola llamada destructiva contra el proyecto equivocado afectaría al sitio en vivo del usuario. Cinco capas independientes deben alinearse antes de que se despliegue cualquier byte:

Token OAuth Bearer debe ser válido y no haber expirado.
Verificación de rol — el llamador debe tener al menos manager en el project_id suministrado. Escalera de roles (de menor a mayor): none → guest → member → manager → admin.
Eco de project_name — el project_name suministrado debe coincidir exactamente con el nombre almacenado del proyecto (sin distinguir mayúsculas, recortado). Llame a get-project-state primero para obtener el nombre exacto.
Simulacro de publish — publish devuelve un manifiesto y un token de confirmación pero no despliega. El agente muestra el manifiesto al humano para su revisión.
publish-confirm con token — el token es de un solo uso, con TTL de 5 minutos, vinculado a usuario + proyecto + hash de manifiesto. En el momento de la confirmación, el servidor reconstruye el manifiesto y rechaza si los borradores o el tema han cambiado desde el simulacro.

Si alguna capa rechaza, la publicación no se ejecuta.

Monitorización operativa

Registro de auditoría: cada llamada mutante exitosa o fallida se escribe en el registro de auditoría con una carga útil de argumentos redactada. Consulte a través del panel de control o la CLI. Los registros de auditoría nunca son legibles por el cliente; el servidor utiliza exclusivamente el SDK de administración.

Cloud Logging: filtre por [mcp] para la identidad por petición, [security] para activaciones del limitador de tasa y [promote] para transiciones de la máquina de estados de publicación.

Bloqueo de publicación: un documento de bloqueo está presente durante una publicación activa, con un campo expires_at. Los bloqueos obsoletos tras su expiración se eliminan automáticamente.

Errores comunes

Error	Causa	Solución
`403 project_name mismatch`	El `project_name` suministrado no coincide con el nombre almacenado	Llame a `get-project-state` y copie `project_name` exactamente
`403 insufficient role`	El rol del llamador es inferior al mínimo de la herramienta	Confirme que el llamador tiene al menos el rol `manager` en el proyecto
`409 publish_locked`	Otra publicación está en curso	Espere a que la publicación en curso finalice o confirme que el bloqueo ha expirado
`410 token expired`	El TTL del token de confirmación (5 min) ha expirado	Llame a `publish` de nuevo para obtener un token nuevo
`409 manifest_changed`	Los borradores cambiaron entre `publish` y `publish-confirm`	Llame a `publish` de nuevo para obtener un manifiesto que refleje el estado actual

Relacionado

Visión general del servidor MCP — catálogo de herramientas, enrutamiento de proyectos por herramienta y widgets de aplicaciones MCP
Instalación del servidor MCP — OAuth, clave API y métodos de conexión stdio
Análisis profundo de OAuth — PKCE, rotación de actualización, revocación de familia, estado del conector
Seguridad y protección de datos — cumplimiento de GDPR, residencia de datos, respuesta a incidentes para propietarios de sitios