# Security Hardening Review: Migración de sesiones v2

## Evidence Basis

Esta revisión deriva de inspección directa del bridge, de sus clientes y de referencias de solo lectura en la raíz externa de proyectos indicada en el [registro de evidencia](context.md). Ese registro distingue consumidores confirmados, enlaces que solo apuntan al bridge e incertidumbres fuera del alcance local. No es un informe de implementación: no se ha retirado ni rotado ninguna credencial.

## Constraints

- Mantener operativas todas las aplicaciones vecinas y clientes no navegador.
- No modificar otros proyectos desde este trabajo.
- Evitar secretos en URL, frontend, logs y documentación.
- Preservar acceso por Tailscale y preparar HTTPS sin asumir todavía el mecanismo.
- Poder revertir por fases y observar qué consumidor sigue usando la cabecera.
- No existe revisión Git fiable del snapshot; cualquier implementación futura deberá repetir el control de drift.

## Opportunity Portfolio

| Opportunity | Evidence | Options | Recommendation | Proposal |
| --- | --- | --- | --- | --- |
| Centralizar y segmentar la sesión del bridge | Frontera compartida, 12 clientes web heredados, Telegram/pruebas y portal LAB externo (`E001`–`E013`) | 1. Compatibilidad endurecida; 2. Migración gradual por capacidades; 3. Corte global inmediato | Opción 2, condicionada a inventario operativo y HTTPS | [Propuesta completa](proposals/centralize-bridge-session.md) |

## Recommendation Summary

Recomiendo la migración gradual por capacidades. Conserva temporalmente `X-Bridge-Token` solo para clientes identificados, mientras los navegadores pasan a una sesión persistente y los servicios reciben credenciales propias, revocables y de alcance mínimo. La retirada global solo debe ocurrir cuando la telemetría confirme cero uso heredado durante una ventana acordada.

El corte inmediato ofrece el estado final más simple, pero hoy rompería al menos el portal LAB de `xzonassite`, Telegram y herramientas de verificación. Mantener el token raíz indefinidamente es compatible, aunque conserva un radio de impacto excesivo.

## Next Decisions

Antes de crear `implementation/` necesitamos decidir:

- qué clientes no navegador deben sobrevivir y quién es su propietario;
- si el HTTPS se resolverá con Tailscale Serve, reverse proxy local u otro terminador;
- duración de sesión, persistencia tras reinicio y política de revocación;
- ventana de observación y relogin;
- si el portal LAB puede migrar a una credencial de servicio limitada;
- si existe Tailscale Funnel o algún acceso público que deba cerrarse o aislarse.