Usos autorizados de navegadores multiperfil para QA, agencias y equipos de seguridad

Regla esencial: separa trabajo que ya está permitido

Un perfil puede mantener separados de otro contexto de trabajo las cookies, el almacenamiento, el historial, las extensiones, los permisos y los ajustes. Esa separación resulta útil cuando la actividad subyacente está autorizada. No concede derechos sobre una cuenta, un servicio, una red, una persona ni un conjunto de datos.

Antes de crear un perfil, deja explícita la cadena de autorización:

Pregunta	Pruebas que deben conservarse
¿Quién posee el sistema o la cuenta?	Organización identificada y contacto responsable
¿Quién autorizó el trabajo?	Contrato, declaración de trabajo, incidencia, plan de pruebas o reglas de actuación
¿Qué activos y cuentas están incluidos?	Entornos, orígenes, ID de cuentas y perfiles y exclusiones exactos
¿Qué acciones se permiten?	Lectura, publicación, pruebas, restablecimiento, invitación, exportación, automatización u otras operaciones identificadas
¿Qué datos pueden utilizarse?	Clasificaciones de datos sintéticos, de prueba, proporcionados por el cliente, personales, confidenciales y de conservación
¿Cuándo se aplica el permiso?	Inicio, caducidad, ventana de mantenimiento y vía de revocación
¿Qué necesita aprobación?	Acciones visibles desde el exterior, destructivas, masivas, que cambien accesos o generen gastos
¿Cuándo debe detenerse el trabajo?	Alcance incierto, datos inesperados, impacto en el servicio, acceso revocado o resultado desconocido

El acceso técnico no demuestra el permiso. Una sesión guardada puede seguir funcionando después de que un miembro deje el equipo o un cliente termine un contrato. El operador debe detenerse cuando se retire la autoridad, aunque el navegador todavía pueda abrir la cuenta.

Un patrón operativo compartido

Las mismas cinco etapas hacen responsables distintos flujos multiperfil.

1. Autorizar

Identifica al propietario del sistema, al cliente cuando corresponda, a los operadores, la finalidad permitida, los activos, las cuentas, las acciones, las fechas, el tratamiento de datos, las aprobaciones y las condiciones de detención. Un cliente puede autorizar trabajo sobre los activos que controla; no puede conceder derechos que no posee sobre otro servicio.

2. Preparar

Crea un perfil para el entorno, cliente, rol o caso de prueba concreto. Aplica solo las extensiones, el proxy, la configuración regional, los permisos y las credenciales necesarios. Prefiere la delegación que admite el servicio y las cuentas individuales frente a contraseñas compartidas o material de sesión copiado.

3. Ejecutar

Para un estado modificable, utiliza un operador o una carga atribuible cada vez. Impón límites de alcance, destino, concurrencia, tasa y coste. Muestra una vista previa de los cambios de gran impacto y vincula la aprobación al destino y a la acción exactos.

4. Registrar

Registra el actor, la carga delegada, la referencia del perfil, la acción, la aprobación, la hora, el destino, el resultado y las versiones pertinentes. Las indicaciones de OWASP sobre registros recomiendan capturar cuándo, dónde, quién y qué, a la vez que se protegen los registros y se excluyen los secretos técnicos. Mantén fuera de los registros corrientes cookies, contraseñas, tokens, credenciales de proxy y contenido de páginas sin procesar, además de datos personales innecesarios.

5. Recuperar y cerrar

Detén correctamente el perfil, verifica el estado esperado, conserva solo las pruebas aprobadas, revoca el acceso temporal y devuelve el perfil a su propietario. Si la ejecución termina en un estado desconocido, investiga antes de reintentar. Restaura una copia correcta conocida o pon en cuarentena el estado dañado, en vez de continuar de forma silenciosa.

Equipos de QA y localización

Límites útiles de perfiles

Los equipos de QA pueden utilizar perfiles separados para:

• estados anónimos, con sesión iniciada y de registro reciente;
• roles de administrador, editor, asistencia y usuario corriente;
• desarrollo, staging y pruebas de humo en producción aprobadas de forma explícita;
• combinaciones de configuración regional, idioma, zona horaria, combinación de colores y permisos;
• configuraciones con y sin extensiones;
• estado limpio del primer inicio y estado persistente actualizado deliberadamente; y
• participantes simultáneos en una situación multiusuario aprobada.

