Seguridad.

Nausika se toma la seguridad en serio. Esta página es el lugar de referencia para investigadores de seguridad, personas que desarrollan clientes de IA y usuarios conectados, para entender cómo notificar una vulnerabilidad, qué respuesta esperar y qué entra o queda fuera del alcance. El contacto legible por máquina vive en /.well-known/security.txt.

Notificar una vulnerabilidad

Escribe a [email protected] con el mayor detalle posible: el endpoint o herramienta afectado, una receta de reproducción, el impacto observado y si crees que la vulnerabilidad es explotable en producción. Acusamos recibo de cada reporte en 2 días hábiles.

De momento no ofrecemos cifrado PGP. Manda el correo en claro y, si el reporte contiene material sensible en tránsito, te contactaremos para coordinar un canal seguro. No tenemos bug bounty remunerado.

Por favor, no pruebes vulnerabilidades de un modo que degrade el servicio para otros usuarios (denegación de servicio, escaneo automatizado de alta frecuencia, intentos de acceder a datos de otros usuarios). Si encuentras un problema usando Nausika con normalidad y lo descubres por casualidad, perfecto — notifícalo.

SLA de respuesta a parches

La severidad la evalúa la persona mantenedora en diálogo con quien reporta, según criterios de triaje estándar (razonamiento estilo CVSS, enfocado en el impacto real para el modelo de datos y la superficie de amenaza de Nausika).

• Crítica — ejecución remota de código, bypass de autenticación en el endpoint MCP, exfiltración de datos cross-tenant, toma de control de una cuenta existente: parche en 7 días; hotfix en mcp.nausika.app el mismo día cuando sea factible.
• Alta — escalada de privilegios (por ejemplo usuario → admin), fuga de datos sensibles (tokens OAuth, cookies de sesión), inyección persistente (stored XSS en admin UI): parche en 14 días.
• Media — denegación de servicio por una sola llamada, divulgación de información no personal, inyección reflected: parche en 30 días.
• Baja — desviaciones de buenas prácticas sin exploit demostrable, endurecimiento, problemas teóricos: atendidos en una release regular, en general en 90 días.

Divulgación coordinada

Preferimos la divulgación coordinada. Una vez confirmada la vulnerabilidad, pedimos a quien reporta que retenga la publicación pública al menos 30 días desde la confirmación (o hasta que el parche esté desplegado, lo que ocurra antes), para que los usuarios conectados no queden expuestos a explotación en producción antes de tener un arreglo disponible.

Daremos crédito a quien reporta en /log al divulgar, salvo petición en contra. Los reportes anónimos son bienvenidos y los tratamos con la misma disciplina de triaje que los demás.

Versiones soportadas

Nausika se sirve desde un único endpoint público en mcp.nausika.app, desplegada desde la build más reciente de main. Solo se da soporte a la versión actualmente desplegada; no hay ramas paralelas de mantenimiento ni distribuciones on-premise. Cuando sale un parche, sale para todo el mundo a la vez.

Forks self-hosted o despliegues no oficiales quedan fuera del alcance del SLA anterior — el código fuente es privado y no lo distribuimos por ahora.

Fuera de alcance

• Vulnerabilidades en servicios de terceros de los que dependemos — Railway, Cloudflare, Resend, GitHub OAuth, Google OAuth, Open-Meteo, NOAA, Wikimedia, OpenStreetMap. Reporta directamente al proveedor; si el problema está en cómo Nausika se integra con ellos (por ejemplo un control de redirect-URI ausente de nuestro lado), entonces sí entra.
• Reportes que requieren acceso físico al dispositivo del usuario o un navegador/OS comprometido, salvo que un comportamiento específico de Nausika empeore la situación.
• Falta de rate-limit en endpoints de solo lectura por debajo de los límites de servicio documentados — se tratan como trabajo de rendimiento, no de seguridad.
• "Findings" de buenas prácticas sin impacto demostrable (cabeceras de seguridad ausentes en activos estáticos, divulgación de versión de bibliotecas de terceros que ya parcheamos con cadencia regular, etc.) — los leemos y consideramos, pero no califican para el SLA anterior.

Qué protegemos, en términos llanos

Dos clases distintas de activos guían nuestro triaje:

• Datos de usuario — tu email de cuenta, tokens OAuth, perfil de barco, derrotas guardadas, valoraciones, favoritos, propuestas enviadas. El acceso cross-tenant a cualquiera de estos se trata como crítico.
• Datos públicos pero curados — lugares, atributos, metadatos de atribución, imágenes. La manipulación que afecta a lo que ven otros usuarios (por ejemplo escrituras no autorizadas en places) se trata como alta; el acceso en lectura es abierto por diseño.

Nausika no almacena datos de pago, sanitarios, documentos de identidad ni biométricos. Ver Privacidad para el modelo completo y la política de retención.

Postura de endurecimiento

Para transparencia: lo que hacemos de continuo, no como reacción a reportes concretos.

• OAuth 2.1 con PKCE para clientes públicos; tokens bearer opacos almacenados con hash (ningún secreto JWT que pueda fugarse).
• Validación anti-SSRF en cada fetch desde URLs aportadas por el usuario (proxy de imágenes, propuestas de lugar).
• Allow-list CORS estricta en el endpoint MCP; requisito same-origin en los iconos del conector según la spec MCP.
• Acceso a la base de datos estrictamente con consultas parametrizadas (tagged template literals); ninguna SQL concatenada en código request-scoped.
• Retención de 90 días en los logs completos de petición, 30 días en los logs operativos, limpieza automática vía job programado. Ver Privacidad.
• Schema-version guard en el servicio MCP: el conector público se niega a arrancar contra una base de datos más antigua que el esquema que espera, evitando despliegues en estado inconsistente.

Mantenimiento y retrocompatibilidad

Los parches de seguridad a veces requieren cambios incompatibles. Cuando ocurre, seguimos las reglas de aviso descritas en la roadmap: 60 días de aviso en /log para cambios de interfaz incompatibles, con la excepción de explotación activa, donde publicamos la corrección de inmediato y explicamos el cambio a posteriori.

El compromiso más amplio para mantener Nausika — disponibilidad del servicio, aviso de cierre, log público — vive en la roadmap.