Contextos seguros: API del navegador y HTTPS
Una guía práctica sobre elegibilidad, permisos, políticas, iframes, pruebas deterministas y límites de BotBrowser para funciones web potentes.
BotBrowser Team
Quieres la documentación estructurada de Plataforma?
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.
Un contexto seguro es un entorno en el que el navegador puede confiar razonablemente en la integridad del origen y en que sus ancestros no rompen esa confianza. El estándar Secure Contexts usa esta clasificación para limitar capacidades que pueden exponer datos privados o controlar dispositivos. HTTPS suele ser necesario en producción, pero solo demuestra elegibilidad: no concede permisos, no anula una política de incrustación, no crea activación del usuario, no garantiza que exista una API ni asegura que una operación remota termine correctamente.
Qué significa contexto seguro
La especificación W3C Secure Contexts define una clasificación, no un icono de candado ni una garantía de que cada script sea confiable. Una página superior HTTPS con certificado válido es el caso habitual. Una página segura dentro de un ancestro no confiable puede perder la clasificación, porque el ancestro controla parte del entorno. window.isSecureContext informa del objeto global actual, pero no dice si la API está implementada, si la política la permite, si el usuario aceptó ni si la llamada tendrá éxito.
Los orígenes de desarrollo de bucle local, como http://localhost, suelen considerarse confiables aunque no tengan un certificado público. Esto facilita el desarrollo, pero no convierte un host remoto HTTP en seguro. Registra siempre URL y versión del navegador: las excepciones y los detalles del navegador pueden cambiar.
“Función potente” engloba cámara, micrófono, geolocalización, portapapeles, credenciales y otras capacidades sensibles. Cada API añade sus propias condiciones: activación transitoria, permiso explícito, documento visible, hardware, política concreta o respuesta válida del servidor. Consulta la operación exacta en su especificación.
Elegibilidad no es autorización
Analiza cinco puertas separadas: (1) el contexto puede exponer la API; (2) el navegador y la plataforma la implementan; (3) el árbol de incrustación y Permissions Policy la permiten; (4) usuario, navegador o dispositivo administrado conceden permiso; y (5) la llamada cumple sus reglas de activación y la aplicación valida el resultado. Mantén estados distintos: no elegible, no compatible, bloqueada por política, permiso denegado, cancelada, operación fallida y completada.
| Puerta | Comprobación | Resultado que se registra |
|---|---|---|
| Contexto | window.isSecureContext y origen final | Elegible o no elegible |
| Política | Cabecera de respuesta y allow del iframe | Permitida o bloqueada |
| Permiso | Decisión del usuario, navegador o dispositivo | Concedido, denegado o pendiente |
| Operación | Interfaz, gesto, hardware y resultado de la aplicación | Completada o fallida |
La Permissions Policy permite que la respuesta superior y el atributo allow del iframe delimiten qué orígenes pueden usar una capacidad. La cabecera es un límite superior y allow es delegación, no una concesión de permiso. Revisa cabecera, atributo, origen hijo y especificación juntos. Un cambio de esquema, host o puerto crea otro origen con almacenamiento, cookies, permisos y service workers separados. Los iframes con sandbox pueden tener un origen opaco.
La activación del usuario es independiente. Coloca la llamada detrás de un control visible y accesible por teclado, explica el motivo y evita solicitar permisos ocultos durante la carga. Conserva una ruta alternativa cuando la capacidad no sea posible.
HTTPS, localhost e incrustación
Compara la URL completa y la cadena de redirecciones. Comprueba el documento HTTPS final, su location.origin y isSecureContext; no uses el estado de la navegación HTTP inicial. También pueden cambiar entre local y producción los encabezados, el proxy, el historial de permisos, el navegador y la estructura de frames.
Un iframe HTTPS puede seguir sin delegación, y una página HTTPS puede cargar contenido activo HTTP que el navegador bloquee. No uses allow="*" como atajo: delega solo la función y el origen necesarios. Same-Origin Policy, aislamiento entre orígenes y Permissions Policy resuelven problemas diferentes; activar uno no satisface los otros.
Fixture determinista
Prueba clasificación sin pedir cámara, micrófono ni datos reales:
async function checkSecureContext(expected) {
const host = document.createElement('section');
const status = document.createElement('output');
status.setAttribute('aria-live', 'polite');
host.append(status);
document.body.append(host);
try {
const actual = window.isSecureContext;
const passed = actual === expected;
status.textContent = `${passed ? 'PASS' : 'FAIL'}: expected ${expected}; observed ${actual}`;
console.assert(passed, status.textContent);
return { passed, actual, visibleResult: status.textContent };
} finally {
host.remove();
}
}
await checkSecureContext(true);
El valor esperado viene de la configuración del caso, nunca del valor observado. Para un iframe ejecuta el fixture en el documento hijo y usa postMessage; valida event.origin antes de aceptar el mensaje. Prueba por separado HTTPS, HTTP remoto cuando sea posible, localhost y el origen hijo. Registra URL exacta, expectativa, navegador, cabeceras, relación de frames y resultado visible. Limpia nodos, datos temporales y contextos aislados en finally.
Una prueba de política debe usar una cabecera controlada y comprobar la delegación concreta. No uses un prompt sensible como única evidencia: puede fallar por política, configuración, decisión del usuario, hardware o implementación. Si haces un smoke test de API, solicita solo después de un gesto y clasifica denegación y cancelación por separado.
Desplegar, observar y revertir
Antes de publicar, verifica certificado, redirecciones, proxy, Content-Security-Policy, Permissions-Policy y allow del iframe en el host canónico. Ejecuta el fixture en staging después de fijar cabeceras y repítelo en el candidato de producción. El informe debe contener URL, versión del navegador, resultado, políticas y origen hijo, sin credenciales ni prompts crudos.
Incluye una vía alternativa: entrada manual para ubicación, descarga convencional para archivos o instrucciones para continuar sin hardware. Conserva datos introducidos y accesibilidad; no describas un error de transporte como rechazo del usuario. Revierte el componente que falló: hosting para certificado/redirección, configuración para cabecera, integración para delegación y aplicación para la vía alternativa. Mantén HTTPS y políticas restrictivas durante el rollback y repite el mismo fixture.
Qué puede validar BotBrowser
BotBrowser ofrece contextos controlados para páginas propias autorizadas. Puedes cargar el fixture en orígenes declarados, observar isSecureContext, comprobar fallbacks y comparar resultados entre versiones. La documentación de aislamiento multi-cuenta describe contextos separados para recorridos reproducibles.
BotBrowser no vuelve confiable un HTTP remoto, no concede permisos, no anula Permissions Policy, no aporta hardware ausente ni garantiza una API en cada plataforma. No sustituye los requisitos W3C, los certificados, las cabeceras, las afirmaciones de la aplicación ni la monitorización de producción. Un resultado positivo solo describe lo visible bajo las condiciones registradas; el propietario del sitio sigue controlando transporte, incrustación y ruta alternativa.
Para este tema, BotBrowser permite usar contextos aislados para cargar una fixture HTTPS propia y observar su resultado visible de contexto seguro, pero no puede volver confiable un origen inseguro ni conceder el permiso solicitado por una persona.
La configuración debe conservar el origen final.
El navegador probado debe quedar registrado.
La cabecera de política forma parte del caso.
El origen del iframe se valida de forma explícita.
La expectativa no se calcula desde el resultado.
La prueba no solicita datos sensibles.
El gesto del usuario se prueba por separado.
La denegación no se confunde con una excepción TLS.
Los recursos mixtos se corrigen en el servidor. La vía alternativa conserva los datos escritos.
La alternativa funciona con teclado.
El informe no guarda credenciales.
El rollback mantiene HTTPS activo.
La fixture se repite después de cambiar cabeceras.
Los contextos aislados se limpian siempre.
Para temas cercanos, consulta la guía de permisos y la guía de compatibilidad y ruta alternativa.
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.