Playwright utiliza contextos aislados del navegador para que las pruebas reciban cookies, almacenamiento local y almacenamiento de sesión separados, y admite varios contextos para situaciones multiusuario. Su documentación sobre contextos también explica por qué partir de un estado limpio reduce la propagación de fallos. Es un patrón de pruebas útil, pero un perfil persistente de un producto y un contexto temporal de automatización pueden conservar estados diferentes. Registra cuál utiliza realmente la prueba.

Localización y pruebas regionales

Una matriz de localización repetible puede variar la configuración regional declarada, la zona horaria, la ventana gráfica, el método de entrada, la dirección del texto y los datos de prueba. Playwright documenta la emulación de configuración regional, zona horaria, geolocalización, combinación de colores y otros ajustes de contexto en su guía de emulación. Trata la emulación como una entrada controlada, no como prueba de que representa todos los dispositivos, redes, regiones jurídicas o experiencias reales.

Utiliza un proxy o una entrada de geolocalización solo cuando lo permitan el propietario de la red, el servicio de destino y el acuerdo de pruebas. Cambiar la ruta de red no concede derecho sobre contenido restringido por región ni permite eludir una decisión de acceso del servicio.

Las recomendaciones rápidas de internacionalización del W3C aconsejan UTF-8, declarar el idioma del documento, utilizar formatos de datos locales, ofrecer navegación visible de idiomas, aplicar una dirección de derecha a izquierda adecuada y validar. Convierte esos principios en comprobaciones observables, como:

• el idioma seleccionado persiste durante la navegación y la reautenticación;
• las fechas, horas, cifras, nombres, direcciones, criterios de ordenación y formas plurales utilizan la configuración regional prevista;
• el texto traducido puede expandirse sin truncarse ni ocultar controles;
• el contenido multilingüe y de derecha a izquierda conserva el orden de lectura y del foco;
• los formularios aceptan y devuelven los juegos de caracteres previstos; y
• los enlaces y mensajes de error siguen siendo comprensibles sin depender de una traducción automática.

Pruebas de accesibilidad

Mantén separados los estados de accesibilidad cuando mejore la reproducibilidad, pero no reduzcas la accesibilidad a un ajuste del perfil. Prueba el teclado, el foco, el zoom, los lectores de pantalla, las preferencias de contraste, el movimiento reducido, los errores y la autenticación accesible frente a WCAG 2.2. El resumen de evaluación del W3C indica que las herramientas ayudan, pero ninguna puede determinar por sí sola si un sitio es accesible; sigue siendo necesaria una evaluación humana informada.

Procedimiento de QA: comprobación de una versión regional

Autorización: el responsable del producto aprueba el origen de staging, dos roles de prueba, las configuraciones regionales compatibles, las fechas de prueba y las cuentas sintéticas.

Perfiles: un perfil limpio por cada par de rol y configuración regional, más otro perfil de actualización que conserve estado de la versión anterior.

Acciones: autenticarse mediante la vía de prueba compatible, ejecutar comprobaciones de navegación y formularios, inspeccionar el idioma y la accesibilidad, capturar los artefactos de prueba aprobados y detener correctamente cada perfil.

Pruebas: ID de la compilación, versión del navegador, entradas de configuración regional y zona horaria, rol, resultado de la prueba, detalles ocultos del error y referencias a los artefactos.

Condiciones de detención: origen de producción inesperado, datos reales de clientes, un permiso que exceda el rol asignado, degradación del servicio o una solicitud para exportar el estado de una sesión activa.

Agencias y operaciones de clientes

Límites útiles de perfiles

Las agencias pueden separar el trabajo por cliente, entidad jurídica, marca, entorno, servicio de destino y rol del operador. Esto puede reducir acciones accidentales entre clientes y aclarar los traspasos. El límite más fuerte combina la separación de perfiles con las funciones de organizaciones, roles y acceso delegado del servicio de destino.

Un flujo de agencia debe tener:

