前端安全

跨域资源共享（CORS，Cross-Origin Resource Sharing）是浏览器用来放宽同源策略限制的一种机制，是前端跨域请求的主流解决方案。面试时考察点主要围绕它的原理、工作流程、配置细节及相关安全问题。 一、CORS 基础概念 作用：允许浏览器从不同源的服务器请求资源，突破同源策略限制。 原理：服务器通过设置特定的 HTTP 响应头，告诉浏览器允许跨域访问。 二、CORS 的关键响应头 头部 说明 Access-Control-Allow-Origin 指明允许访问的源，可以是具体域名（如 https://example.com）或 *（表示允许所有域访问） Access-Control-Allow-Methods 允许的请求方法（GET、POST、PUT、DELETE 等） Access-Control-Allow-Headers 允许请求携带的自定义头部字段 Access-Control-Allow-Credentials 是否允许携带 Cookie 或 HTTP 认证信息，值为 true 时允许 Access-Control-Max-Age 预检请求的结果缓存时间，单位秒 三、CORS 请求分类 1. 简单请求 满足以下条件，浏览器直接发请求： 请求方法是 GET、POST、HEAD 中之一。 请求头只包含简单头（如 Accept, Content-Type 仅限 application/x-www-form-urlencoded、multipart/form-data 或 text/plain）。 不携带自定义 Cookie、认证信息。 2. 预检请求（Preflight） 当请求不满足简单请求条件时，浏览器先发送 OPTIONS 请求询问服务器是否允许该跨域请求。 服务器响应通过特定头部告诉浏览器是否放行。 四、CORS 工作流程 浏览器发送跨域请求。 如果是简单请求，直接带上请求头发送实际请求，服务器返回响应带有 CORS 相关头，浏览器决定是否允许。 如果是非简单请求，浏览器先发 OPTIONS 预检请求。 服务器响应预检，决定是否允许后，浏览器再发实际请求。 浏览器根据响应头决定是否允许前端访问响应内容。 五、携带 Cookie 的跨域请求 默认情况下，跨域请求不发送 Cookie。 前端请求时必须设置：xhr.withCredentials = true 或 fetch 的 credentials: 'include'。 服务器必须设置：Access-Control-Allow-Credentials: true。 Access-Control-Allow-Origin 不能使用 *，必须指定具体域名。 常见考点 CORS 是什么？为什么需要它？ 同源策略和 CORS 的关系？ 简单请求和预检请求的区别？ 预检请求的触发条件有哪些？ Access-Control-Allow-Origin 设置为 * 有什么限制？ 如何支持带 Cookie 的跨域请求？ CORS 配置中的常用响应头说明。 如何解决跨域请求失败问题？ JSONP 和 CORS 的区别？ 服务器如何配置支持 CORS？

