The core issue: Stripe's Payment Intent pattern (server gets token → passes to client → client opens iframe) is safe because the blast radius is bounded; worst case, someone pays your invoice. But the same pattern applied to admin embeds (payroll, HR, financial controls) means a single XSS or compromised npm dependency can exfiltrate full admin access.
The fix I'm proposing (RequestRequest) routes every iframe API call through the host page for server-side JWT signing. The iframe never holds a persistent credential. There are three interactive demos in the post, including a real race condition demo against a Durable Object.
I disclosed this to two vendors in Jan 2024. Both classified it as informational. Neither has changed their architecture.
1 comment
[ 2.7 ms ] story [ 15.2 ms ] threadThe core issue: Stripe's Payment Intent pattern (server gets token → passes to client → client opens iframe) is safe because the blast radius is bounded; worst case, someone pays your invoice. But the same pattern applied to admin embeds (payroll, HR, financial controls) means a single XSS or compromised npm dependency can exfiltrate full admin access.
The fix I'm proposing (RequestRequest) routes every iframe API call through the host page for server-side JWT signing. The iframe never holds a persistent credential. There are three interactive demos in the post, including a real race condition demo against a Durable Object.
I disclosed this to two vendors in Jan 2024. Both classified it as informational. Neither has changed their architecture.