使用<脚本src=..查找站点的状态代码-安全问题

我们有一个网站，其中Iframes指向动态URL（通过用户输入）。如果出现404/500或任何其他错误，我们希望用不同的用户友好的其他URL替换Iframe源。

所以这听起来像是你在制造一种"；网页中的浏览器"

为此，我们可以使用oneror事件来识别动态网站何时出现问题。（然后，如果出现问题，请替换iframe url）

是的，除了中没有多少东西发生错误事件。我想你从对其他答案的评论中已经意识到了这一点。如果我理解正确的话，您说的是使用一个伪script元素首先加载URL（作为脚本，即使它不是真正的脚本），并使用script元素的onload/onerror处理程序来确定URL是否有效（onerror不会在脚本错误时启动，只会在网络错误时启动）。

这也适用于跨域url，但可能存在动态url可能是恶意的情况，并且当恶意代码将在我们网站的同一框架、同一域中执行时，就会出现这样的安全问题。

这个假设正确吗？

你的假设是正确的。如果URL确实包含脚本，它将在与您的网站位于同一域的用户浏览器中执行。

有什么解决办法吗？

一个简单的解决方法可能是像jsfiddle.net那样做。。。具有单独的子域作为"；防火墙"；在第三方内容和您的真实域之间。

还有其他建议吗？

脚本预加载破解实际上就是这样，一个破解。它挪用了脚本标记并发出了不必要的请求。我可能会考虑使用XHR来触发HEAD请求，或者做一些简单的服务器端代理。

是的，如果使用<script>标记嵌入远程JS文件，则会出现安全问题，因为代码将在页面的上下文中执行。

想到的唯一解决方法是向资源发出服务器端请求并解析响应标头。然而，这可能与客户端请求的行为不同，因为调用将来自服务器，因此它将具有不同的IP、不同的cookie等。

如果用户只能指定框架的URL，那么框架文档中的任何脚本都将在框架文档的上下文中运行，而不是在嵌入框架的父文档的上下文下运行。

在框架内运行的脚本是否可以访问父文档（即您的文档）的问题取决于两个文档的来源：只有当它们相等时，两个文档才被称为相同来源。只有在这种情况下，一个文档才能访问另一个文档。