安全性极差的 API 很常见。恰当的例子 - TechCrunch 上的this story。
这引出了一个问题，在 SSL 方面，您如何平衡安全性和性能？显然，用户名和密码等敏感信息应通过 SSL 发送。可能使用 API 密钥的后续调用呢？对于需要身份证明的 API 调用，什么时候可以使用未加密的连接？
【问题讨论】：
标签： security http api ssl https
如果允许混合内容，那么中间人可以重写混合内容注入 JS 来窃取页面中已有的敏感信息。 在咖啡馆等提供免费无线接入的情况下，中间人攻击并不是那么困难。
https://www.eff.org/pages/how-deploy-https-correctly 给出了很好的解释：
在托管应用程序时 HTTPS，不能有混合内容； 即页面中的所有内容必须 通过 HTTPS 获取。这是常见的 请参阅站点上的部分 HTTPS 支持，在 主要页面是通过哪些 HTTPS，但部分或全部媒体 元素、样式表和 JavaScript 页面中的内容是通过 HTTP 获取的。
这是不安全的，因为虽然 主页加载受到保护 主动和被动网络攻击， 其他资源都不是。如果一个 页面加载一些 JavaScript 或 CSS 代码 通过 HTTP，攻击者可以提供一个 假，恶意代码文件并采取 页面加载后的 DOM 上。 然后，用户将返回到 没有安全感的情况。这 这就是为什么所有主流浏览器都会发出警告 用户关于混合加载的页面 内容。参考也不安全 图像通过 HTTP：如果攻击者怎么办 交换了保存消息和删除 网络邮件应用中的消息图标？
您必须为整个应用程序提供服务 域通过 HTTPS。重定向 HTTP 使用 HTTP 301 或 302 的请求 对等效 HTTPS 的响应 资源。
【讨论】：
问题在于，如果不了解应用程序的性能，那么在没有指标的情况下尝试优化应用程序是错误的。这就是导致开发人员决定让 API 不加密的原因，只是认为它正在获得另外 10 毫秒的性能。简而言之，平衡安全问题与性能的最佳方法是首先考虑安全性，从真实客户那里获得一些负载（而不是某些架构师痴迷的白板棒图），并在您怀疑性能可能是问题。我有一种奇怪的感觉，它不会与安全相关。
【讨论】：
您需要收集一些关于所谓的 SSL 性能问题的证据在您跳跃之前。你可能会得到一个相当大的惊喜。
【讨论】：