问一个关于 https 和伪造域名请求数据的问题

[rizon]

本人对这些不是很了解，出于爱好涉猎相关的东西，问题如下：

我有一个页面，其中的 js 脚本会请求某第三方服务，服务可以设置域名安全。

1. 比如我把域名设置为 http://example.com ，但是其他人可以通过简单的例如配置 host 来实现模拟这个域名发出的请求。

   问题 1： 如何模拟一个域名来发出请求?

2. 然后我就换个方式把后台服务的安全域名设置为 https://exapmle.com ，这样对方就无法模拟我的域名来进行 https 请求了

   问题 2：因为 https 请求必须使用证书，而且证书的签证域名必须是经过验证是你所有的，因此 https 的请求是无法伪造的，我这样理解是对的吗？

引伸问题 3:对于没有后台服务的纯静态的前端页面，因为没有后台接口都是写 js 调用 api，因此如果调用一些第三方服务的 API，势必会导致要把 authKey 这一类的东西暴露出来，就会存在被人恶意利用 authKey 来伪造请求，有什么办法可以保证安全的办法吗？

[printempw]

虽然我不晓得你是从哪家的文档里看来个「 Web 安全域名」这种神秘的词，不过一般来说基于请求的来源域名进行访问控制的方法就是检查 HTTP 请求头中的 Referer。

正常来说，某个站点下发出的所有 HTTP 请求（图片、脚本资源 etc.没）的 header 中都会被浏览器附上一个 Referer 头，用于告诉服务器这个请求是从哪个页面发起的（ http://example.com ）。但是这个 HTTP 请求头是可以随意修改的，所以伪造起来也很容易。另外一种方法就是别人直接把你的域名（ http://example.com ）通过修改 host 指向他自己的服务器，这样浏览器在访问假网站时发起的资源请求也会带上 Referer: http://example.com 的头了。

所以：

1. 服务器端看到 Referer 在你设置的「 Web 安全域名」中时（虽然是伪造的），自然就会放行。

2. 不。人家照样可以直接手动构造含有 Referer 的请求，也可以设置 host 后用自签发证书搞定浏览器。API 服务器那边哪会管那么多，一般看到 Referer 对就让过了。

3. Google it.

看这帖子十几个小时没人回复还蛮可怜的，就稍微献下丑。另，我挺久没关注这方面的东西了，也有可能最近有什么更好的根据请求来源地址限制访问的方法也说不定。如果我上面哪里说错了，还希望各位大佬不吝赐教 :P

[rizon]

@printempw 非常感谢