Borrar los datos del sitio sin cruzar los límites de una cuenta
Qué elimina el borrado de datos del sitio, qué permanece y cómo proteger las sesiones al cerrar sesión o cambiar de cuenta.
Quieres la documentación estructurada de Identidad?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Respuesta breve
Borrar los datos del sitio es un reinicio útil, pero no equivale a cerrar una cuenta ni a eliminar los registros de un servicio. El navegador puede conservar cookies, localStorage, sessionStorage, bases de datos IndexedDB, entradas de Cache Storage, registros de service worker, permisos y caché HTTP. El servicio también puede mantener una sesión autenticada en el servidor. El estándar Clear-Site-Data define una cabecera que un origen puede solicitar, pero el navegador decide cómo aplicarla.
El modelo correcto tiene tres límites: estado del navegador, estado de la cuenta de la aplicación y registros del servicio. Cerrar sesión termina la sesión del servidor. La limpieza elimina el estado local seleccionado para que una cuenta anterior no vuelva a aparecer. Las copias de seguridad, otros dispositivos y otros orígenes quedan fuera. La referencia de MDN sobre Clear-Site-Data y la API StorageManager describen observaciones y límites, no un borrador universal.
Qué se considera dato del sitio
Las cookies viajan automáticamente en solicitudes HTTP que coinciden con sus atributos. Eliminar una cookie puede impedir que el navegador presente un identificador, pero el servidor debe revocar o caducar la sesión. localStorage suele sobrevivir al cierre de una pestaña; sessionStorage está ligado a un contexto superior y normalmente termina al cerrarlo. Ninguno viaja solo, aunque el código de la aplicación puede copiar sus valores a una solicitud.
IndexedDB guarda datos estructurados para bases locales, colas y funciones sin conexión. Cache Storage suele estar administrado por un service worker y una caché antigua puede sobrevivir a una actualización o a un cierre de sesión. Los registros del worker, los permisos y la caché HTTP tienen ciclos distintos. La guía del modelo de almacenamiento compara estos mecanismos y la guía del ciclo de caché del service worker explica la propiedad y la limpieza de cachés.
Clear-Site-Data pertenece a un origen
La cabecera Clear-Site-Data procede de un origen y sus directivas, como "cache", "cookies", "storage" y "executionContexts", describen categorías que el agente de usuario puede limpiar. El soporte varía entre navegadores y versiones. Una respuesta de cuentas.example no puede borrar datos de un origen ajeno ni de un servicio incrustado.
Por eso la cabecera es una petición, no una prueba. Registra el navegador, las directivas, el origen y el resultado observado. "storage" no elimina bases de datos del servidor, copias de seguridad, otros dispositivos ni toda memoria de una aplicación. Combina la cabecera con código explícito de limpieza y una acción de sesión en el servidor.
Cerrar sesión y cambiar de cuenta
Invalida primero la sesión del servidor, después elimina el estado local específico de la cuenta y reinicia el estado en memoria. Si falla la acción del servidor, muestra un error y no presentes la cuenta como cerrada. Una pestaña adicional puede seguir mostrando una vista antigua; notifica a las demás pestañas, rechaza respuestas obsoletas y vuelve a comprobar la sesión antes de escribir.
Un cambio de cuenta tiene el mismo riesgo aunque no exista un botón de cierre. El perfil continúa abierto, así que hay que borrar o aislar tokens, respuestas en caché, borradores, bases IndexedDB, colas sin conexión y cachés del worker antes de cargar la segunda cuenta. Recargar una página no realiza limpieza.
El control visible debe decir qué ocurrirá, por ejemplo: “Cerrar sesión en este dispositivo y eliminar los datos guardados de esta cuenta”. No prometas borrar la cuenta del proveedor, el historial del servidor o datos de otro origen desde un control del navegador.
Eliminación parcial y recuperación
La limpieza puede ser parcial: una operación puede estar bloqueada, una directiva puede no estar implementada o la aplicación puede olvidar un almacén. Trata la ausencia de estado como una entrada normal y ofrece una pantalla de acceso, una descarga nueva o una recuperación explícita. No deduzcas la identidad por la presencia de una clave.
Después de limpiar, la siguiente solicitud debe demostrar el límite: el servidor exige una sesión válida y el cliente reconstruye el estado desde una respuesta aprobada. Una cola sin conexión puede pertenecer a la cuenta anterior; pausa o descarta sus cambios según una política documentada y nunca los envíes bajo la cuenta siguiente. Registra resultados mínimos sin cookies, tokens ni contenido.
Contextos aislados para pruebas autorizadas
BotBrowser proporciona BrowserContexts separados con cookies, almacenamiento y estado de sesión aislados, y permite probar cierres y cambios de cuenta autorizados. BotBrowser no puede controlar la respuesta Clear-Site-Data, el código de limpieza del sitio, la invalidación del servidor, la expulsión del navegador ni los registros fuera del contexto. La documentación de aislamiento de múltiples cuentas describe la capacidad.
Para una revisión, crea dos contextos con datos sintéticos, registra el navegador y los almacenes esperados, cierra sesión en el primero y comprueba que su siguiente solicitud requiera autenticación. Verifica que el segundo conserve su propia sesión. Cierra los contextos al terminar y conserva solo resultados de aprobado o fallido; el aislamiento de prueba no demuestra que el servicio haya borrado sus datos.
Lista práctica de limpieza
- Inventaría cookies, Web Storage, IndexedDB, Cache Storage, workers, permisos, caché HTTP, memoria y colas sin conexión.
- Asigna propietario, duración y clasificación de cuenta a cada elemento.
- Invalida la sesión del servidor y luego limpia el estado local; avisa a otras pestañas y workers.
- Registra directivas, versión del navegador y resultado de
Clear-Site-Data; prepara un mecanismo de reserva para cobertura parcial. - Haz que la siguiente navegación requiera autenticación y muestra un inicio limpio o una recuperación documentada.
- Repite con dos pestañas, cambio de cuenta, actualización del worker y un segundo contexto autorizado.
Los marcos incrustados pueden pertenecer a otro origen y administrar sus propias cookies y almacenes. La página principal no debe prometer que una limpieza propia borra ese servicio.
Clasifica cada valor como credencial, preferencia visual, cambio sin conexión o recurso público. La categoría determina si se revoca, se elimina, se conserva o se crea de nuevo.
Una cookie caducada no equivale a una sesión revocada. El servidor debe rechazar un identificador reutilizado según su política de autenticación.
La limpieza debe ser idempotente. Ejecutar dos veces la salida debe producir el mismo estado seguro aunque falte una base, una caché o un worker.
Comprueba el worker activo y su versión cuando cambie la limpieza. Un worker antiguo puede interceptar una descarga aparentemente nueva.
No uses la existencia de almacenamiento para descubrir una cuenta. El navegador puede haberse restaurado, compartirse o haber sufrido una expulsión.
Los mensajes de conservación deben separar la eliminación local de la retención del servicio. Así la persona puede solicitar la acción adecuada.
El equipo de soporte necesita origen, versión del navegador, directivas solicitadas y resultado de la siguiente solicitud, no valores privados.
Las sesiones sin contraseña, las cookies de dispositivo recordado y las cargas temporales necesitan el mismo propietario y una respuesta cuando faltan.
Si varios roles comparten perfil, usa contextos separados o una política explícita. Un selector visual de cuenta no aísla el almacenamiento.
Prueba también una operación bloqueada. Cuotas, políticas privadas y ajustes administrados pueden impedir un almacén que antes funcionaba.
Usa datos de prueba sintéticos y evita credenciales reales en los registros de limpieza.
Antes de limpiar, explica si la aplicación recargará, volverá al inicio de sesión o conservará una preferencia no sensible.
La guía de partición del almacenamiento ayuda cuando un marco incrustado cambia según el sitio superior; la partición no sustituye la limpieza de la cuenta.
Las políticas de privacidad pueden impedir una operación aunque el código sea correcto. El resultado debe quedar como un caso de reserva, no como una identidad nueva.
El propietario del origen debe decidir cuánto tiempo conservar datos de diagnóstico y quién puede leerlos.
Una respuesta vacía puede ser válida después de salir. La interfaz debe diferenciarla de una respuesta dañada o de una cuenta inexistente.
El servidor debe comprobar el estado en cada operación sensible, no solo al cargar la primera página.
Las preferencias no sensibles pueden sobrevivir si se explican; los tokens y las respuestas privadas necesitan un final claro.
Una actualización de esquema debe probar el camino de datos ausentes antes de publicarse.
El equipo debe repetir la prueba cuando cambien atributos de cookie, código de caché o reglas de sesión.
El registro de prueba puede guardar categorías y resultados, pero no valores de cuentas.
Los usuarios de un dispositivo compartido necesitan una acción visible y reversible cuando sea posible.
La limpieza de un origen no debe presentarse como borrado legal o contractual de una cuenta.
Una cola pendiente necesita una decisión explícita durante cada cambio de cuenta.
La documentación de soporte debe indicar quién es responsable del navegador, la aplicación y el servidor.
Preguntas frecuentes
¿Borrar las cookies elimina la cuenta?
No. Elimina cookies seleccionadas. La cuenta, los registros del servidor y las sesiones de otros dispositivos permanecen hasta que el servicio los gestione.
¿Clear-Site-Data: "*" borra todo?
No existe esa garantía universal. Sigue limitado al origen y a la implementación del navegador. Prueba los navegadores admitidos y explica qué se verificó.
¿Un contexto nuevo equivale a borrar datos?
No. Es un punto de partida aislado para una prueba autorizada, no una orden para borrar el servidor u otros orígenes.
¿Puede un trabajador de servicio restaurar datos?
Sí, si conserva respuestas en caché o estado en memoria. Versiona las cachés, limita los datos de cuenta y verifica la siguiente solicitud después del cierre.
¿Qué ve la persona si falla la limpieza?
Una pantalla de acceso, un reintento o una recuperación honesta. No afirmes que se borró todo si el servicio no terminó su propia invalidación.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.