我有可靠的合作伙伴，我想让他调用我的Iframe并添加一个JS / css文件路径作为参数，我会这样称呼它：
<script type="text/javascript" src="@(HttpUtility.UrlDecode(HttpContext.Current.Request.Params["CustomJs"]))" ></script>
<link type="text/css" media="screen" href="@(HttpUtility.UrlDecode(HttpContext.Current.Request.Params["CustomCss"]))" rel="stylesheet" />
这是为了让他能够挂钩设计并注册一些JS钩子。 合作伙伴是值得信赖的，并且会签署一份文件，证明JS / css的使用仅适用于将从我们这边调用的允许函数。
问题是，我是否将我的客户暴露在任何形式的危险情况下（假设合作伙伴都没问题）。
全部属于ssl
什么是安全风险。
由于
答案 0 :(得分：2)
风险在于，如果您的合作伙伴的安全性受到损害，您的系统也将变得不安全。假设，如果攻击者以某种方式将恶意代码添加到您的伙伴的脚本中，则代码可能会传递给您的系统。这与跨站点脚本攻击http://en.wikipedia.org/wiki/Cross-site_scripting高度相关。
为了规避这种风险，我建议为这些JS / CSS文件实施一个主持代理。例如，一个ASP.NET处理程序（.ashx）将调用合作伙伴的站点以获取原始脚本并将它们存储在内部（可能在数据库中），而有问题的帧通过使用处理程序来获取脚本和CSS。类似的东西：
<script ... src="ModeratedProxy.ashx?partner=abcd&file=efg.js"></script>
如果合作伙伴更改脚本，处理程序将通知网站所有者，甚至可以允许预先审核任何外部文件。
答案 1 :(得分：1)
由于CSS和JavaScript在框架中嵌入到文档中而不是直接嵌入到文档中，因此CSS仅应用于框架的文档。
框架的JavaScript是否可以访问文档的DOM有点复杂。因为这里应用了Same Origin Policy。但除非您和您的合作伙伴共享相同的来源，否则您的合作伙伴的JavaScript无法访问您的文档的DOM并从中读取数据或更改它。