Entrevista frontend: ¿Cómo diseñarías permisos de extensión de navegador con el principio de menor privilegio?

Enunciado y contexto adecuado

La extensión procesa la página actual solo después de un clic explícito en la barra de herramientas y luego envía los campos filtrados a un backend controlado. No necesita escanear en segundo plano cada pestaña ni acceder a las cookies de sitios arbitrarios. Propón la división de permisos en Manifest V3, el flujo en tiempo de ejecución, la degradación elegante y el plan de verificación de lanzamientos.

Esta pregunta evalúa los límites de permisos de extensiones de navegador y la seguridad del producto. El backend sigue siendo responsable de la autenticación, la minimización de datos y los controles de auditoría; los permisos de la extensión no los reemplazan.

Qué evalúa el entrevistador

El entrevistador quiere ver que la capacidad de las API, los hosts alcanzables y el consentimiento del usuario se traten como decisiones separadas. Chrome documenta los permisos de API, los permisos de host, los permisos opcionales y activeTab por separado; estos afectan las API disponibles, el acceso a URL, las advertencias de instalación y el comportamiento en las actualizaciones.

Una respuesta sólida comienza con la menor capacidad posible, explica por qué una acción puntual sobre la página actual no debería solicitar <all_urls>, y cubre la denegación, la revocación, las actualizaciones y la telemetría. Limitarse a decir "agregar permisos" no demuestra un ciclo de vida seguro.

Aclaraciones para hacer primero

• ¿La "página actual" incluye páginas especiales, marcos de origen cruzado, URLs de tipo file o ventanas de incógnito?
• ¿La API necesita el documento completo o solo los campos seleccionados por el usuario?
• ¿La extensión debe observar los cambios de la página cuando el usuario no ha hecho clic en ella?
• ¿Qué implementaciones de WebExtensions deben ser compatibles?
• ¿Las políticas empresariales pueden preconfigurar los permisos y durante cuánto tiempo se pueden conservar los campos de auditoría?

Estructura de respuesta en 30 segundos

"Dividiría la capacidad en lectura de la página actual, comunicación con el backend y almacenamiento. Para una acción puntual utilizaría activeTab en lugar de un acceso amplio a hosts. Solo una función genuina en segundo plano entre varias páginas justificaría optional_host_permissions precisos, solicitados cuando el usuario active dicha función. Declararía únicamente los permisos de API requeridos, me detendría ante una denegación o revocación y proporcionaría una alternativa de copia manual. Antes de las actualizaciones, compararía las diferencias de permisos y supervisaría los nuevos accesos y flujos de datos; una reversión eliminaría la nueva capacidad".

Respuesta detallada paso a paso

Paso 1: Mapear el comportamiento con los permisos

Los permisos de API como storage y scripting otorgan capacidades de API de extensión; los permisos de host definen el rango de URLs con el que se puede interactuar. El manifiesto debe derivarse de cada flujo de datos, no de características que podrían necesitarse más adelante.

Un punto de partida para procesar únicamente la pestaña donde el usuario hizo clic es:

{
  "manifest_version": 3,
  "permissions": ["activeTab", "scripting", "storage"],
  "optional_host_permissions": ["https://app.example.com/*"]
}

Cuando un script se inyecta solo en la página actual, activeTab otorga acceso temporal tras una acción del usuario; cerrar o navegar fuera de la pestaña lo finaliza. Si el producto realmente necesita procesamiento en segundo plano para app.example.com, evalúa un permiso de host opcional y preciso en lugar de recurrir por defecto a *://*/*.

Paso 2: Diseñar el consentimiento progresivo

Solicita solo las capacidades esenciales y de menor riesgo durante la instalación. Cuando el usuario haga clic en "Analizar esta página", verifica la URL contra el conjunto permitido. Si se necesita un host adicional, llama a chrome.permissions.request() y explica el propósito, el alcance y cómo salir de la función.

const granted = await chrome.permissions.request({
  origins: ["https://app.example.com/*"]
});
if (!granted) {
  showManualCopyFallback();
  return;
}

El éxito significa que la capacidad del navegador está disponible; no elude la autenticación del backend. Si la solicitud falla, el usuario la revoca posteriormente o la política la deshabilita, regresa al estado sin permisos sin mostrar avisos repetitivos.

Paso 3: Distinguir entre estado activo, otorgado y revocable

Chromium distingue los permisos actualmente activos de los permisos otorgados históricamente. chrome.permissions.remove() reduce la capacidad actual, mientras que el conjunto de permisos otorgados históricamente aún puede registrar el permiso; una solicitud posterior podría no volver a mostrar el mismo aviso. Las decisiones en tiempo de ejecución deben basarse en lo que está disponible actualmente, y la configuración debe exponer una acción de revocación clara.

Antes de cada tarea, llama a chrome.permissions.contains() para verificar el permiso real. Durante la tarea, escucha permissions.onRemoved; detén la lectura y la carga, limpia la cola de salida y registra un evento auditable de cambio de permisos.

Paso 4: Manejar la denegación, las actualizaciones y la reversión

