Cómo evaluar un navegador para equipos: una lista de comprobación práctica

Define la decisión antes de abrir una página de precios

Una evaluación útil empieza por el trabajo, no por la lista de proveedores. Anota:

• los flujos autorizados y los sistemas que los permiten;
• el número de personas, perfiles guardados, perfiles sincronizados y sesiones simultáneas del navegador;
• los sistemas operativos y las arquitecturas de procesador compatibles;
• los motores, extensiones, proxies, proveedores de identidad y clientes de automatización necesarios;
• las obligaciones de residencia, conservación, exportación, eliminación y auditoría de los datos;
• los objetivos de tiempo de recuperación y pérdida aceptable de datos;
• las necesidades de accesibilidad de operadores y administradores;
• el presupuesto, periodo de facturación, cobertura de asistencia y condiciones de salida; y
• los flujos prohibidos que el producto no debe permitir a tu equipo.

Mantén separados los tipos de recursos. Un plan con 500 perfiles guardados, 100 sincronizados en la nube, cinco puestos y diez sesiones simultáneas no ofrece 500 sesiones simultáneas para el equipo. Convierte cada límite en la unidad que consume tu flujo.

Después identifica los requisitos no negociables. Un conjunto habitual es:

1. compilaciones compatibles y actuales del navegador;
2. ausencia de daños silenciosos en perfiles y de escritores simultáneos;
3. identidades individuales con acceso revocable y de privilegios mínimos;
4. ausencia de secretos sin procesar en registros y salidas de automatización normales;
5. pruebas de auditoría utilizables;
6. una vía probada de restauración y salida; y
7. uso lícito y autorizado conforme a las condiciones aplicables de los servicios.

No ocultes un requisito fallido dentro de una puntuación media. Una interfaz pulida no compensa un actualizador sin verificar ni una restauración que pierda estado.

Utiliza una escala de pruebas sencilla

Para cada punto de la lista, registra el resultado y la prueba más fuerte obtenida.

Resultado

• Superado: el requisito declarado se demostró en el entorno de prueba definido.
• Preocupación: el comportamiento entra en conflicto con el requisito o crea una contrapartida importante.
• No verificado: las pruebas faltan, no son accesibles, están obsoletas o resultan demasiado ambiguas para decidir.
• No aplicable: el requisito realmente no se aplica al flujo y se registra el motivo.

Prueba

1. Afirmación publicada: texto comercial o de ventas.
2. Documentación técnica: documentación versionada del producto, seguridad, API o asistencia.
3. Demostración observada: una demostración en directo del proveedor con tu situación.
4. Prueba controlada: tu equipo reproduce el comportamiento con datos desechables y registra versiones y resultados.
5. Prueba independiente o contractual: una evaluación acotada, un compromiso firmado o una condición de asistencia que cubra el requisito.

Una prueba de nivel superior no siempre es mejor. Un informe independiente puede excluir el navegador de escritorio, mientras que una prueba controlada puede ejercitarlo directamente. Registra el alcance, la fecha, la versión y las limitaciones de cada artefacto.

1. Estado del producto y límites de las afirmaciones

• □ ¿Existe una compilación real e instalable para cada plataforma y arquitectura que necesitas?
• □ ¿Puede el proveedor identificar la versión actual de la aplicación, la del navegador y la fecha de publicación?
• □ ¿Se etiquetan por separado las funciones beta, de vista previa, experimentales y con disponibilidad general?
• □ ¿Coinciden la documentación y la prueba real respecto a límites y comportamiento?
• □ ¿Las afirmaciones sobre seguridad, disponibilidad, cifrado y rendimiento se limitan a componentes y pruebas concretos?
• □ ¿Se publican las limitaciones conocidas, los flujos no compatibles y las reglas de fin del soporte?
• □ ¿Evita el proveedor las garantías de invisibilidad, supervivencia de cuentas o acceso a servicios de terceros?

Captura el instalador, la pantalla de versión, las notas de la versión y la documentación pertinente en la fecha de evaluación. Una respuesta comercial sin una referencia estable sigue siendo una afirmación publicada, no un comportamiento verificado.

2. Aislamiento e integridad de perfiles

Primero define qué denomina perfil el producto. Puede referirse a un directorio persistente de datos del navegador, un contexto temporal, un archivo sincronizado, una sesión remota o un conjunto de ajustes. No son equivalentes.

Chromium documenta el directorio de datos de usuario como ubicación de esos datos y explica cómo elegir uno personalizado. También señala casos en los que dos instancias en ejecución no pueden compartir un directorio. Utiliza la documentación upstream sobre el directorio de datos como punto de partida y exige después pruebas específicas del producto.

