Prompt and setting
An identity provider is embedded in an iframe on many customer sites. A signed-in user should see account information, but browsers may partition or block third-party cookies. Design a flow using the Storage Access API without turning every embed into a silent tracking channel.
Assume the iframe can navigate to its own first-party page, the top-level site controls the iframe permissions, and users may refuse prompts. The answer must cover consent, CSRF, fallback, and logout.
What the interviewer tests
- Whether you know that storage access is permission-gated and frame-scoped, not a universal cookie switch.
- Whether you require user activation and an explicit product reason before requesting access.
- Whether you separate partitioned bootstrap state from unpartitioned session state.
- Whether denial leaves a functional signed-out or redirect-based path.
Clarifying questions before answering
- Does the widget need cross-site session continuity, or can a redirect return an authorization code? A redirect may avoid requesting embedded cookie access.
- Has the user visited the identity provider as a first party and set its cookie? Some browsers require that relationship before granting access.
- What top-level origins may embed the frame? This determines the
Permissions-Policyallowlist. - What data is shown before consent? The pre-access view must not leak account identity.
30-second answer framework
“I treat the Storage Access API as a user-mediated capability, not as a fallback cookie toggle. The iframe starts with partitioned or opaque state, asks only after a click that clearly explains the benefit, and checks the returned promise. The top-level site sends a narrow Permissions-Policy allowlist. On denial, I use a first-party redirect or signed-out experience. Every state-changing request still has CSRF protection, and the widget can revoke its session and return to the same neutral state.”
Step-by-step deep dive
1. Separate the states and threat model
Before access, the iframe may have partitioned storage or no cookie. It must not infer a user identity from that state. After requestStorageAccess() succeeds, the embedded document may access its unpartitioned first-party cookies according to browser policy.
The capability is scoped to the document and embedding context. It is not proof that the top-level site is trusted, nor a replacement for origin checks, CSRF defenses, consent records, and logout semantics.
2. Gate the request behind user intent
Render a neutral signed-out widget. A button such as “Sign in to show account details” creates a user activation. In that handler, call the API and handle rejection as an expected branch. Do not request access on page load or use a hidden frame to manufacture activation.
The application should explain which data becomes available and remember the decision only as permitted by browser policy. A request can be denied because the browser blocks third-party cookies, the user has not interacted with the site as a first party, the frame lacks policy permission, or the context is not eligible.
3. Configure the embedding boundary
The top-level response owns the policy. Allow only the identity origin and only on routes that embed the widget:
Permissions-Policy: storage-access=(self "https://id.example")The iframe must be served with the expected origin and sandbox settings. A sandboxed frame needs the appropriate same-origin capability, and an origin mismatch must fail closed. Treat the policy as an allowlist, not as a way to grant every third party access.
4. Establish first-party and embedded flows
If the browser requires first-party interaction, the widget opens a first-party page on the identity origin. The user signs in there, the identity provider sets its first-party cookie, and a short-lived, origin-bound result returns to the embed. The result should not be a reusable bearer token in a URL.
Back in the iframe, request storage access after the user gesture, then read the session through the identity origin. The server still checks the top-level origin, session state, and CSRF token. A successful grant does not bypass account authorization.
5. Design denial, logout, and measurement
When access is denied, keep the widget useful: show a sign-in link, use a redirect-and-return flow, or offer a first-party account page. Do not loop prompts. Logout clears the identity session and resets the iframe to its neutral state; it should also invalidate any cached account view.
Measure grant success, denial reasons where available, redirect completion, and account-view errors by browser and embedding origin. Never log cookie values or account data. The product should be able to remove the API path later without losing the redirect flow.
High-quality sample answer
I would start with an anonymous iframe that only renders a sign-in affordance. After a user click, it requests storage access and handles rejection explicitly. The embedding page sends a narrow Permissions-Policy allowlist for the identity origin. If a browser requires first-party interaction, I redirect to the identity site, establish its session there, and return an origin-bound result without putting a bearer token in the URL.
After the grant, the iframe reads the first-party session, but origin checks, CSRF protection, authorization, and logout still apply. If access is denied, the product uses redirect login or a signed-out view and never loops prompts. I measure grants, denials, redirect completion, and failures by browser and origin, while keeping the fallback functional.
Common mistakes
- Error: Calling the API on page load → Why it fails: browsers require user intent and users cannot understand a surprise prompt → Fix: request only after an explanatory activation.
- Error: Treating success as global cookie permission → Why it fails: access is scoped and policy- and browser-dependent → Fix: check the promise for each embedded context.
- Error: Allowing every origin in
Permissions-Policy→ Why it fails: it enlarges the tracking and data-access surface → Fix: allowlist the identity origin on specific routes. - Error: Putting a session token in a redirect URL → Why it fails: URLs leak through history, logs, and referrers → Fix: use a short-lived, one-time, origin-bound result.
- Error: Repeating prompts after denial → Why it fails: it creates a hostile loop and still cannot force permission → Fix: switch to redirect or signed-out fallback.
Follow-up questions and responses
Can partitioned cookies replace the Storage Access API?
They can support an embed-specific bootstrap session, but they do not provide the same cross-site continuity as an unpartitioned first-party session. Choose partitioned state when isolation is acceptable; use redirect login when continuity matters and access requests are undesirable.
What if the iframe is sandboxed?
Verify that the sandbox preserves the origin and capability needed by the flow. If it makes the origin opaque or blocks the API, fail closed and use a first-party redirect. Do not weaken the sandbox globally just to make one embed work.
Does a granted storage access remove CSRF risk?
No. The iframe can send cookies after access, so state-changing endpoints still need CSRF defenses, origin validation, same-site cookie settings where applicable, and authorization. Storage permission changes reachability, not request intent.