之前遇到过。前端没办法立即加验证码，而那边却在呼呼的耍短信。
当时的解决办法是：
服务器关掉端关掉对短信验证码的请求。
对向服务器请求短信验证码的接口，服务器直接把返回的errorCode设置为异常代码，可以被前端捕获，然后把验证码写到错误信息中，弹出来。这样用户还是可以看到验证码的。

然后再坐下来加图片验证等等

1.每个手机号每天只能调用10次短信接口.
2.每个手机号每分钟只能调用1次.
3.采用token,做好效验.

我原来想的是有同源策略就不会有外域能调用，但是后面发现还是有人能用工具搞定，我司采用的是

1. 将用户的当前ip+mobile 存入memcached的key里 ,value 为时间戳大家知道怎么玩，到时候取出来算算

2. 禁止可能出现的跨域请求

3. 服务端在页面对前端生成类似CsrfToken的令牌，在提交时与后端验证，一次只能验证1个，成功你需要生成新的令牌给前端，因为要考虑可爱的用户有时等待时间什么的，不然用户体验差

但是看到楼主说的有人能换ip 换号码调用，我想的是这样的话就复杂了，啥样的都能搞出来的赶脚

坐等楼下精彩解答

告诉你们个内幕: 很多是短信提供商给刷的, 创业公司很少有那闲功夫去搞竞争对手!

更别说有集群的服务器切换IP去刷, 那是个地下产业链

另外, 简单的图片验证码, 还是能破解的

增加发送前验证，必须手动才能生成的那种，比如拖动验证码、拼图验证码；token令牌验证，让每个表单提交只能使用一次

验证码不能太简单，注意过滤ip，小项目推荐引入第三方验证服务。

图文验证码+参数经过加密生成sign+参数去服务端做校验

之前我们也遇到过相同的问题，当时的也是不能改前端，后来分析一下请求数据包的共性，因为是用工具批量发的，请求头上有一些特征，我们的接口判断到这些特征后直接返回200，不走后面的业务逻辑。

直接返回200的原因是不想让对方知道我们已经采取了防御措施，避免他们进一步攻击。

以下思路仅供参考：

1. APP发版出去了，别人却能够用脚本来跑接口，第一感觉这是安全性没做好，线上的接口一定要开启https访问。这样别人来抓包的难度也会大很多。

2. 我个人感觉，发送短信的接口可以不暴露给前端，也就是说无法通过直接调用某个接口来发送短信，可以作为一个后端服务，仅暴露给API来访问。发送短信的逻辑可以写在注册，登陆等的逻辑里面。

3. 对参数进行一次校验，比如可以将请求参数以某种规则组合成某个唯一的值，服务端拿到参数后以相同的规则组合出来看下是不是和校验值一样，如果一样则继续进行操作，如果不一样报错给客户端，这样别人在调用你的接口的时候还需要破解你的这个校验规则，这个规则越难破解，别人通过接口调用也就越难。

4. 其他的限制可以参考楼上各位大神的思路。

ip与手机绑定的形式不好，正常的用户可能会无法使用
1、限制手机号发送验证码的次数
2、验证码
3、token