Pagos embebidos y aislamiento entre orígenes: por qué chocanEmbedded payments and cross-origin isolation: why they clash
Con COEP activo, el iframe de tu proveedor de pagos puede quedar bloqueado antes de mostrar un solo campo.
With COEP on, your payment provider’s iframe can be blocked before it shows a single field.
Algunas funciones del navegador, como ciertos usos de WebAssembly con memoria compartida, piden que el sitio esté aislado entre orígenes. Para eso se envían las cabeceras Cross-Origin-Embedder-Policy y Cross-Origin-Opener-Policy. El problema aparece cuando la misma página necesita un formulario de pago embebido.
Lo que medimos
Con COEP: credentialless, los subrecursos de terceros quedan exentos de CORP, pero un documento anidado (un iframe) sigue necesitando su propia cabecera COEP. Los iframes que inyecta la librería de pagos no la envían. El script carga, pero el iframe controlador queda bloqueado y el formulario nunca aparece.
Dos salidas que sí funcionan
- Una ruta propia para el pago, con la excepción de cabeceras solo ahí. Ojo: las reglas de cabeceras de la mayoría de los hosts casan rutas, no parámetros de consulta. Si tu pantalla de pago vive en
/?screen=pago, primero necesita una URL de verdad. - Pago por redirección de primer nivel, como un checkout alojado. Además saca el número de tarjeta de tu dominio y evita que
COOP: same-originrompa la autenticación 3D Secure, que depende dewindow.opener.
Antes de elegir cualquier SDK que meta iframes (pagos, video, mapas), revisa con curl -I qué cabeceras envían esos iframes. No lo supongas.
Some browser features, such as certain uses of WebAssembly with shared memory, require the site to be cross-origin isolated. That means sending Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy headers. The trouble starts when the same page needs an embedded payment form.
What we measured
With COEP: credentialless, third-party subresources are exempt from CORP, but a nested document (an iframe) still needs its own COEP header. The iframes injected by the payments library do not send it. The script loads, the controller iframe is blocked and the form never appears.
Two ways out that work
- A dedicated route for payment, with the header exception only there. Note: most hosts match header rules on paths, not query strings. If your payment screen lives at
/?screen=payment, it first needs a real URL. - A top-level redirect payment, such as a hosted checkout. It also takes the card number off your domain and keeps
COOP: same-originfrom breaking 3D Secure flows that depend onwindow.opener.
Before choosing any SDK that injects iframes (payments, video, maps), check what headers those iframes send with curl -I. Do not assume.