Pregunta y alcance
Eres responsable de un panel de control que embebe meet.example para llamadas, video.example para reproducción y varios marcos de anuncios. El marco de la reunión necesita microphone y camera; el marco de video necesita fullscreen; los anuncios no necesitan ninguna de estas funcionalidades. La página utiliza HTTPS, los orígenes de los marcos son conocidos y el navegador aún debe solicitar al usuario el consentimiento de medios cuando la política lo permita.
El alcance comprende la composición y el diagnóstico de políticas del lado del navegador. La autenticación, CSP y la autorización en el servidor siguen siendo controles independientes. Asume que el encabezado de respuesta es configurado por el servidor del panel y que cada marco de origen cruzado tiene un atributo allow explícito.
Qué está evaluando el entrevistador
El entrevistador quiere ver si separas tres compuertas: la política de respuesta, la delegación del marco y el permiso en tiempo de ejecución del usuario. Una lista de permitidos en el encabezado por sí sola no otorga acceso a un marco de origen cruzado, y un atributo allow no puede ampliar un encabezado que deniega la funcionalidad.
También evalúan si evitas la conveniencia de usar comodines. Una respuesta sólida comienza desde () para funcionalidades sensibles, nombra orígenes exactos, maneja la navegación anidada y describe qué hace la interfaz de usuario cuando una API no está disponible. Una respuesta débil escribe *, espera a que aparezca un mensaje de permiso y califica la funcionalidad como segura.
Preguntas para aclarar antes de responder
- ¿A qué orígenes exactos pueden navegar los marcos de reunión y de video? Una navegación a un origen diferente puede requerir ese destino en la política del marco, o la funcionalidad debe denegarse tras la navegación.
- ¿El marco de la reunión abre marcos anidados? De ser así, define si la delegación puede continuar y prueba el origen anidado en lugar de asumir que la concesión del primer marco se hereda para siempre.
- ¿Qué navegadores y webviews embebidos son compatibles? La sintaxis de una política puede ser correcta mientras que un entorno de ejecución más antiguo expone una superficie de fallas diferente.
- ¿Es obligatoria una llamada con cámara o micrófono? Si es opcional, la interfaz de usuario puede ofrecer una alternativa de solo texto cuando se deniegue la política o el permiso del usuario.
Un marco de respuesta de 30 segundos
“Pondría por defecto la cámara y el micrófono en () y los otorgaría solo al origen de la reunión en la política de respuesta. Otorgaría pantalla completa solo al origen del video. Cada iframe de origen cruzado repetiría la funcionalidad prevista en su atributo allow, ya que tanto el encabezado como la política del marco son obligatorios. El marco detectaría la denegación por política por separado de la denegación por parte del usuario, renderizaría una alternativa y nunca trataría un aviso de permiso como autorización. Probaría casos de mismo origen, de origen cruzado, de navegación, de marcos anidados, de encabezados faltantes y de respaldo del navegador antes del despliegue.”
Respuesta profunda paso a paso
Paso 1: Comenzar con un inventario que deniegue por defecto
Enumera cada funcionalidad controlada por política utilizada por la página y su origen propietario. No infieras permisos a partir del nombre del producto “reunión”. Cámara y micrófono son dos funcionalidades independientes. Pantalla completa es otra. Los anuncios son una clase explícita de acceso cero.
Utiliza un encabezado explícito como:
Permissions-Policy: camera=(self "https://meet.example"), microphone=(self "https://meet.example"), fullscreen=(self "https://video.example")La lista de orígenes exactos evita que un marco no relacionado reciba una concesión. Si el propio panel de control no debe acceder a una funcionalidad, elimina self y otorga acceso solo al origen del marco requerido, luego verifica que la política padre aún permita la delegación.
Paso 2: Delegar en cada límite de iframe
El marco de la reunión recibe solo sus dos funcionalidades y el marco de video recibe solo pantalla completa:
<iframe src="https://meet.example/room" allow="camera; microphone"></iframe>
<iframe src="https://video.example/player" allow="fullscreen"></iframe>
<iframe src="https://ad.example/slot" allow=""></iframe>Para un marco de origen cruzado, omitir allow bloquea la funcionalidad incluso cuando el encabezado de respuesta lista el origen. Por el contrario, agregar allow="camera" a un anuncio no anula camera=() ni a un origen no presente en el encabezado.
Paso 3: Tratar la política y el consentimiento del usuario como estados diferentes
Permissions-Policy decide si el documento puede usar una funcionalidad. La Permissions API y la solicitud de medios representan el permiso otorgado por el usuario. Una funcionalidad bloqueada puede fallar antes de que aparezca una solicitud. El marco debe asignar “política denegada”, “usuario denegó”, “no soportado” y “dispositivo ocupado” a diferentes telemetrías y textos de recuperación.
No hagas que la verificación del lado del cliente sea el límite de seguridad. La página que embebe controla la delegación, mientras que la aplicación aún autentica la llamada y autoriza la membresía en la sala desde el servidor.
Paso 4: Manejar la navegación y los marcos anidados explícitamente
Si el marco de la reunión puede navegar a un origen de soporte, incluye ese destino en la política de allow solo si es de confianza y necesita la misma funcionalidad. El origen inicial de src de un marco y un origen de navegación posterior no son intercambiables. Para marcos anidados, verifica la política efectiva en cada límite y deniega por defecto cuando la propiedad no esté clara.
Paso 5: Desplegar con pruebas observables
Envía el encabezado en modo de diagnóstico solo de reporte (report-only) o a una pequeña cohorte de rutas cuando la plataforma lo permita; luego compara las violaciones de política, los resultados de los avisos, la finalización de llamadas y el uso de alternativas. Prueba un marco del mismo origen, un marco de origen cruzado permitido, un marco de origen cruzado no listado, un atributo allow faltante, un subdominio modificado y una navegación de marco. Comprueba que los anuncios nunca lleguen a mostrar un aviso y que un marco de reunión denegado ofrezca chat de texto.
Ejemplo de respuesta de alta calidad
“Escribiría la política a partir del modelo de amenazas. La cámara y el micrófono comienzan como permisos vacíos, luego el encabezado lista únicamente a meet.example; la pantalla completa lista únicamente a video.example. Los dos marcos de origen cruzado llevan atributos allow coincidentes, mientras que el marco de anuncios no lleva ninguno. El navegador sigue controlando el consentimiento del usuario, por lo que el código de la reunión distingue un bloqueo por política de una denegación del usuario y ofrece una alternativa de solo texto. No pondría la autorización en este encabezado: el servidor sigue verificando la sala y al usuario.
Antes de habilitarlo globalmente, ejecutaría la matriz: orígenes permitidos y no listados, subdominios del mismo sitio pero de origen cruzado, allow omitido, navegación de marcos, marcos anidados, navegadores no soportados y encabezado faltante. La telemetría registra la funcionalidad, el origen del marco, el resultado de la política, el resultado del usuario y la alternativa sin grabar medios. Cualquier aviso inesperado proveniente de un anuncio o cualquier acceso exitoso tras la navegación a un origen no confiable detiene el despliegue.”
Errores comunes
- Usar
*para la cámara y el micrófono → cualquier marco elegible puede solicitar una funcionalidad potente → comienza con()y agrega los orígenes exactos. - Agregar solo el encabezado HTTP → un iframe de origen cruzado aún necesita la delegación del contenedor → establece un atributo
allowcoincidente. - Agregar solo
allow→ el marco no puede ampliar la política padre → verifica tanto la respuesta como cada límite de marco. - Tratar la falta de un aviso como un error del navegador → la denegación por política puede ocurrir antes del consentimiento del usuario → reporta los estados de política, consentimiento, soporte y dispositivo por separado.
- Asumir que los subdominios son del mismo origen → mismo sitio (same-site) no significa mismo origen (same-origin) → enumera cada origen y prueba la navegación.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué la funcionalidad está bloqueada si el encabezado incluye el origen de la reunión?
Verifica el atributo allow del iframe, el esquema y puerto exactos, y si el marco navegó. Para un marco de origen cruzado, la lista de permitidos del encabezado y la política del contenedor se intersectan; una sola concesión faltante bloquea la funcionalidad.
Pregunta de seguimiento 2: ¿Se debería omitir el encabezado y depender solo de allow?
No. Una política de respuesta explícita le da al propietario de la página un límite de nivel superior y previene concesiones accidentales cuando se añade un nuevo marco. Omitirla puede dejar un comportamiento por defecto permisivo para algunas funcionalidades, lo que convierte una posterior inserción de terceros en una regresión de políticas.
Pregunta de seguimiento 3: El marco de la reunión navega a un dominio de soporte. ¿Qué cambia?
Reevalúa el destino como un nuevo origen. Otorga cámara o micrófono allí únicamente después de que la confianza, la autenticación y el manejo de datos hayan sido revisados; de lo contrario, la navegación debe perder esas capacidades y la interfaz debe explicar la alternativa.
Pregunta de seguimiento 4: ¿Puede la Permissions Policy reemplazar la autorización del lado del servidor?
No. Controla la disponibilidad de funcionalidades del navegador en un documento. No comprueba la identidad del usuario, la membresía en la sala ni si una solicitud puede unirse a una llamada. Mantén esas verificaciones en el servidor y trata a la política como un límite de mínimo privilegio en el navegador.