• □ ¿Tiene cada perfil persistente un límite de almacenamiento y procesos claramente definido?
• □ ¿Impide el producto que dos escritores abran el mismo estado modificable del perfil?
• □ ¿Están aislados según se documenta las cookies, el almacenamiento, la caché, el historial, las extensiones, las descargas, los permisos y las preferencias?
• □ ¿Se etiquetan de forma diferente las sesiones temporales y los perfiles persistentes?
• □ ¿Utiliza un inicio limpio únicamente los datos del perfil previsto?
• □ ¿Conserva un reinicio exactamente el estado que el producto promete conservar?
• □ ¿Se controlan los permisos y los orígenes de instalación de las extensiones?
• □ ¿Se tratan las importaciones de perfiles como entradas no fiables y se validan antes de usarlas?
• □ ¿Puede ponerse en cuarentena un perfil dañado o incompatible sin sobrescribir una copia correcta conocida?

Las pruebas deben incluir comprobaciones entre perfiles. Establece un marcador inofensivo en el perfil A, confirma que no aparece en B, reinicia ambos y repite después de actualizar la aplicación. Utiliza cuentas desechables y datos sintéticos.

3. Vigencia del navegador, sandbox y actualizaciones

Un navegador es una dependencia de seguridad que exige mantenimiento continuo. La documentación actual de canales de Chromium indica que Stable recibe versiones menores semanales y principales cada cuatro semanas. Esa cadencia de versiones no dicta el nivel de servicio de un proveedor, pero muestra por qué «basado en Chromium» está incompleto sin pruebas de versión y actualizaciones.

• □ ¿Puedes relacionar la compilación del navegador con una versión upstream exacta?
• □ ¿Existe un objetivo o historial publicado de adopción de actualizaciones de seguridad upstream?
• □ ¿Quién supervisa las versiones y correcciones urgentes upstream?
• □ ¿Las actualizaciones de la aplicación y del navegador están firmadas y autenticadas con independencia de la conexión de descarga?
• □ ¿Puedes verificar resúmenes de artefactos, procedencia de versiones o una cadena de custodia equivalente?
• □ ¿Los despliegues se realizan por etapas, se supervisan y pueden detenerse?
• □ ¿La reversión evita recuperar una versión insegura según la política actual?
• □ ¿Se prueban las migraciones del esquema de perfiles en las vías compatibles de actualización y reversión?
• □ ¿Mantiene el producto activado el sandbox del navegador durante el funcionamiento normal?
• □ ¿Puede el proveedor explicar los procesos sin sandbox o con privilegios y por qué son necesarios?

Chromium describe su sandbox como un límite que restringe el código no fiable y aplica privilegios mínimos tanto al código aislado como a su controlador. Revisa el diseño del sandbox de Chromium y pide después al proveedor que muestre su configuración real de producción. Afirmar que un producto «utiliza Chromium» no demuestra que todas las mitigaciones upstream sigan activadas.

Para la integridad de las actualizaciones, The Update Framework es una referencia útil porque aborda expresamente la vulneración de repositorios y claves de firma. La procedencia SLSA define información verificable sobre dónde, cuándo y cómo se produjo un artefacto. Un proveedor no tiene que usar esos proyectos exactos, pero debe explicar cómo aborda la identidad de los artefactos, las claves vulneradas, la reversión, la congelación y la procedencia de la compilación.

4. Identidad, dispositivos y privilegios mínimos

NIST SP 800-53 Rev. 5 organiza controles de acceso, auditoría, autenticación, planificación de contingencias, respuesta ante incidentes y riesgo de la cadena de suministro. Utiliza esas familias como preguntas, no como prueba de implementación por el mero hecho de que el producto declare ajustarse al marco.

• □ ¿Recibe cada persona una identidad individual en lugar de un inicio compartido del equipo?
• □ ¿Está disponible y puede imponerse la autenticación multifactor para administradores y otros roles sensibles?
• □ ¿Se admiten opciones de autenticación más fuertes y resistentes al phishing cuando el riesgo lo exige?
• □ ¿Puede federarse la identidad con tu proveedor cuando sea necesario, sin eludir la autorización del producto?
• □ ¿Los roles son lo bastante granulares para separar consulta, inicio, edición, uso compartido, exportación, eliminación, facturación y administración?
• □ ¿Puede limitarse el acceso a una organización, un espacio, una carpeta o un conjunto explícito de perfiles?
• □ ¿Puede revocarse rápidamente un dispositivo, una sesión, un usuario, una credencial de servicio o una invitación?
• □ ¿Las cuentas de servicio tienen su propia identidad, caducidad, alcances y límites de tasa?
• □ ¿Los cambios de permisos y los intentos fallidos de autorización aparecen en el registro de auditoría?
• □ ¿La baja elimina el acceso sin obligar a cambiar una contraseña compartida?

