很多时候很多企业 尤其是初创企业在进行项目开发的过程中为了能尽快的实现项目上线赚钱，往往都是会忽视掉如何安全的去开发，一开始企业业务没做大还好，等业务做大了就漏洞百出，各种修补，由市场去检验到的安全问题往往意味着损失已经发生，所以在项目设计到开发 把安全这块考虑进去是非常重要的。
一般前端在开发中应该如何做到安全去开发呢？以下总结了下我的开发经验：
1.防止关键接口按钮无限点击
危害：假如不良用户在一个关键接口无限点击 就相当于直接dos攻击后台接口 这会导致后台服务器响应负载无限大，严重的话会导致服务器宕机！
措施：1.设置每次按钮可点击时间 2.加个加载动画 3.点击后将按钮置灰，并disabled设置为true;并将文字设为 正在加载中 后台响应后再打开 4.后端人员要进行数据库的唯一约束设置 或者是联合约束设置
2.防止接口地址直接暴露在网页中
危害：接口如果直接暴露 相当于告诉不法分子 我在这 来打我啊 这种极具挑衅行为当然不提倡
措施：在关键接口尽量使用 post方法 并对关键字段加token，上线时要对源码进行压缩 混淆。
3.防止接口传输内容被抓包
危害：接口内容被抓包的危害无异于将密码直接暴露在不法分子面前 不管使用什么验证码都无效的 危害是不言而喻的
措施：对关键内容进行hash处理 使用https协议 获取设备IP并绑定
常见的处理方式：
安全机制的设计
现在，大部分App的接口都采用RESTful架构，RESTFul最重要的一个设计原则就是，客户端与服务器的交互在请求之间是无状态的，也就是说，当涉及到用户状态时，每次请求都要带上身份验证信息。实现上，大部分都采用token的认证方式，一般流程是：
- 用户用密码登录成功后，服务器返回token给客户端；
- 客户端将token保存在本地，发起后续的相关请求时，将token发回给服务器；
- 服务器检查token的有效性，有效则返回数据，若无效，分两种情况：
- token错误，这时需要用户重新登录，获取正确的token
- token过期，这时客户端需要再发起一次认证请求，获取新的token
然而，此种验证方式存在一个安全性问题：当登录接口被劫持时，黑客就获取到了用户密码和token，后续则可以对该用户做任何事情了。用户只有修改密码才能夺回控制权。
如何优化呢？第一种解决方案是采用HTTPS。HTTPS在HTTP的基础上添加了SSL安全协议，自动对数据进行了压缩加密，在一定程序可以防止监听、防止劫持、防止重发，安全性可以提高很多。不过，SSL也不是绝对安全的，也存在被劫持的可能。另外，服务器对HTTPS的配置相对有点复杂，还需要到CA申请证书，而且一般还是收费的。而且，HTTPS效率也比较低。一般，只有安全要求比较高的系统才会采用HTTPS，比如银行。而大部分对安全要求没那么高的App还是采用HTTP的方式。
我们目前的做法是给每个接口都添加签名。给客户端分配一个密钥，每次请求接口时，将密钥和所有参数组合成源串，根据签名算法生成签名值，发送请求时将签名一起发送给服务器验证。类似的实现可参考OAuth1.0的签名算法。这样，黑客不知道密钥，不知道签名算法，就算拦截到登录接口，后续请求也无法成功操作。不过，因为签名算法比较麻烦，而且容易出错，只适合对内的接口。如果你们的接口属于开放的API，则不太适合这种签名认证的方式了，建议还是使用OAuth2.0的认证机制。
我们也给每个端分配一个appKey，比如Android、iOS、微信三端，每个端分别分配一个appKey和一个密钥。没有传appKey的请求将报错，传错了appKey的请求也将报错。这样，安全性方面又加多了一层防御，同时也方便对不同端做一些不同的处理策略。
另外，现在越来越多App取消了密码登录，而采用手机号+短信验证码的登录方式，我在当前的项目中也采用了这种登录方式。这种登录方式有几种好处：
- 不需要注册，不需要修改密码，也不需要因为忘记密码而重置密码的操作了；
- 用户不再需要记住密码了，也不怕密码泄露的问题了；
- 相对于密码登录其安全性明显提高了。
参考 阿里云： https://www.aliyun.com
资深黑客教你如何攻破一个网站 ：https://blog.csdn.net/qq_42156420/article/details/80791820?utm_source=blogxgwz2