一. 浏览器系统安全方面，使用多进程方案，而js主线程运行在渲染进程中，渲染进程时运行在沙箱中的，没有对本地OS文件的直接读写权限，所以需要通过IPC与浏览器主线程通信，才可以获取cookie等信息，这样就限制了恶意JS对本地OS系统的置入病毒或者恶意程序。
二. 网络安全方面Https 实现安全加密通信，避免明文数据被窃取。
三. Web页面级别安全，是我们关注的重点。
1. 使用同源策略（协议，域名，端口都必须相同），才可以允许资源共享，彼此操作DOM, cookie, indexDB, LocalStorage, SessionStorage等
- 比如可以通过获取上一个页面的opener来执行DOM操作： opener.document.body.style.display = "none"
- IndexDB是浏览器提供给的一个非关系性数据库，支持事务，支持二进制存储，大小可达250M，它是异步读写的，与LocalStorage同步读写方式不同。
- 在安全与便利性的平衡下，引入CSP（内容安全策略），让Server来决定Browse能加载哪些资源，让Server来决定能否执行内联的JS代码等，减少XSS攻击。
- CSP是一个http响应头字段，告诉浏览器可以从哪里获取资源，是否可以执行某些JS代码等，但这个字段的兼容性不太好，IE不支持，Edge支持。
2. XSS (Cross-Site-Script),
本该缩写为css，可与层叠样式表冲突，故此缩写为XSS。
它的含义是，插入一段JS，用户浏览页面时，它会自动执行实行攻击。由于这段恶意JS拥有正常JS脚本的所有权限，比如读Cookie，监听用户输入的信息（如信用卡账号密码），修改DOM，生成浮动窗广告 等等。所以需要识别和避免。
它有3种类别的XSS
存储型XSS，输入框没有任务过滤，没有经过任何编码/转换直接存到DB中，读取内容是，直接展示出来，就会导致js自动执行。
反射性XSS，通过URL插入<script>标签，server端没有处理到，直接返给Browse
DOM中的XSS，连接一些恶意的WiFI路由器，信息被截获修改，注入恶意JS，返回修改后的内容给浏览器。
如何防止
任何UI输入域，必须转码编译，URL编码，过滤掉特殊的<script>标签等
严格的CSP策略，比如禁止第三方提交数据，禁止执行内联脚本和未授权的脚本，提供上报机制；或者限制加载其他域的资源文件。
Http only，JS不能直接读取这个Cookie，重要的数据需要设置一下，只允许http请求带上。
3. CSRF攻击
跨站请求伪造
它主要是利用用户登录信息，如Cookie信息，通过黑客网站做一些恶意攻击。简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的
case， 用户登录一个正规的银行网站，登录信息一般会保存在cookie中，此时没有退出，则cookie还在有效期内。此时用户访问一个恶意网站，这个网站可自动向银行网站发送请求，比如隐藏域post，image点击，浏览器在向银行网站发送请求时会带上它还没有过期的cookie信息，这样银行站点就区分不出这个请求时从哪里发过来的，就会认为这个请求时合法的，就可以做转账等操作。
如何防止
由于这是由于server端的漏洞+cookie未过期+user打开了黑客的site，3个条件同时满足才会触发的攻击行为，so我们从以下几个方面来防止。
a. SameSite， cookie中的SameSite可以禁止第三方站点发送请求时携带本站点的cookie
它有几个值，
Strict，完全禁止；
Lax， 宽松点，它要求从第三方站点打开且是Get请求时，可以携带这个Cookie，但Post方法，image加载，iframe加载的URL 都不能带。这个也是chrome浏览器（2020年发布的80）后版本的默认值，加强安全策略。
none，没有限制。
因此，网站开发者可以对一些关键cookie设置为strict，lax来加强防控。
b. server端验证Origin/Referer，通过判断请求方来做控制
注意，现在主要是使用Origin，优先级高，Referer，且他们的区别是，Origin不含Path部分，且不会像Referer一样存在兼容性问题，Referer还可能被用户禁用和篡改。
c. CSRF Token
Server返回一个CSRF Token放到隐藏域，或者图片验证码中，每次发请求时会带上，在server端对token（验证码）进行验证。