• una autorización vigente del cliente y un responsable nominal de este;
• un usuario compatible del servicio o un rol delegado para cada operador cuando esté disponible;
• un propietario del perfil y un estado de traspaso registrado;
• carpetas, etiquetas, extensiones, proxies y reglas de conservación específicos del cliente;
• aprobación para publicar, cambiar accesos, realizar acciones masivas, eliminar y gastar;
• un registro de auditoría visible para el cliente o propietario de la cuenta que corresponda;
• un proceso rápido para revocar, perder dispositivos, cambiar personal y terminar contratos; y
• un plan de exportación y eliminación acordado antes de incorporar al cliente.

Evita compartir credenciales sin procesar como mecanismo de colaboración. Cuando las herramientas de prueba o automatización guardan estado autenticado, protégelo como una credencial. Las indicaciones de Playwright sobre autenticación advierten de que el estado almacenado puede contener cookies y encabezados capaces de suplantar la cuenta y no debe incorporarse a repositorios.

Procedimiento de agencia: traspaso aprobado de contenido

Autorización: la declaración de trabajo identifica el sistema de contenidos controlado por el cliente, la marca, los operadores, las operaciones permitidas, el responsable de la aprobación y la fecha de finalización del contrato.

Perfiles: un espacio de trabajo del cliente con perfiles independientes de editor y publicador. Cada operador utiliza una identidad individual del servicio; el perfil del publicador no es un almacén compartido de contraseñas.

Acciones: el editor prepara un borrador, el sistema registra una vista previa y una revisión del contenido, el responsable nominal del cliente acepta la revisión exacta y el publicador la envía una vez.

Pruebas: actor, cliente, perfil, revisión del contenido, referencia de aprobación, destino, resultado del envío y hora. Los valores del contenido solo se conservan cuando lo permiten el acuerdo con el cliente y la política de datos.

Recuperación: si se pierde la respuesta después del envío, comprueba el sistema de destino antes de reintentar. Si termina el contrato, revoca el acceso, devuelve los registros aprobados y elimina o conserva los datos restantes del perfil según el acuerdo.

Límites que siguen estando prohibidos

El trabajo de clientes no justifica:

• crear cuentas, reseñas, interacciones o identidades falsas;
• enviar spam o mensajes masivos no solicitados;
• acceder a una cuenta después de que el cliente o propietario del servicio revoque el permiso;
• comprar, recopilar, reutilizar o compartir credenciales o sesiones robadas;
• ocultar quién realizó una acción ante una investigación autorizada;
• eludir controles de la plataforma para recuperar un acceso prohibido; ni
• actuar fuera de los derechos del cliente, la legislación aplicable o las condiciones del servicio.

Si una plataforma rechaza una acción, investiga la autorización y el proceso de negocio. No trates un perfil, proxy o vía de automatización como permiso para eludir la decisión.

Equipos de seguridad y respuesta ante incidentes

El alcance escrito es lo primero

Los equipos de seguridad necesitan algo más que una solicitud general de «probar el sitio». NIST SP 800-115 ofrece indicaciones para planificar y realizar pruebas técnicas de seguridad, analizar los resultados y desarrollar mitigaciones. NIST define las reglas de actuación como restricciones establecidas antes de la prueba que dan autoridad al equipo para realizar actividades definidas.

Las reglas de actuación deben identificar:

• hosts, aplicaciones, API, tenants y cuentas exactos incluidos;
• servicios de terceros y dependencias de producción expresamente excluidos;
• técnicas y herramientas permitidas;
• redes o dispositivos de origen de las pruebas cuando corresponda;
• horario y límites de tasa, concurrencia e impacto en el servicio;
• cuentas y roles de prueba y datos aprobados;
• acciones prohibidas, como la persistencia, la ingeniería social, los cambios destructivos o la denegación de servicio;
• tratamiento, cifrado, acceso, conservación y destrucción de las pruebas;
• contactos de incidentes y emergencias;
• condiciones de detención inmediata; y
• expectativas de informes, corrección, nuevas pruebas y divulgación.

Si la demostración exige un acceso o impacto que exceda esas reglas, detente y obtén autorización escrita antes de continuar.

Límites útiles de perfiles

Dentro de una evaluación autorizada, los perfiles separados pueden aislar:

