El coste y la seguridad: no dejarlas abiertas en producción

Las cuatro lecciones anteriores han sido un elogio razonado de la observabilidad: el diff, el historial, el salto en el tiempo, la sesión reproducible. Esta es la contrapartida, y sería deshonesto cerrar el nivel sin ella. Todo lo que hace valiosa esta herramienta —que conserve el pasado en lugar de destruirlo, que serialice cada intención con sus datos, que permita exportar una sesión entera a un fichero— es exactamente lo que la vuelve peligrosa cuando se queda encendida donde no debe. Un historial es un archivo, y un archivo de una aplicación real contiene, casi siempre, más información personal de la que su equipo recuerda haber puesto ahí.

El coste antes que el riesgo

Empecemos por lo mensurable. Guardar el historial significa retener en memoria el estado inicial y una entrada por cada acción despachada, con su payload y, según la configuración, una fotografía del estado resultante. En una aplicación pequeña eso es irrelevante; en un panel con listados grandes y sesiones de horas, el crecimiento es lineal y se nota. El síntoma habitual no es que la aplicación se caiga, sino que la propia extensión se vuelve lenta y el navegador dedica una fracción visible de su tiempo a serializar objetos que nadie va a mirar.

El coste en tiempo de ejecución tiene tres fuentes. La primera es la serialización de cada acción y cada estado para enviarlos a la extensión, proporcional al tamaño del árbol. La segunda es el cálculo del diff, que compara dos árboles completos. La tercera, y con diferencia la más cara, es la captura de la pila de llamadas cuando trace está activo, porque generar una traza en cada dispatch cuesta órdenes de magnitud más que despacharla. Ninguna de las tres es problema en desarrollo; las tres serían inaceptables en producción, y esa es la primera razón, la menos grave, para no dejarlas encendidas.

Hay un cuarto coste, indirecto y curiosamente positivo, que conviene nombrar: la instrumentación castiga de forma proporcional al tamaño del estado y al número de acciones, de modo que una aplicación cuyo store va lento con las DevTools abiertas te está informando de algo aunque no lo hayas preguntado. Casi siempre significa que estás guardando en el estado más de lo que deberías o despachando con más frecuencia de la necesaria. La extensión funciona así como un detector accidental de un mal diseño que en producción no se notaría hasta mucho más tarde.

Qué queda expuesto y ante quién

Ahora el riesgo, que es de otra categoría. Conviene ser preciso sobre el modelo de amenaza, porque el error opuesto —tratar esto como una catástrofe inminente— lleva a conclusiones igual de malas. El estado de una aplicación cliente vive, por definición, en la máquina del usuario, y quien controla esa máquina siempre ha podido examinarlo con las herramientas del navegador. La integración de las DevTools no crea ese acceso: lo hace cómodo, completo e histórico, y son esos tres adjetivos los que cambian el cálculo. Que algo fuera técnicamente accesible no significa que fuera práctico, y la diferencia entre lo accesible y lo práctico es, en seguridad, casi toda la diferencia.

flowchart TD
S[estado y acciones] --> H[historial retenido en memoria]
H --> A[cualquiera con acceso al dispositivo]
H --> B[capturas de pantalla y grabaciones de soporte]
H --> C[exportacion a fichero JSON]
C --> D[el fichero viaja en un ticket o un chat]
D --> E[queda almacenado fuera de tu control]
style E fill:#f38ba8,color:#11111b
style A fill:#fab387,color:#11111b

Hay además una asimetría temporal que agrava el problema. Una petición de red expone un dato durante el instante en que viaja; el store lo expone mientras la pestaña viva; el historial lo expone durante toda la sesión aunque la pantalla que lo mostraba se cerrara hace una hora. Un token que se usó al arrancar y que ya nadie necesita sigue estando en la entrada número tres del monitor, y seguirá estando en cualquier exportación que se haga al final del día. La observabilidad convierte lo efímero en permanente, y esa conversión es precisamente lo que había que evaluar.

El riesgo grande no es el atacante remoto: es el flujo cotidiano por el que ese historial acaba en sitios que nadie eligió. Una persona de soporte pide una captura del monitor y en ella aparece el token de sesión. Un usuario exporta la sesión para adjuntarla a un ticket y ese fichero, con su correo, su dirección y el detalle de sus pedidos, queda archivado en un sistema de incidencias con permisos amplios. Un desarrollador reproduce ese fichero en su portátil y la copia se queda ahí durante meses. Ninguno de esos pasos es un ataque; todos son personas haciendo su trabajo, y el resultado es información personal circulando fuera del perímetro donde estaba protegida.

