浏览器使用小记 – Content-Security-Policy

个人博客

最近重度使用网关 Kong，对接了一堆难搞的存量系统，遇到很多问题，先扔一个：当 Kong 转发请求后，第三方的响应内容里拼接了完整的资源请求地址，但它看到的只是 Kong 剥掉 https 壳以后的 http 请求，所以拼接出来的地址是 http://…. ，到了浏览器端，根据该地址发起 http 请求时，就会被浏览器 block 掉，开 debug 可以看到提示 csp 或者 mixed。

在有多个组成环节的情况下，一个问题通常就会有多种解法（甩锅应该更形象）。就目前这个问题，淡化 PaaS/CaaS 等设施的情况下，参与环节可以聚焦到三个：客户端浏览器 — Kong 网关 — 存量X系统。

最直接的想法就是由 X 系统自行调整，从尽量减少耦合的角度来说，一个系统应该尽量不了解其他系统的知识，不应该拼接完整的 url 请求地址，最好是能根据 rfc7231 里的描述改用 relative url absolute path，完整的请求地址则交由客户端浏览器去拼接。

然鹅存续时间比较长的企业里，历史积累下来的各种存量系统情况一般都比较复杂，存量 X 系统无力调整。秉着网关尽量透明的原则，分析处理之。

回到最开始浏览器提示的 CSP 问题，CSP 即 Content-Security-Policy，因为我们的网站在浏览器端是通过 https 访问的，从一个 https 的网页上发起 http 请求，属于安全性降级的操作，被认为是不安全的，所以浏览器直接 block 掉。

但是这种情形实际上并不少见，比如我的网站以前去第三方请求了一些资源，当时大家都是 http，没啥问题，后来我一夜之间升级到 https 后，因为浏览器安全策略可能就加载不到这些资源了。

这下咋办？标准里打了一个补丁，允许通过设置 upgrade-insecure-requests（字面意思：升级不安全的请求），告知浏览器自动将 http 的请求替换为 https 的请求。

按这个思路，在返回的第一个响应经过 Kong 时，设置上【content-security-policy: upgrade-iinsecure-requests】就可以了。

ps：csdn 啥时候又上了个尬到抠脚的发文助手，这么搞吃枣药丸