现在前端肯定也需要知道安全问题，作为网站开发者，要保证基础的三点：

1. 保密性
   数据内容不能泄漏，加密是常用方法
2. 完整性
   数据内容不能被篡改，特别是现在oAuth盛行的年代，协议要求sign签名，就是保证双方数据完整。一旦信息被改会发生什么不言而喻
3. 可用性
   网站服务是可用的

常见前端攻击方式

DDos攻击，Dos攻击，SQL注入，XSS，CSRF等，D|Dos攻击是通过http协议本身特点，通过大量恶意请求导致服务器不能响应的攻击，防范这个问题需要运维或FireWall来做的，这里就不多说明，只简单说下FEer会接触到的几个。

在此之前，不得不说一个概念：安全沙箱。不知道的可以度娘一下

SQL注入

通过非法方式影响服务的正常有效运行，提供非正确的信息返回或不能正常服务。在前后端未进行分离的年代，sql注入是每个web开发者都需要熟知的。那时候访问的url就很容易猜到是哪个库表哪个操作，最著名的sql注入就是登录时user和password输入'1' or 2=2"' 如果没有对URI进行特殊符号转化，服务端sql脚本就可能出现

sql = "select * from user where user='1' or 2=2"' password='' " // 密码类似user的写法复制代码

sql查询条件是成立的，有可能会把整个库表的信息都返回，甚至也给暴力破解留下入口。

现在FEer可以不用考虑这一点，但是请求地址还是可以在network里看到，适当的加密和偏移还是需要的。当然，后端的安防是最最重要的，这里只说前端，node的代理或后端对于前端脚本的请求拦截找机会再做分享。

XSS（cross-site scripting）跨站脚本攻击

从本站发起，这是首要条件，因为安全沙箱的限制，非本站脚本不能操作cookie或dom，那么它如果攻击呢？

攻击方式：

• 用户输入
  例如：在某个评论页，输入了非法代码，后端未转译，或前端直接innerHTML插入。那么网站的保密性就没有了，造成的结果：

// 可能是div可能是a，不设防就可以随意添加dom测试链接// 各种脚本随意跑

• 第三方脚本引入
  症状和结果同“用户输入”，所以现在很多https网站下不能引用http的域名文件，就是防止http劫持带来的XSS问题。
• 劫持
  页面或js脚本被追加了某些内容，例如广告；最常见的是SP运营商这么干

防范手段

前端几乎没有安全一说，即便是加密的js代码也是可以反编译，所有的内容几乎都暴露在浏览器里。所以对用户的输入都是不可信的，即便是加密的js代码也是可以反编译，针对用户的输入，需要后端配合业务进行针对性的过滤和转译；并且根据攻击类型（反射、存储引用、DOM）进行相应的规则，“<a, <script, <Script，,'," ”等等，练css其实也可以进行js的hack，最好用innerText而不是innerHTML。如果业务实在需要匹配规则作好，允许的情况下就别让代码执行。

CSRF（cross-site request forgery）请求伪造

从第三方站点发起，利用cookie伪造成你的合法请求；一般钓鱼网站会这么干。还是因为安全沙箱的关系，攻击者不能拿到sessionid或标明合法身份的sign，但在页面中利用你未过期的cookie就可以发起攻击（浏览器关闭cookie还能有效呢？yes，就是tmd有可能不过期），新建tab进行其他网站的浏览也是常态。

防范手段

Referer验证，如果来源非本站，那么可以判定是非法请求；但是IE低版本和某些阉割浏览器这玩意是无效的；

token验证，每次提交需要用户输入验证码或拉动豆腐块等等，就是证明是人，是人，是人在提交； 头部自定义内容（加密），我在畅旅时跟后台通信会加上用户名密码的md5加密； 经过我自己的实际工作检验，虽然也是没什么用，但可以增加攻击难度；再有就是OTA或存在价格竞争的企业，爬虫扫描价格也是很常见的攻防大战；都是只增加难度，完全靠前端防范是不可能的。切切！