Apagar de verdad y redactar en el origen

La práctica correcta tiene dos mitades, y solo la primera es la que todo el mundo conoce. La primera es apagar la integración en producción, que en Redux Toolkit ocurre por defecto pero conviene verificar en lugar de suponer, sobre todo si alguien tocó el parámetro devTools o si la variable de entorno no es la que crees en el proceso de compilación. La verificación es directa: abre la aplicación desplegada con la extensión instalada y comprueba que no aparece ninguna instancia.

Conviene añadir a esa verificación manual una automática, porque los apagados se rompen en silencio. Los tres puntos donde falla en la práctica son siempre los mismos: una variable de entorno que en el empaquetador no vale lo que se supone, un enhancer remoto añadido para depurar un dispositivo y nunca retirado, y un entorno de preproducción que comparte configuración con desarrollo pero base de datos con producción. El tercero es el más peligroso de los tres porque combina instrumentación encendida con datos reales, y es también el que ninguna revisión de código detecta, porque el código es correcto y lo que está mal es dónde corre.

La segunda mitad, que casi nadie hace, es asumir que el apagado no cubre todos los casos y redactar los campos sensibles en el origen. Hay razones sólidas: los entornos de preproducción con datos reales suelen tener la instrumentación encendida; el registro casero de la lección tercera envía acciones aunque la extensión esté apagada; y las capturas de pantalla que se piden en soporte se toman en cualquier entorno. Las DevTools admiten funciones de saneado que se aplican antes de enviar cada acción y cada estado.

const REDACTADO = '[redactado]'

const sanearAccion = (accion) =>
  accion.type === 'sesion/entrar'
    ? { ...accion, payload: { ...accion.payload, token: REDACTADO } }
    : accion

const sanearEstado = (estado) => ({
  ...estado,
  sesion: { ...estado.sesion, token: REDACTADO },
  perfil: { ...estado.perfil, email: REDACTADO, telefono: REDACTADO },
})

export const store = configureStore({
  reducer: raiz,
  devTools: import.meta.env.DEV && {
    name: 'panel',
    actionSanitizer: sanearAccion,
    stateSanitizer: sanearEstado,
  },
})

Ese saneado tiene una limitación importante que hay que enunciar: solo afecta a lo que se envía a la extensión, no a lo que hay en memoria. El token sigue en el store y sigue siendo accesible por otras vías. Por eso el saneado es una mitigación, no una solución, y la solución de fondo es la política de la sección siguiente: los secretos no deberían estar en el estado.

Conviene además fijar el criterio de qué se redacta y cómo, porque redactar de más inutiliza la herramienta. El principio correcto es sustituir el valor conservando la forma: un correo se convierte en una marca fija pero no desaparece, de modo que el diff sigue mostrando que ese campo cambió y el diagnóstico no se pierde. Lo que nunca hay que hacer es eliminar la clave entera, porque entonces el historial miente por omisión y acabas depurando una representación que no se corresponde con el estado real.

Convertir la política en una prueba

Una política que solo vive en la cabeza del equipo se erosiona con el primer campo nuevo que alguien añade a una respuesta del servidor. La forma de que aguante es convertirla en algo que falle solo, y aquí la estructura del estado juega a favor: como el árbol es un dato plano y serializable, se puede recorrer y comprobar en una prueba.

const PROHIBIDAS = ['token', 'password', 'iban', 'dni', 'email']

function clavesSensibles(nodo: unknown, ruta = ''): string[] {
  if (nodo === null || typeof nodo !== 'object') return []
  return Object.entries(nodo).flatMap(([k, v]) =>
    PROHIBIDAS.includes(k.toLowerCase())
      ? [ruta + '.' + k]
      : clavesSensibles(v, ruta + '.' + k),
  )
}

test('el estado no contiene campos prohibidos', () => {
  expect(clavesSensibles(store.getState())).toEqual([])
})

Esa prueba es tosca a propósito y por eso funciona. No pretende ser un análisis de privacidad completo, sino una alarma barata que salta el día en que alguien guarde en el store la respuesta entera de un extremo nuevo con un campo email dentro. Aplicada sobre el estado que resulta de replegar una sesión de prueba realista, cubre más superficie de la que parece, y su verdadero valor no es técnico sino social: obliga a que cada excepción se discuta y se anote en vez de colarse en silencio.