同源策略：为什么XMLHttpRequest不能跨域请求资源？
浏览器安全可以分为三大块——Web 页面安全、浏览器网络安全和浏览器系统安全。
什么是同源策略
如果两个 URL 的协议、域名和端口都相同，我们就称这两个 URL 同源。
浏览器默认两个相同的源之间是可以相互访问资源和操作 DOM 的。两个不同的源之间若想要相互访问资源或者操作 DOM，那么会有一套基础的安全策略的制约，我们把这称为同源策略。
具体来讲，同源策略主要表现在 DOM、Web 数据和网络这三个层面。-
安全和便利性的权衡
页面中可以嵌入第三方资源
为了解决 XSS 攻击，浏览器中引入了内容安全策略，称为 CSP。CSP 的核心思想是让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能够执行内联 JavaScript 代码。跨域资源共享
引入了跨域资源共享（CORS），使用该机制可以进行跨域访问控制，从而使跨域数据传输得以安全进行。跨文档消息机制
引入了跨文档消息机制，可以通过 window.postMessage 的 JavaScript 接口来和不同源的 DOM 进行通信。
跨站脚本攻击（XSS）：为什么Cookie中有HttpOnly属性？
什么是 XSS 攻击
XSS 全称是 Cross Site Scripting，跨站脚本，为了与“CSS”区分开来，故简称 XSS。XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。XSS 的危害
窃取 Cookie 信息、监听用户行为、修改 DOM、在页面内生成浮窗广告-
恶意脚本是怎么注入的
- 储存型 XSS（持久型 XSS）
黑客利用站点漏洞将一段恶意 JavaScript 代码提交到网站的数据库中；用户向网站请求包含了恶意 JavaScript 脚本的页面；当用户浏览该页面的时候，恶意脚本就会将用户的 Cookie 信息等数据上传到服务器。 - 反射型XSS（非持久型 XSS）
在一个反射型 XSS 攻击过程中，恶意 JavaScript 脚本属于用户发送给网站请求中的一部分，随后网站又把恶意 JavaScript 脚本返回给用户。当恶意 JavaScript 脚本在用户页面中被执行时，黑客就可以利用该脚本做一些恶意操作。
Web 服务器不会存储反射型 XSS 攻击的恶意脚本，这是和存储型 XSS 攻击不同的地方。 - DOM 型 XSS
基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。具体来讲，黑客通过各种手段将恶意脚本注入用户的页面中，比如通过网络劫持在页面传输过程中修改 HTML 页面的内容，这种劫持类型很多，有通过 WiFi 路由器劫持的，有通过本地恶意软件来劫持的，它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。
- 储存型 XSS（持久型 XSS）
-
如何阻止 XSS 攻击
存储型 XSS 攻击和反射型 XSS 攻击是服务端的安全漏洞。而基于 DOM 的 XSS 攻击属于前端的安全漏洞。- 服务器对输入脚本进行过滤或转码
- 充分利用 CSP
- 限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
- 禁止向第三方域提交数据，这样用户数据也不会外泄；
- 禁止执行内联脚本和未授权的脚本；
- 提供了上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。
- 使用 HttpOnly 属性
由于 JavaScript 无法读取设置了 HttpOnly 的 Cookie 数据，所以即使页面被注入了恶意 JavaScript 脚本，也是无法获取到设置了 HttpOnly 的数据。因此一些比较重要的数据我们建议设置 HttpOnly 标志。
CSRF攻击：陌生链接不要随便点
- 什么是 CSRF 攻击
CSRF 英文全称是 Cross-site request forgery，所以又称为“跨站请求伪造”，是指黑客引诱用户打开黑客的网站，在黑客的网站中，利用用户的登录状态发起的跨站请求。简单来讲，CSRF 攻击就是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事。
-
实施 CSRF 攻击
- 自动发起 Get 请求
- 自动发起 POST 请求
- 引诱用户点击链接
和 XSS 不同的是，CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。
-
如何防止 CSRF 攻击
- 充分利用好 Cookie 的 SameSite 属性（通常有 Strict、Lax 和 None 三个值）
- 验证请求的来源站点
Referer 是 HTTP 请求头中的一个字段，记录了该 HTTP 请求的来源地址。
Origin 属性只包含了域名信息，并没有包含具体的 URL 路径。
服务器的策略是优先判断 Origin，如果请求头中没有包含 Origin 属性，再根据实际情况判断是否使用 Referer 值。 - CSRF Token
HTTPS：让数据传输更安全
由于 HTTP 的明文传输特性，在传输过程中的每一个环节，数据都有可能被窃取或者篡改，这倒逼着我们需要引入加密机制。于是我们在 HTTP 协议栈的 TCP 和 HTTP 层之间插入了一个安全层，负责数据的加密和解密操作。
我们使用对称加密实现了安全层，但是由于对称加密的密钥需要明文传输，所以我们又将对称加密改造成了非对称加密。但是非对称加密效率低且不能加密服务器到浏览器端的数据，于是我们又继续改造安全层，采用对称加密的方式加密传输数据和非对称加密的方式来传输
密钥，这样我们就解决传输效率和两端数据安全传输的问题。
采用这种方式虽然能保证数据的安全传输，但是依然没办法证明服务器是可靠的，于是又引入了数字证书，数字证书是由 CA 签名过的，所以浏览器能够验证该证书的可靠性。
