Web API 的安全标头

信息安全 代理人 api 标题
2021-08-19 17:50:22

我刚刚得到了一个设置，一个在默认情况下通过 Let's Encrypt 具有 HTTPS 的 caddy 服务器后面的 golang web api，服务器代理了对 web api 的所有请求。所以我在securityheaders.io等网站上测试了我的网络服务器“安全性”。他们给了我一个 F，所以我添加了他们要求的标题，我得到了一个 A

Access-Control-Allow-Methods "GET, POST, OPTIONS"
Strict-Transport-Security "max-age=31536000;"
Content-Security-Policy "script-src 'self'"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
-Server

这些是我目前拥有的标头，但我想知道当我制作的不是网站而是 API 网络服务器时，它们是否对安全性是必要的，例如

Access-Control-Allow-Methods "GET, POST, OPTIONS"
-Server

所以基本上，如果您只想请求您的 API，所有这些安全标头都是必需的吗？

1个回答

从列表中检查标题并不是断言站点安全性的最佳技术。securityheaders.io之类的服务可以为您指明正确的方向，但它们所做的只是与建议的设置列表进行比较，而没有任何关于您的应用程序的上下文。因此，一些提议不会对只提供 JSON 响应的 API 端点的安全性产生任何影响。

  • Strict-Transport-Security这是有道理的，因为它保证用户在第一次访问后直接通过 HTTPS 连接到您的站点，直到max-age达到超时 - 从而防止降级攻击。即使是 API 端点也应该使用 SSL 保护，因此请保留该标头。

  • Access-Control-Allow-Methods: GET, POST, OPTIONS本身不是一个安全选项。如果您的 API 通过CORS预检请求工作，您需要决定允许跨域站点使用哪些方法。禁用 CORS 可能会使您的 API 不可用。该特定设置是否合理取决于您的实施。

  • X-XSS-Protection: 1; mode=block对于常规站点来说可能是一个很好的建议，因为它指示 XSS Auditor（在 WebKit 浏览器中实现，但不是在 Firefox 中实现）在检测到反射的 XSS 尝试时不呈现站点。但是对于只提供 JSON 响应且不提供活动内容的 API，此标头不会带来任何好处。

  • X-Content-Type-Options: nosniff如果站点没有正确声明类型，则阻止浏览器对内容类型做出假设。如果您正在运行 JSON API，您应该使用Content-Type: application/json. 如果您正确执行此操作，则无需添加nosniff指令。

  • X-Frame-Options: Deny防止任何网站将您的网站嵌入 HTML 框架中。该选项阻止点击劫持攻击，攻击者通过伪装的框架诱骗用户与您的网站进行交互。但如果没有交互元素，跨域框架的风险有限。然而，由于存在涉及将内容拖出框架的高级攻击，可能会泄露 JSON 响应，您可能仍希望将该标头留在那里。

  • Content-Security-Policy标头控制允许您的站点与哪些来源（脚本、样式表、图像等）交互的哪些内容。您的设置"script-src 'self'意味着只能加载来自同一来源的脚本。CSP 对于常规站点很有用，但对您的 API 端点没有意义，因为您不提供任何可以由 CSP 控制的活动内容。

  • 标Server头指定有关服务器和在其上运行的软件的信息。通常建议根本不发送该标头，以免披露有关后端软件和版本的任何信息。

其它你可能感兴趣的问题
上一篇密码在内存中吗？ 下一篇使用端口 80 检测非 HTTP 数据包