劫持与https

• DNS劫持
  DNS劫持就是通过劫持了DNS服务器，通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，其结果就是对特定的网址不能访问或访问的是假网址，从而实现窃取资料或者破坏原有正常服务的目的。DNS劫持通过篡改DNS服务器上的数据返回给用户一个错误的查询结果来实现
  症状：在某些地区的用户在成功连接宽带后，首次打开任何页面都指向ISP提供的“电信互联星空”、“网通黄页广告”等内容页面。还有就是曾经出现过用户访问Google域名的时候出现了百度的网站。这些都属于DNS劫持。再说简单点，当你输入google.com这个网址的时候，你看到的网站却是百度的首页。
• http劫持
  在用户的客户端与其要访问的服务器经过网络协议协调后，二者之间建立了一条专用的数据通道，用户端程序在系统中开放指定网络端口用于接收数据报文，服务器端将全部数据按指定网络协议规则进行分解打包，形成连续数据报文。
  用户端接收到全部报文后，按照协议标准来解包组合获得完整的网络数据。其中传输过程中的每一个数据包都有特定的标签，表示其来源、携带的数据属性以及要到何处，所有的数据包经过网络路径中ISP的路由器传输接力后，最终到达目的地，也就是客户端。
  HTTP劫持是在使用者与其目的网络服务所建立的专用数据通道中，监视特定数据信息，提示当满足设定的条件时，就会在正常的数据流中插入精心设计的网络数据报文，目的是让用户端程序解释“错误”的数据，并以弹出新窗口的形式在使用者界面展示宣传性广告或者直接显示某网站的内容。在2000年初期，SP运营商对网站文件内容的劫持非常常见。

防范手段

DNS劫持现实生活中很难防范，因为提供网络服务的SP运营商让你看什么就得看什么，这也是伟大的墙所存在的条件；进不来出不去。

http劫持可以使用https增加攻击者的成本。 HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

https工作方式

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。SSL介于应用层和TCP层之间。应用层数据不再直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增加自己的SSL头，具体是如何进行加密、解密、验证的，请看下图：

1.服务器用RSA生成公钥和私钥

2.把公钥放在证书里发送给客户端，私钥自己保存

3.客户端首先向一个权威的服务器检查证书的合法性，如果证书合法，客户端产一段随机数，这个随机数就作为通信的密钥，我们称之为对称密钥，用公钥加密这段机数，然后发送到服务器

4.服务器用密钥解密获取对称密钥，然后，双方就已对称密钥进行加密解密通信了

如果有兴趣可以看下https的头和http的头有哪些区别，还有公钥和私钥，都可以了解一下。

HTTPS的优点

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

1.使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

2.HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

3.HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

4.谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”；但18年10月开始Chrome也不再提示https网站安全与否；因为大部分网站都有SSL证书了。

HTTPS的缺点

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

1.HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电； 2.HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

3.SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

4.SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

5.HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

总结

1.保密性

SQL，XSS，CSRF等攻击都是通过非法手段获取用户信息，或从后端或从前端来进行。假设你是攻击者，可以通过什么手段进行攻击就能找到防止的方法 2.完整性 请求的数据、cookie、header、body、sign等完整，后端对header和ua信息进行验证，前端在header里加密某一段信息都是方法。 3.可用性 我曾遇到过这种问题：前端（C端hybird）写了一个轮询，设定的结束条件是拿到数据，看似没什么大问题，后端微服务资源分配模块没做好，结果拖的所有的服务都当机。核心的点还是在后端，但前端也需要设定合理的结束条件。再有就是提供http服务的稳定和高并发，nginx，负载均衡，异地多活等

PS：个人经验的一点分享，肯定会有遗漏；欢迎留言指正，互相交流学习！

防止sp运营商劫持有个文章非常好，请点链接：