只要您依赖传入的用户信息，您就永远不会受到完全保护/安全。任何东西都可以被欺骗、改变、修改；随后，您的组件现在受到了损害。

如果您想走保留一些信任的路线，那么将其列入白名单是有意义的。然而，更进一步可能更理想——您发行令牌来代替指定域（想想谷歌分析如何在 mysite.com 上使用 UA-XXX 号码）。将管理推回他们的 Web 管理员，现在他们的责任是出现错误域/安全漏洞的可能性。

为了进一步详细说明我所指的内容，而不是拥有一个许可名单，而是设置一个令牌数据库：

tokens
id       # Primary Key
token    # Unique generated token

然后，有一个 1:* 关系，可以为该键定义有效的来源：

origins
id       # Primary key
token_id # Forieign Key, tokens.id
origin   # origin (e.g. google.com)

然后为特定客户（将在其页面上包含您的组件的任何人）创建一个令牌。例如，假设我们有令牌abc123def456：

<iframe src="http://server.com/component?key=abc123def456"></iframe>

在这里，您的组件将对您的tokens表执行服务器端查找并进行验证。您还可以对Referer标头添加额外的检查，但这取决于您（并意识到Referer 无论如何都可能被欺骗）。默认 bahvior 是 to deny *，所以你会显示一个页面说“没有指定来源，请配置”（或类似的东西）。

接下来，他们登录到管理页面并添加“abc.com”。现在，小部件变为：

<iframe src="http://server.com/component?key=abc123def456&origin=abc.com"></iframe>

现在，服务器端，您正在验证密钥和来源（针对您在表中编译的允许origins列表（与该密钥相关联）。如果黑客试图使用（或修改它）一个无效的来源（相对于键）会反弹并显示错误页面。

如果他们决定不指定原点，您还可以配置默认原点，这样只要您包含/component?key=abc123def456它就假定默认原点。

或类似的东西

当我听说白名单时，它让我回到了防火墙的历史。

首次使用防火墙时，它们的运行方式是“默认接受所有内容，但拒绝的内容除外”。这给早期的防火墙和系统管理员带来了很多问题，因为他们必须主动掌握威胁并将其添加到拒绝名单中。

当业界意识到这个问题并切换到当前的“默认阻止所有内容，除了允许的内容”的系统时，这大大减少了威胁形势和系统管理员团队的压力。

再次面对这个问题时使用这个类比。这应该能说服大多数人。

最后，我找到了一个用于 XSS 攻击的 PoC。该组件在如下调用时易受攻击：

http://my-server.com/component?origin=javascript:alert%28%27Hello%20world!%27%29

它证明了一旦用户单击组件生成的链接，恶意脚本就有可能运行。

最后我们的队友接受了强化组件。

他没有选择允许列表，而是选择检查该origin值是否为有效 url。