客户端发送HTTP请求调用API发送验证邮件是否安全？

你担心的风险100%存在。所有运行在用户侧的客户端代码本身就是不可控的，攻击者完全不需要修改你的客户端代码，直接通过抓包就能拿到你发信API的请求地址、参数格式，用curl、Postman这类工具就能随意发起请求，完全绕开你在客户端写的所有校验逻辑。

要规避这类风险，核心原则是所有关键校验逻辑全部放在服务端实现，不要信任任何来自客户端的请求参数，具体可以按以下规则落地：

• 发信接口不能无限制触发，服务端必须先过前置校验再执行发信逻辑：
  • 仅当用户刚提交注册/换绑邮箱请求、提交的邮箱格式合法、对应账号未完成邮箱验证、且距离上一次向该邮箱发验证信的间隔不小于60s时，才允许触发发信
  • 生成的验证token必须为长度足够的不可预测随机字符串，存储在服务端（数据库/Redis均可），关联对应用户ID、过期时间、使用状态，不要把token的生成、校验逻辑放在客户端
• 接口加多层限流规则：同一个IP地址1分钟内最多请求发信5次，同一个邮箱地址1小时内最多请求发信3次，避免被恶意调用刷爆你的邮件服务配额
• 验证通过逻辑完全由服务端控制：仅当用户点击邮件内的验证链接、服务端校验token有效、未过期、未被使用时，才将对应账号的邮箱验证状态改为已通过，绝对不要接受客户端直接提交的「验证完成」请求
• 所有邮件服务的敏感配置（比如邮件服务商API密钥、发件人账号密码）全部存在服务端环境变量中，不要在前端代码里出现任何相关内容

如果要进一步降低非法调用风险，可以给发信接口加CSRF校验，同时配置CORS规则仅允许你的业务域名跨域调用，不过这两项只能阻挡普通的浏览器端恶意调用，防不住脚本/工具类的请求，所以不能替代前面的核心校验逻辑。

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