Para consultar terminología actual y garantías de autenticación, utiliza NIST SP 800-63B-4, finalizado el 31 de julio de 2025. Confirma qué partes del producto cubren las afirmaciones de autenticación del proveedor: el inicio de sesión del sitio, el desbloqueo de escritorio, las API local y en la nube, la recuperación y el acceso de asistencia pueden utilizar mecanismos distintos.

5. Datos sensibles y límites de confianza

Dibuja el producto como flujo de datos. Marca el gestor de escritorio, los procesos del navegador, el servicio local, el plano de control en la nube, el almacenamiento de sincronización, el actualizador, el informador de fallos, las herramientas de asistencia y las integraciones de terceros. Pregunta en cada límite qué lo cruza y por qué.

• □ ¿Qué contenido de los perfiles permanece en local de forma predeterminada?
• □ ¿Qué metadatos y contenido sensible se suben al activar la sincronización?
• □ ¿Dónde se cifra y qué partes pueden obtener las claves de descifrado?
• □ ¿Cómo se protegen, copian, rotan y recuperan las claves locales?
• □ ¿Qué pueden leer los administradores de la organización, la asistencia del proveedor, los operadores de infraestructura y los clientes de automatización?
• □ ¿Se excluyen cookies, contraseñas, credenciales de proxy, secretos de doble factor y claves de cifrado de la interfaz, los registros, la telemetría, las API y las salidas de agentes normales?
• □ ¿Pueden previsualizarse los informes de fallos y diagnósticos, se ocultan los datos, respetan el consentimiento y tienen conservación limitada?
• □ ¿Puede la asistencia trabajar sin solicitar archivos sin procesar de perfiles ni credenciales?
• □ ¿Se tratan las extensiones importadas, los archivos, las descargas del navegador y los metadatos de actualizaciones como entradas no fiables?
• □ ¿Se define la eliminación en copias locales, objetos en la nube, copias de seguridad, registros y artefactos de asistencia?

No aceptes «cifrado» como respuesta completa. Registra la categoría de datos, la ubicación, el límite de cifrado, quién posee la clave, la vía de recuperación y los casos en los que existe texto sin cifrar.

6. Colaboración y auditabilidad

• □ ¿La propiedad del perfil permanece clara durante una asignación y un traspaso?
• □ ¿Puede el producto impedir o resolver visiblemente las ediciones simultáneas?
• □ ¿Se registran las invitaciones, los cambios de roles, los inicios, las detenciones, el uso compartido, las exportaciones, las eliminaciones, las llamadas de automatización y las recuperaciones?
• □ ¿Identifica cada evento al actor humano, la carga delegada, el recurso, la hora, la decisión y el resultado?
• □ ¿Se registran los valores anteriores y posteriores de los cambios importantes de configuración, con los secretos ocultos?
• □ ¿Son inequívocos los relojes, las zonas horarias, el orden de sucesos y los identificadores de solicitudes?
• □ ¿Están documentados el acceso a auditorías, el formato de exportación, la conservación y los controles de eliminación?
• □ ¿Puede un administrador cambiar o borrar los mismos registros utilizados para revisar su actividad?
• □ ¿Puede el equipo exportar los registros a su sistema de supervisión o investigación?
• □ ¿El registro continúa, utiliza un búfer seguro o cierra el acceso cuando el destino de auditoría no está disponible?

Las indicaciones de OWASP sobre registros recomiendan registrar fallos de autorización y acciones de mayor riesgo y capturar cuándo, dónde, quién y qué, a la vez que se controla el acceso y se evitan secretos técnicos. Aplica esa prueba a los eventos que exporta realmente el producto, no solo a capturas de una página de seguridad.

7. Recuperación, interrupción y salida

Una afirmación sobre copias de seguridad está incompleta hasta que se prueba una restauración. El NIST Cybersecurity Framework 2.0 incluye resultados para crear, proteger, mantener y probar copias, además de verificar los activos y sistemas restaurados.