• el cliente A del cliente B;
• las identidades del evaluador de la navegación personal corriente;
• cada rol o tenant de prueba;
• la validación pasiva de las pruebas activas aprobadas;
• un estado de referencia limpio de otro modificado para la prueba;
• las pruebas de respuesta ante incidentes del trabajo operativo continuado; y
• el estado de las nuevas pruebas del resultado original.

Utiliza perfiles para proteger el alcance y las pruebas, no para ocultar el origen o la finalidad de la evaluación. No rotes perfiles, redes ni identidades para eludir límites de tasa, bloqueos u otros controles, salvo que el propietario del sistema haya incluido expresamente ese comportamiento en las reglas de actuación.

Procedimiento de seguridad: regresión autorizada del control de acceso

Autorización: el propietario enumera la aplicación de staging, dos tenants de prueba, roles corrientes y de administrador, las solicitudes permitidas, el límite de tasa, la ventana y el contacto de emergencia. Se excluyen la producción y la infraestructura de identidad de terceros.

Perfiles: un perfil limpio para cada rol y tenant aprobados. Cada uno contiene datos sintéticos y una identidad de prueba emitida por el servicio.

Acciones: verifica que cada rol alcanza los recursos esperados y después ejecuta los casos negativos aprobados que confirman la denegación de otros roles y tenants. Utiliza el menor número de solicitudes necesario para reproducir un resultado.

Pruebas: versiones de la aplicación y el navegador, caso de prueba, actor, referencias al tenant y rol, ID de correlación de solicitudes, pruebas de respuesta ocultas, hora y resultado. No conserves registros ajenos que encuentres durante la prueba.

Condiciones de detención: aparecen datos personales o de producción, el servicio se vuelve inestable, una prueba sale del tenant enumerado, se exponen credenciales fuera del conjunto de pruebas o el propietario retira la autorización.

Recuperación: detén las solicitudes activas, avisa al contacto nominal, conserva las pruebas protegidas mínimas, revoca las credenciales de prueba, restaura el estado de prueba y documenta si es seguro volver a probar.

El permiso tiene varias capas

Utiliza esta tabla cuando la autorización no esté clara:

Situación	Decisión
Tu empresa posee el sistema de staging, el plan de pruebas identifica la cuenta y las acciones, y el operador tiene el rol asignado	Continuar dentro de los límites documentados
Un cliente pide a una agencia administrar una cuenta mediante los roles compatibles del servicio y el contrato cubre el trabajo	Continuar con controles de acceso nominal, aprobación, auditoría y baja
Un cliente solicita acceso a una cuenta de terceros que no posee ni controla	Detenerse; el cliente no puede conceder ese permiso
Un contacto de seguridad ofrece un apoyo general pero no una lista de activos ni alcance de las pruebas	Detenerse; obtener reglas de actuación por escrito
Una sesión válida permanece después de que una persona deja el equipo	Detenerse y revocarla; el acceso técnico ha sobrevivido a la autorización
Una prueba encuentra credenciales reales o datos personales fuera del conjunto aprobado	Detenerse, minimizar el acceso, proteger las pruebas y avisar al contacto designado
Una plataforma bloquea una acción y se propone responder rotando perfiles o proxies	Detenerse; no utilizar el aislamiento para eludir controles
Un flujo crea interacciones falsas, spam, fraude, phishing, robo de credenciales o acceso no autorizado	Prohibido

Lo que la separación de perfiles no puede establecer

El límite de un perfil puede reducir la mezcla accidental de estado. No puede demostrar por sí solo que:

• el operador está autorizado;
• la identidad de la cuenta es genuina;
• el navegador representa otro dispositivo físico;
• una configuración regional simulada representa a un residente o un derecho regional legítimo;
• un proxy autoriza el acceso desde su ubicación aparente;
• las extensiones o el endpoint son fiables;
• un sitio web aceptará la sesión; ni
• una prueba de seguridad está dentro del alcance.

Trata el perfil como un control dentro de un sistema más amplio de identidad, autorización, tratamiento de datos, auditoría, recuperación, contratos y revisión humana. Cuando alguna de esas capas no esté clara, operar con seguridad significa detenerse y resolver la ambigüedad antes de continuar.