如何防范针对API Key与API Secret的MITM攻击？Facebook、Instagram是如何防护的？

• 所有API调用强制走TLS 1.2及以上版本的HTTPS链路，禁止明文HTTP传输，客户端要严格校验服务端证书合法性，禁用自签证书信任、忽略证书错误的配置
• 不要把API Secret直接放在请求URL或者请求头的明文字段里，优先用签名机制：把请求参数、时间戳、nonce随机值和API Secret拼接后做哈希（比如HMAC-SHA256），服务端用相同规则验签，就算流量被截获，攻击者拿不到Secret也没法伪造合法请求，同时时间戳+nonce的配置可以避免重放攻击
• 给API Key设置最小权限，同时绑定调用IP、请求域名、过期时间，就算密钥泄露也能把损失降到最低
• 客户端不要硬编码存储API Secret，移动端、前端JS里禁止明文存放Secret，敏感密钥要存在安全加密容器里，比如安卓的Keystore、iOS的Keychain
• 敏感接口开启双向TLS认证（mTLS），客户端和服务端互相校验证书，避免中间人造假链路

• 所有开放平台API默认只支持TLS 1.3+的HTTPS访问，强制禁用TLS 1.0/1.1等存在漏洞的旧版本协议，同时启用证书透明度（CT）校验，避免伪造SSL证书被信任
• 开放平台接口统一要求签名鉴权，不允许API Secret直接在传输链路里出现：开发者调用接口时需要按照平台给定的规则，把请求参数、时间戳、App Secret共同生成签名，平台后台验签通过才会处理请求，就算流量被MITM截获也不会泄露Secret
• 平台会实时监控API调用的异常行为：比如突然变更的调用IP、异常高频请求、签名错误频次过高的情况，会直接拦截请求并给开发者推送告警，必要时会临时冻结有风险的API Key
• 针对Web端调用的场景，平台提供OAuth 2.0的授权码模式，前端只拿有效期极短的access_token调用接口，不会接触到App Secret，从根源上避免密钥泄露风险

绝大多数主流平台都会落实基础的服务端防护措施，但不会承担所有攻击风险，责任划分通常遵循权责对等原则：

• 平台层面会负责传输链路的基础安全、签名验签机制的实现、异常流量的监控拦截、密钥存储的服务端安全，这些属于平台必须提供的基础能力
• 开发者侧需要自行遵守平台的安全规范：比如不要泄露API Secret、不要在前端明文存储密钥、严格校验证书、按要求生成签名，如果因为开发者自身不规范使用导致的密钥泄露、MITM攻击损失，平台通常不会承担责任
• 正规平台的开放平台协议里都会明确写明双方的安全责任，不会让用户承担所有非主观因素导致的风险，但是如果用户故意绕过平台安全机制（比如关闭证书校验、明文传输密钥）导致的问题，责任由用户自行承担

内容的提问来源于stack exchange，提问作者Eduard6421