浏览器安全性是前端开发中的重要考察点之一，主要指浏览器在访问网站过程中如何防止攻击者利用漏洞或机制实施攻击、窃取数据、破坏用户体验等。 一、常见的浏览器安全威胁 1. XSS（跨站脚本攻击） 原理：攻击者注入恶意脚本到网页中，在用户浏览页面时执行。 危害：窃取 cookie、伪造操作、传播蠕虫。 防御： 对输出进行HTML转义； 使用 Content Security Policy（CSP）； 严格控制用户输入（白名单）； 使用框架自动防御（如 React 的 JSX 自动转义）。 2. CSRF（跨站请求伪造） 原理：用户登录目标网站后，被诱导访问恶意链接，触发网站上的有状态请求。 危害：修改密码、转账等敏感操作被伪造。 防御： 使用 CSRF Token； Referer 验证； SameSite Cookie 属性限制第三方请求。 3. 点击劫持（Clickjacking） 原理：攻击者在页面上嵌入透明 iframe，引诱用户点击。 防御： 禁止网页被嵌入 iframe：X-Frame-Options: DENY / SAMEORIGIN； 使用 CSP 中的 frame-ancestors 指定允许嵌入的来源。 4. 恶意文件上传 原理：上传可执行脚本，触发服务端或客户端执行。 防御： 严格限制文件类型与大小； 不在上传目录下执行脚本； 设置 CDN 或存储桶只读访问权限。 5. 恶意第三方脚本（供应链攻击） 原理：攻击者污染 CDN 或依赖源，注入恶意代码。 防御： 使用子资源完整性校验（Subresource Integrity, SRI）； 只信任可靠的依赖源； 上线前锁定依赖版本。 二、浏览器原生安全机制 1. 同源策略（Same-Origin Policy） 限制不同源之间访问 Cookie、DOM、LocalStorage 等。 同源指：协议、域名、端口号都相同。 2. CORS（跨域资源共享） 浏览器通过预检请求和响应头判断是否允许跨域访问。 3. Content Security Policy（CSP） 通过设置 HTTP Header 控制资源加载策略，防止 XSS 和数据泄露。 示例： Content-Security-Policy: default-src 'self'; script-src 'self' https://trust.cdn.com; 4. HTTP-only & Secure Cookie HttpOnly: 防止 JavaScript 读取 Cookie； Secure: 仅在 HTTPS 下传输 Cookie； SameSite: 限制第三方请求携带 Cookie。 5. Sandbox（iframe 安全沙箱） <iframe sandbox> 属性限制 iframe 的行为； 可防止脚本执行、表单提交等危险操作。 三、前端开发中的安全实践 安全措施 说明 输入校验 客户端和服务端都要做，优先使用白名单策略 输出编码 HTML、JavaScript、URL 编码避免 XSS 注入 HTTPS 加密传输防止中间人攻击（MITM） 使用现代框架 React/Vue/Angular 等框架天然防御 XSS 限制权限 用户行为应严格授权与验证 CSP 策略 强制资源加载来源、禁止内联脚本 四、总结 浏览器安全是前端必须掌握的重要基础知识，核心目标是 防止前端受到攻击者控制或操纵。它涉及浏览器机制、HTTP协议、安全头部、数据验证等多个维度，需要前端开发者在日常开发中养成良好安全意识与编码习惯。 ...

共 35 道 前端安全 面试题。答案默认折叠，便于先自行作答。 1. 如果发现JWT Token泄露，如何快速响应？ 难度：3 · 类型：QA 题目要点 定位：确认泄露的是单个用户 Token 还是全局密钥。 拉黑：立即将泄露的 Token jti 加入 Redis 禁用名单。 阻断：如果是密钥泄露，立即更新环境变量中的 JWT_SECRET。 通知：提醒受影响用户，并建议其修改密码（以防攻击者通过其他渠道获取了账号控制权）。 审计：检查该 Token 泄露期间产生的异常操作日志，进行回滚或补偿。 参考答案 由于 JWT 是无状态的（服务器默认不存储 Token，无法像 Session 那样轻易在服务端作废），快速响应的核心思路在于阻断该 Token 的有效性或强制变更鉴权环境。 以下是针对不同场景的快速响应方案： 1. 服务端拦截：引入“黑名单”机制（最快响应） 这是最直接的补救措施。虽然 JWT 旨在去中心化校验，但在紧急情况下，必须引入中心化检查。 操作：将泄露的 Token 唯一标识（通常是 jti 载荷）或整个 Token 字符串存入 Redis 等极速缓存中，并设置过期时间（等于该 Token 的剩余有效期）。 逻辑更新：修改后端的鉴权中间件，在校验 JWT 签名通过后，额外多一步检查：“该 Token 是否在 Redis 黑名单中？”。如果在，则拒绝请求。 优点：秒级生效，精准拦截。 2. 变更签名密钥（最彻底但代价大） 如果怀疑是大规模泄露，或者加密私钥（Secret Key）本身已暴露： 操作：立即在服务端更换用于签署 JWT 的 Secret Key。 后果：由于密钥变了，之前所有基于旧密钥生成的 Token（包括合法用户的）都会瞬间失效。 适用场景：密钥泄露或遭受系统性攻击。虽然这会导致全服用户强制下线（需重新登录），但在极端安全风险下是必要的“熔断”。 3. 强制用户重新登录：变更 User Secret 如果你的 JWT 签名逻辑中引入了用户特有的变量（例如：HMAC256(payload, base_secret + user_password_hash)）： ...