我的一些个人总结
1.web 攻击
最主要的攻击方式，另起一文详细说明；
其实攻击针对的主要还是服务端，毕竟拿到客户端再多的数据用户也不大；
2.使用不安全的接口
很多接口对外开放权限-导致不需要校验既可以进行查询（爬虫抓数据），甚至是update、delete操作；
对来访的IP做校验，加ip/域名黑白名单。对外部环境设置ip黑名单，对内部环境设置ip/域名白名单；
使用上层服务检测来访请求中的参数信息：B参数、C参数、登录信息、token；
使用不加密的请求参数；
使用https的方式不正确（不理解……）；
使用抓包工具/http调试工具，篡改请求；
3.Android/IOS文档目录权限开放
注意不要有开放访问/修改权限的文件；
Android的静态文件中字符串要加密，防止篡改；
对发出的请求做校验，只可以发出指定域名的请求（Android、IOS有现成的方法，可以在官网上查到）；
本地文件（Share Preferences等）/数据库中尽量不存储数据，存储数据时必须加密；
4. Android root、IOS 越狱提升权限拿到隐私数据
检测如果是root权限或者已经越狱的话，禁止启动；
注意，有些第三方工具可以hook检测越狱或者root的方法；
5.SO文件、dex文件逆向
重要的代码存在SO中；
加壳，使用第三方加壳工具；
代码混淆（聊胜于无）；
6.使用过时的加密方式
过时的MD4、MD5等等等等，记不住了，网上解密的工具已经很成熟（CMD5）
不要自己定义一个新的加密规则（本地可破解）
推荐3DES、RSA（客户端支付常使用），还有一种忘了……
7.不安全的登录信息
登录信息保持过长（也得看业务要求，维持个折中的方案）
验证码失效时间过长、验证码保持有效性的bug
8.接口和网站链接命名不好，攻击者直接暴力撞号\撞库
更改链接命名
校验来访IP，自动加入（临时）黑名单
9.用户跳过身份验证
beta测试时，注意设计这方面的测试用例；
使用工具adb直接调用activity，测试人员在beta测试中设计相关测试用例（不仅如此，使用adb直接调起activity后，可以自己设置参数发起特殊的请求进行SQL注入等攻击）；
10.将测试中的调试信息打印到logcat
严格控制测试、调试信息发到线上，调试入口在发布时必须关闭；
限制日志的级别，测试人员必须注意