Blocked autofocusing on a <input> element in a cross-origin subframe

Question

In our web app/site, I need to use an iframe or a popup window to validate if the current token is valid and refresh it if no.

So, I create an iframe, and set the property 'src' to the validation link such as "https://<domain_name>/auth?client_id=xxx" which is different to our app domain https://<app_domain>. and the return value will like "https://<domain_name>/code=yyyy"

document.createElement('iframe');

and I added the message handle for the web app/site, like

window.addEventListener("message", this.messageHandler);

in the messageHandler, I will check if the message is from a specified website, and then validate the "code" value, blabla, etc.

But when running in Chrome, I always got the error "Blocked autofocusing on a element in a cross-origin subframe."

what confused me is:

1. it always failed when running in the Chrome browser, but it can work fine in Firefox and Edge chromium.
2. I tried to set iframe.sandbox = "allow-forms allow-scripts allow-same-origin", the problem still existed.
3. If the validating token failed in iframe or timeout, I will create a popup window to continue validating and refresh the token. But every time, using popup window can always succeed. If it is really a cross-origin issue, why using iframe failed but using popup window succeeded.
4. I didn't use window.postmessage. because I don't know how to pass the return value of iframe/popup-window to the main page.
5. I used CORS extension of Chrome or using parameter --disable-web-security when launching Chrome. the problem still existed.
6. when I created the iframe or popup window. it is very simple, I just set the iframe.src property, there is no element being created.

any help will be much appreciated.

p.s. I refer to the following doc: Blocked autofocusing on a form control in a cross-origin subframe
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

Solution

Support for iframes in web development will only get worse over time as they are a security black hole, browsers are gradually over time locking out features and use of them.

I am assuming you are doing this because you are validating a user on a third party service, validating by watching the response of a third party service website?

Without knowing the service you are using I cannot comment specifically but for anyone looking to do something similar I would highly suggest not doing this:

• As mentioned, iframes are constantly having features locked down due to security concerns
• An attacker could change the source of the iframe and submit their own iframe to look like it has been correctly validated
• It's unlikely that the page you are using as your iframe src is intended for this use, which will come back and bite you when the 3rd party developer changes how their page behaves, which they likely will do without knowing it's going to break your application

I recommend:

• Finding a stable API the 3rd party service offers and using that
• Finding another service if none exist

Apologies to rain on your parade!

Comments

[Orionpax]

This is the 3rd party service we are using. (forge.autodesk.com/en/docs/oauth/v2/tutorials/…). I think it should be a stable API. We want to use the grant type to refresh our web app's access token by using iframe. because most of the time, there is no need to popup a window for the user to input credentials again. Using existing refresh token can do that.

[jmcgrory]

Looking at those docs and your example, I would go with opening in a popup rather than the iframe approach (why? see my comments on iframe security). _"If it is really a cross-origin issue, why using iframe failed but using popup window succeeded." Because unlike an iframe (which is loading a document with a different origin within your current document's origin, i.e. CROSS origin) you are visiting this separately (SEPARATE origins). Use the redirect_uri / client_id to link the authorisation back to the original client's session as the docs require.

[Jonathan Parker]

Isn't iframes the current best practice for OIDC with PKCE flow? Capturing a refresh token via an iframe means the token is not exposed to security issues that occur when it is shared between the authorization server and the browser via the URL. This blog post from 2019 suggests that iframes is the best way as of writing auth0.com/blog/oauth2-implicit-grant-and-spa