• □ ¿Puedes crear una copia coherente respetando los bloqueos de perfiles?
• □ ¿Las versiones locales y sincronizadas pueden identificarse y ordenarse?
• □ ¿Puede un operador restaurar una versión elegida sin destruir la copia actual?
• □ ¿Se verifican los datos restaurados y la compatibilidad del navegador antes de reanudar el uso normal?
• □ ¿Qué ocurre después de terminar a la fuerza un proceso, perder la red, llenar el disco, interrumpir una subida o sufrir un fallo de la aplicación?
• □ ¿Se protege una última versión correcta conocida frente a una reparación fallida?
• □ ¿Puede eliminarse un dispositivo revocado o perdido sin perder la única vía de recuperación?
• □ ¿Las claves o códigos de recuperación se protegen tanto frente a pérdidas casuales como al acceso sin restricciones de administradores?
• □ ¿Puede el equipo exportar sus datos en un formato documentado y verificar la exportación antes de cancelar el servicio?
• □ ¿Existe un proceso compatible para eliminar y cerrar la cuenta con una declaración clara de conservación residual?

Ejecuta pruebas de recuperación solo con datos desechables, salvo que el proveedor y tu proceso de cambios admitan expresamente ejercicios en producción. Registra el tiempo de recuperación, el estado perdido, los pasos manuales, las advertencias y la versión del producto. Una demostración correcta con un perfil pequeño no establece rendimiento ni integridad a la escala de producción.

8. Automatización y controles para desarrolladores

• □ ¿Expone el producto operaciones versionadas de dominio en vez de acceso sin restricciones al sistema de archivos o los procesos?
• □ ¿Se documentan por separado las capacidades de API, CLI, SDK, Playwright, CDP, WebDriver, webhooks y agentes?
• □ ¿Existe una matriz exacta de compatibilidad entre navegador y cliente?
• □ ¿Pueden limitarse las credenciales por tenant, perfil, operación, destinatario, caducidad, tasa y coste?
• □ ¿Las acciones destructivas, masivas, visibles desde el exterior, portadoras de secretos o que generen gastos exigen una política o aprobación más fuerte?
• □ ¿Las vistas previas se vinculan a la solicitud exacta que se ejecutará?
• □ ¿Los comandos que modifican datos son idempotentes o explican los resultados desconocidos?
• □ ¿Pueden cancelarse y reanudarse con seguridad las operaciones largas?
• □ ¿Entra en vigor la revocación durante un trabajo activo?
• □ ¿Las decisiones de automatización se atribuyen en el mismo registro que las acciones humanas?
• □ ¿Puede una salida normal de automatización seguir siendo útil sin devolver estado de sesión sin procesar?
• □ ¿Los mensajes de error son lo bastante específicos para recuperarse sin filtrar secretos?

Prueba las vías de denegación. Un token de solo lectura debe fallar al iniciar un perfil. Uno limitado a un perfil debe fallar con otra carpeta. Una credencial caducada no debe renovarse de forma silenciosa con un acceso más amplio. Un agente no debe convertir una llamada rechazada en una aprobación de administrador reformulando la solicitud.

9. Experiencia y accesibilidad de los operadores

• □ ¿Pueden quienes usan el teclado alcanzar, operar y abandonar todos los controles, diálogos, tablas, menús y acciones de perfiles?
• □ ¿El foco es visible y sigue un orden lógico después de navegar, recibir errores y cambiar un modal?
• □ ¿Funcionan con lectores de pantalla las etiquetas, los errores, los cambios de estado y las confirmaciones destructivas?
• □ ¿La interfaz sigue siendo utilizable con zoom y texto ampliado?
• □ ¿El color, el movimiento y los límites de tiempo pueden ajustarse o no son esenciales?
• □ ¿Pueden distinguirse la organización, el perfil, el proxy, el entorno y el estado de riesgo seleccionados sin depender solo del color?
• □ ¿Pueden revisarse las acciones masivas sin obligar a utilizar tablas densas e inaccesibles?
• □ ¿Funcionan de forma coherente el comportamiento nativo de la plataforma, las notificaciones, los selectores de archivos, los avisos de credenciales y los diálogos de actualización?

WCAG 2.2 ofrece criterios comprobables para contenido web, incluidos el uso del teclado, el orden y la visibilidad del foco, el tamaño de objetivos, la identificación de errores y la autenticación accesible. Un producto de escritorio puede incluir interfaces nativas y web, por lo que deben combinarse las comprobaciones de estándares pertinentes con pruebas de tecnologías de asistencia en cada sistema operativo compatible.

10. Adecuación comercial y operativa

