Question

we have a site with Iframes pointing to dynamic Urls (by user input).
In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.

Is this assumption correct?
Is there any solution for this?
Any other suggestions?

Thanks,
Tal

Answer 1

we have a site with Iframes pointing to dynamic Urls (by user input). In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.

So it sounds like you are making a sort of "browser in a web page."

For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)

Yes, except not many things have onerror events. I assume you are aware of this from your comments on other answers. If I understand you right, you’re talking about using a dummy script element to load the URL first (as a script, even though it’s not really a script), and determine whether the URL is valid using the using onload/onerror handlers for the script element (onerror will not fire on a script error, only a network error).

This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.

Is this assumption correct?

Your assumption is correct. If the URL actually does contain a script, it will execute in the user’s browser in the same domain as your site.

Is there any solution for this?

A simple workaround might be to do something like what jsfiddle.net does… have a separate subdomain act as a "firewall" between the third-party content and your real domain.

Any other suggestions?

The script preload hack is really just that, a hack. It misappropriates the script tag and makes needless requests. I would probably look into using XHR to fire off a HEAD request instead, or doing some light server-side proxying.