Ante una denegación, presenta un paso siguiente no técnico como la selección manual, copiar y pegar, o salir. No clasifiques la denegación como un error de red ni reintentes solicitudes de permisos en segundo plano.

Antes de un lanzamiento, genera un diff de permisos que cubra nuevas API, patrones de host, coincidencias de content-scripts y campos de datos. Chrome puede deshabilitar una extensión cuando una actualización incrementa los privilegios y esperar a un consentimiento renovado. Además, eliminar un permiso no necesariamente borra las concesiones históricas, por lo que las pruebas de reversión deben cubrir tanto a los usuarios que lo otorgaron previamente como a los que nunca lo hicieron.

Paso 5: Convertir los permisos en un límite de seguridad comprobable

Los scripts de contenido procesan entradas controladas por la página, por lo que los manejadores de mensajes deben validar el remitente, el tipo de mensaje y el tamaño. El backend debe reautorizar la identidad de la extensión, la identidad del usuario, el recurso de destino y la lista de campos permitidos. Los permisos de host limitan la capacidad del navegador; no hacen que una página sea confiable ni impiden que una extensión envíe datos leídos al backend equivocado.

Antes del lanzamiento, construye una matriz para instalación, permitir, denegar, revocar, expiración de activeTab tras la navegación, solicitud de host opcional, actualización con incremento de permisos, reversión, deshabilitación por política empresarial, navegadores no compatibles y modo sin conexión. La telemetría debe registrar la clave de permiso, el patrón de host, el resultado y la versión, nunca el texto de la página.

Respuesta de ejemplo de alta calidad

"Comenzaría con el mapa de capacidades y flujos de datos. Dado que la acción de la barra de herramientas procesa únicamente la página actual, el diseño principal utiliza activeTab, scripting y el storage requerido, sin acceso a todos los sitios. Solo una función en segundo plano para app.example.com usaría un permiso de host opcional y preciso, solicitado cuando el usuario la active. Explicaría el propósito y el alcance antes de la solicitud, ofrecería selección manual tras una denegación y evitaría bucles de avisos.

Antes de cada tarea verificaría los permisos actuales y escucharía eventos de revocación. Si el acceso desaparece, detendría la lectura, limpiaría la cola de salida y haría que el backend reautorice la identidad y el recurso. Antes de una actualización, compararía los cambios de API, host y scripts de contenido, y luego probaría la inhabilitación, el consentimiento renovado y la reversión. Finalmente, usaría una matriz de permisos y telemetría anonimizada para verificar la ausencia de escaneos en segundo plano, inyecciones entre hosts, texto de página en registros y asegurar una degradación segura ante denegaciones y revocaciones".

Errores comunes

• Solicitar <all_urls> por defecto → amplía la exposición de lectura e inyección e incrementa las advertencias → comienza con activeTab, luego evalúa hosts precisos para funciones continuas.
• Tratar optional_host_permissions como consentimiento automático → la declaración no es la aprobación del usuario → solicítalo en el momento de la función y maneja la denegación.
• Verificar permisos solo en la instalación → los usuarios pueden revocarlos más tarde → verifica antes del trabajo y escucha eventos de eliminación.
• Revisar solo los cambios de código en las actualizaciones → los nuevos permisos pueden deshabilitar la extensión → compara conjuntos de permisos y prueba concesiones previas.
• Tratar el permiso del navegador como autorización del backend → los datos aún pueden llegar a la cuenta equivocada → reautoriza identidad, recursos y campos en el servidor.
• Llenar el texto de consentimiento con nombres de API → los usuarios no pueden formarse un modelo de riesgo útil → explica el propósito, el alcance y la salida.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué no solicitar <all_urls> directamente?

Una acción puntual en la página actual no necesita acceso en segundo plano a todos los sitios. activeTab otorga capacidad temporal tras una acción del usuario y reduce la exposición a largo plazo; solo un requisito continuo y claro entre varias páginas justifica un acceso preciso a hosts.

Pregunta de seguimiento 2: ¿Qué sucede con los datos ya subidos cuando el usuario revoca el acceso?

La revocación impide el acceso posterior del navegador, pero no puede recuperar los datos que ya salieron del dispositivo. Utiliza campos mínimos, retención corta y controles de eliminación en el backend; limpia la cola de salida local e informa al usuario sobre el procesamiento que ya se llevó a cabo.

Pregunta de seguimiento 3: ¿Por qué reautorizar en el backend después de que el permiso opcional es otorgado con éxito?

El permiso del navegador indica que la extensión puede leer una página, no que el usuario puede acceder a un recurso empresarial. El backend debe validar la sesión, la versión de la extensión, el recurso de destino y la lista de campos permitidos, y rechazar solicitudes obsoletas o anómalas.

Pregunta de seguimiento 4: ¿Se puede asumir que el comportamiento de permisos en Chrome y Firefox es idéntico?

No. Comparten conceptos de WebExtensions, pero los avisos, los patrones de coincidencia y los límites de tiempo de ejecución pueden diferir. Prueba la instalación, solicitud, revocación, navegación y actualización en cada navegador de destino y mantén las diferencias en una matriz de compatibilidad.