如果传输本身是安全的（即 https），攻击者就无法嗅探数据。但它可能会记录在服务器端，服务器可能会在以后受到威胁，或者某些安全漏洞可能会导致日志文件公开可见。此类日志文件通常包含 URL，并且如果使用自定义日志格式指定，它们可能包含来自标头的其他行，例如 User-Agent、Referer 和其他标头。因此，将这些 API 密钥放入请求标头中可能是个坏主意，除非您确保它们不会被记录。

反对将密钥放在请求正文中的一个论点是，现在可以创建一个简单的 HTTP 表单，其中包含更容易用作 CSRF 请求的密钥。当包含 API 密钥作为标头时，攻击者必须能够执行 XHR 请求并受到CORS的限制。

不将密钥包含在 URL 中的另一个原因是它可能会包含在后续请求的 Referer 标头中。此外，URL 通常包含在浏览器历史记录中，这样您就有了另一个可能受到威胁的地方。这仅与正常的浏览器请求相关，即应用程序完成的 XHR 或 REST 请求不受影响。

关于“header”含义的一些解释：有时使用名称“header”来区分HTTP消息的初始部分和正文。在这种情况下，URL 是标头（请求行）的一部分。其他时候，一个人谈论标题（复数）并且仅表示“字段：值”对，即不包括带有 URL 的请求行。我不清楚问题中使用了哪个含义，所以我最好同时涵盖两者。

我认为在 HTTP 标头中使用它并没有显着的安全优势（不包括在启动 HTTP 请求的请求行中发送的 URL，您必须更加意识到它被记录在浏览器历史记录中或服务器日志）与在 POST 请求正文中。

在“授权标头或自定义 X-API-KEY 标头”中发送密钥的优点是 API 中多个方法之间的分离和一致性。也就是说，您可以通过检查 API 使用的标头字段来处理 GET、POST、PUT 等方法的相同服务器代码的身份验证。此外，如果用户需要在请求正文中提交其他 POST/PUT 数据作为其 API 请求的一部分，则将其与身份验证数据分开。