• □ ¿Se presentan y valoran por separado los puestos, perfiles guardados y sincronizados, almacenamiento, tráfico, sesiones simultáneas, tasa de API, trabajadores de automatización y niveles de asistencia?
• □ ¿Qué límites son topes estrictos, excesos facturados o condiciones de uso razonable?
• □ ¿Pueden cambiar la facturación o la capacidad sin aprobación de un administrador?
• □ ¿Están documentados los protocolos de proxy, métodos de autenticación, extensiones y entornos de red compatibles?
• □ ¿Cubre la política de asistencia los incidentes de actualización, los daños de perfiles, las restauraciones fallidas, los informes de seguridad y la recuperación de cuentas?
• □ ¿El estado del servicio, la comunicación de incidentes y las vías de escalado son reales y están supervisados?
• □ ¿Define el contrato la devolución y eliminación de datos, los cambios de precio, la suspensión y la terminación?
• □ ¿Puedes abandonar el servicio sin perder las pruebas necesarias para demostrar una migración segura?

Calcula el coste con la concurrencia máxima de trabajo, el estado sincronizado esperado, el volumen de automatización y los requisitos de asistencia. Registra impuestos, compromisos anuales, excesos y trabajo de migración. Evita comparar solo el mayor número de perfiles de cada página de precios.

Un plan de prueba controlada

Utiliza cuentas de prueba, credenciales sintéticas y perfiles creados para la evaluación. No importes cookies de producción solo para que la prueba parezca realista.

1. Registra el entorno. Anota las versiones de la aplicación y el navegador, el sistema operativo, el hardware, la red, el tipo de proxy, el conjunto de extensiones, el plan de la cuenta y la fecha de la prueba.
2. Crea dos roles y varios perfiles. Incluye un administrador, un operador limitado, carpetas separadas y al menos un perfil al que el operador no deba acceder.
3. Ejecuta el flujo normal. Inicia, utiliza, detén, traspasa y vuelve a iniciar perfiles. Registra el estado esperado y el real.
4. Ejercita la denegación. Intenta acceder a un perfil fuera del alcance, exportar, cambiar un rol y ejecutar un comando de automatización con la identidad limitada.
5. Ejercita una interrupción. Con datos desechables, interrumpe una detención del navegador o un paso de sincronización mediante un método compatible del proveedor o que sea seguro. Verifica la vía de recuperación.
6. Restaura y compara. Restaura una instantánea conocida en una copia nueva, verifica su integridad y conserva la copia actual hasta aceptar el resultado.
7. Revoca el acceso. Elimina un usuario, dispositivo, sesión y credencial de servicio; confirma la denegación en la interfaz y la API e inspecciona los eventos de auditoría.
8. Comprueba la portabilidad. Exporta los datos permitidos, inspecciona el formato documentado, vuelve a importarlos en un destino desechable si se admite e identifica lo que se omite.
9. Revisa la accesibilidad. Completa las tareas principales con teclado y la tecnología de asistencia pertinente en cada plataforma necesaria.
10. Concilia costes y afirmaciones. Compara el uso de recursos y las respuestas de asistencia observados con la propuesta y el contrato.

Plantilla de registro de decisión

Requisito	Prioridad	Resultado	Prueba y fecha	Limitación o riesgo	Responsable y siguiente acción
Ejemplo: el operador no puede exportar el estado de sesión	Requisito	Superado	Prueba controlada, versión X, AAAA-MM-DD	Solo superficie de API; CLI sin probar	El responsable de seguridad debe probar la CLI

Cierra la evaluación con cuatro listas explícitas:

• requisitos superados con pruebas suficientes;
• preocupaciones aceptadas por un responsable nominal y con fecha de revisión;
• elementos que siguen sin verificar;
• condiciones que provocarían otra evaluación, como un motor, proveedor de identidad, actualizador, modelo de precios o formato de perfil nuevo.

Señales de alarma habituales

Pausa la decisión cuando:

• no pueda identificarse la versión del navegador;
• deba desactivarse el sandbox para el uso normal;
• los administradores y la automatización compartan una credencial permanente;
• el producto dependa de compartir cookies o contraseñas sin procesar para los traspasos del equipo;
• una API pueda exportar secretos que la interfaz afirma proteger;
• los eventos de auditoría omitan al actor o no puedan exportarse;
• «copia de seguridad» solo signifique que existe una copia en la nube, sin una restauración demostrada;
• el proveedor no pueda explicar las escrituras interrumpidas ni el acceso simultáneo a perfiles;
• un flujo esencial inaccesible carezca de alternativa;
• un informe de seguridad exija enviar secretos mediante correo corriente; o
• las afirmaciones del producto prometan indetectabilidad, acceso garantizado a cuentas o elusión de controles de la plataforma.

Un resultado «no verificado» no es una acusación. Es una afirmación precisa sobre la ausencia de pruebas. Mantenlo visible hasta que el proveedor aporte pruebas, tu equipo compruebe el comportamiento o quien decide acepte el riesgo.