核心概念
这么多年的开发中，没有关注过前端安全的问题，只是又简单的一点点的认知，直到面了一家很注重安全的公司，面试结束很讽刺的对我说了句，大环境不好，还是不要换工作了。 你要说能用到多少，看公司项目了，但是下面这些起码还是记着比较好
| 攻击方式 | 简要说明 | 主要防御手段 |
|---|---|---|
| 跨站脚本攻击（XSS） | 攻击者向网页注入恶意脚本，在用户浏览器中执行以窃取信息或进行恶意操作。 | 输入过滤与转义、内容安全策略（CSP）、避免使用危险的API（如 innerHTML）、HttpOnly Cookie。 |
| 跨站请求伪造（CSRF） | 攻击者诱导用户在已登录目标网站的情况下，访问恶意网站并发起非预期的操作请求（如转账）。 | CSRF Token、SameSite Cookie、校验请求来源（Referer/Origin）。 |
| 点击劫持（Clickjacking） | 攻击者通过透明iframe覆盖恶意按钮在合法页面上，诱导用户点击。 | 设置 X-Frame-Options 响应头、使用 CSP 的 frame-ancestors 指令。 |
| 第三方依赖风险 | 引入的第三方库或组件可能存在已知漏洞，被利用来攻击用户。 | 定期使用 npm audit或 yarn audit检查漏洞、最小化依赖、锁定版本。 |
| 本地存储泄露 | 敏感数据（如Token）存储在localStorage中，可能被XSS窃取。 | 优先使用HttpOnly Cookie存储敏感信息、如需本地存储则进行加密。 |
| 开放重定向（Open Redirect） | 网站接受用户控制的输入作为重定向目标，诱导用户跳转到钓鱼网站。 | 对重定向目标URL进行白名单校验、避免直接使用用户输入构造跳转链接。 |
| JSONP劫持 | 通过未授权的JSONP接口窃取用户的敏感数据。 | 减少JSONP接口的使用（推荐使用CORS机制）、在服务器端对数据请求进行认证。 |
关键原理
XSS跨站脚本攻击
XSS攻击的本质是注入，攻击者将恶意脚本注入到网页，并在浏览器中执行。XSS攻击可以分成下面几类：
- 存储型XSS： 存储在服务器上的恶意脚本，如何实现呢，想想论坛的评论区
- 反射型XSS：作为URL参数的一部分的恶意脚本，发送到服务器后立即反射回浏览器执行，常见的是钓鱼链接
- DOM型XSS：修改页面的DOM来执行恶意脚本 可以看到这种攻击方式就是不加判断的执行一些东西，不管是服务器获取的内容还是DOM树上获取的，从这种攻击方式来思考如何防御
- 输入过滤和输出转义：对用户的输入进行严格的验证和过滤，并对输出到页面的内容进行转义
- 内容安全策略CSP ：通过http响应头
Content-Security-Policy限制页面中脚本，样式等资源的加载来源，从根本上防止非法脚本的执行 - 谨慎操作DOM ：慎用
innerHTML,eval(),document.write()这种就不要用了，也不好用 - 设置Cookie为httpOnly：防止JavaScript读取隐私信息
跨站请求伪造CSRF
CSRF利用的是每次请求都会默认携带Cookie，当我们登录了一个正常的网站，并在不知情的情况下有访问了危险的网站，利用携带Cookie的机制，危险的网站获得我们的用户的信息，并伪装成我们正常的用户，对正常的网站进行攻击 知道了攻击方法，应对方式也就应运而生了
- CSRF Token：我们和正常网站的每一次请求都携带一个约定好的Token，嵌入表单或者请求头，服务器每次请求验证此Token，不合法的拒绝
- SameSite Cookie ：设置Cookie的SameSite属性
- Strict：完全禁止第三方的Cookie
- Lax：允许在安全跨站请求中携带Cookie，平衡安全和用户体验的默认推荐方式
- 校验请求来源：检查HTTP请求头中的Origin或Referer字段，判断请求来源合法
点击劫持
使用一个透明的IFrame诱骗用户在不知情的情况下触发目标网站的操作 了解他，防御他
- 设置X-Frame-Options响应头
- DENY:页面不能被任何iframe嵌入
- SAMEORIGIN：页面只能被同源网站嵌入
- 使用CSP的frame-ancestors指令：更精细的控制允许哪些页面嵌套当前页面，可配置多个，更灵活，兼容性更好
图表
