最初，让我写这个，我是拒绝的，后来，面试被问到，炸了，虽曾看过，却不曾记之，俗语有言：好记性不如烂笔头，这波，GG。
虽然，我写了这篇博客，但是，你要想多了解点内容，还是去看别人的稳，文章里放的链接都是我整个看完觉得不错的，大家有兴趣直接移步，妥！
web常见的安全问题：
1. XSS (cross site scripting 跨站脚本攻击)
XSS用最简单的话介绍就是通过在输入内容中插入可执行代码达到影响/攻击/获取信息目的，所以可以将XSS问题理解为如何插入代码(攻击方)和如何过滤输入(防御方)的一个PK过程。这个过程其实是非常有趣斗智斗勇的，有兴趣的同学可以搜一搜相关内容，之前看过一篇生动形象的博文，可惜没有收藏，然后找到一篇很像的关于XSS与CSRF(此文有六年，这六年间又有了一些新东西，不过还是非常有参考意义)。
作为web开发者，如何防范XSS？
1. 将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了；
2. 表单数据规定值的类型，可以使用pattern正则判断合法性，减少可能的意外发生概率；
3. 对数据进行Html Encode 处理（主要针对< > ’ “等可能形成运行代码的字节）；
4. 过滤或移除特殊的Html标签， 例如: <script>, <iframe> , < for <, > for >, " for；
5. 过滤JavaScript 事件的标签。例如 “onclick=”, “onfocus” 等等；
6. 文本区域使用innerHTML，这样出现的<script>内容就是不会运行的（也要防范用户插入img onerror）。
2.CSRF(Cross Site Request Forgery, 跨站请求伪造)
参考文章： CSRF攻击的应对之道
简介： CSRF是诱导用户发送请求给被攻击站点，从而到达某些目的。
防范方式：
- 验证 HTTP Referer 字段：http请求头中有一个referer字段，值为请求方的地址，服务端可以通过拦截验证referer的值，判断是否为合法请求，此法无法保证完全安全(某些老式浏览器可以更改referer，某些用户会不发送referer)。
- 增加token：在请求时增加一个token参数，服务端解析session获取token，如果没有值或者值不匹配则认为是非法请求，弊端是麻烦，而且无法保证完全安全(攻击者伪造token，referer泄漏等)。
- 在 HTTP 头中自定义属性并验证：此法是直接给XHR增加请求头字段，服务端再检测字段，这样安全性较高(不会被浏览器记录，不会因为referer泄漏)，但是老系统增加此方式很工作量很大，且会影响用户一些正常体验，最好选择性增加。
关于XSS和CSRF的关系知乎有比较简单易懂的回答大家可以参考：如何用简介生动的语言说明 XSS 和 CSRF 的区别？
web安全还有一个之前比较火的SQL注入，不过现在服务器开发多数已经形成了可以有效避免SQL注入的变成习惯（有意或无意），而且数据库也都有权限控制，所以一般的SQL注入现在很难行得通，当然开发人员也要注意，常在河边走哪有不湿鞋。