使用HTTP而非HTTPS调用GET API是否存在重大安全风险？

首先明确：用HTTP而非HTTPS调用这个API存在不可忽视的安全风险，远大于响应时间缩短带来的收益，具体风险分以下几点：

• 中间人攻击篡改响应，危害用户安全
  HTTP传输是明文的，攻击者可以在用户和服务器之间拦截并修改API返回的数据。比如你的JS原本要获取计算结果，攻击者可能把结果换成恶意数据，甚至植入可执行的恶意脚本，用户浏览器执行后会遭遇数据泄露、会话劫持，甚至设备被控制。

• API极易被恶意滥用，耗尽服务器资源
  虽然你认为用户无合理理由直接调用，但HTTP的明文特性让攻击者很容易通过抓包获取API的请求格式（路径、参数等），然后批量伪造请求。即便有服务条款限制，没有加密和身份验证的话，你很难区分合法调用和恶意调用，最终导致服务器资源被耗尽，正常用户的请求受影响，甚至产生额外的运营成本。

• 用户敏感数据泄露，引发合规风险
  如果API请求中附带了任何用户相关信息（比如会话ID、用户标识），HTTP传输会直接把这些数据暴露给网络监听者。攻击者拿到这些信息后，可以冒充用户进行操作，或者窃取用户隐私，这会让你的服务违反数据保护相关法规（如GDPR、《个人信息保护法》），面临处罚。

• 浏览器安全限制导致服务异常
  目前主流浏览器对HTTP内容的限制越来越严格：如果你的主站是HTTPS，调用HTTP API会触发混合内容警告，用户看到后会不信任你的服务；未来浏览器可能直接禁止HTTPS页面加载HTTP资源，届时你的API调用会完全失效。

关于响应时间的顾虑：HTTPS的握手延迟可以通过多种优化手段降到极低，比如启用HTTP/2、配置SSL会话复用、使用CDN加速SSL握手，这些措施完全可以抵消HTTPS带来的微小延迟，没必要为了这点速度牺牲安全。

建议措施 #

• 立刻将API切换到HTTPS，这是最基础的安全防线。
• 给API添加身份验证机制（比如请求签名、专属Token），确保只有你的合法JS代码能发起调用，进一步防止滥用。
• 配置API请求频率限制，即便被抓包，也能有效限制恶意调用的影响范围。

内容的提问来源于stack exchange，提问作者D'Arcy