在 React + React Router v7 SSR 项目里做多端适配，我踩的两个坑

// server.js（示例，仅演示不安全行为）
const express = require('express');
const app = express();

app.get('/search', (req, res) => {
  const q = req.query.q || '';
  // 直接把用户输入拼到 HTML 中 —— 危险！
  res.send(`<html><body>搜索: ${q}</body></html>`);
});

app.listen(3000);

访问 /search?q=<script>alert(1)</script> 会执行脚本（反射型）。

前端 DOM XSS（危险）

<div id="out"></div>
<script>
  const q = location.search.split('q=')[1] || '';
  document.getElementById('out').innerHTML = q; // 不转义 —— 危险（DOM XSS）
</script>

实战防范要点

**输出编码（服务器端）**：所有插入 HTML 的内容做 HTML 转义（&<>\"'）。
前端最小化 innerHTML：尽量用框架绑定（React/Vue 的模板）替代 innerHTML。

框架框出来的插值（{value} / {{ value }}）会自动做 HTML 转义，把 <、>、&、"、' 等关键字符替换成实体（< 等），从而把攻击脚本当文本显示，而不是执行。
富文本白名单清洗：对于必须存储/渲染的 HTML（富文本），后端用白名单 sanitizer（比如 bleach / html-sanitizer），前端再用 DOMPurify 做一次保护，对标签属性等进行清洗。
Content-Security-Policy（CSP）头部：禁止内联脚本、只允许可信源。
HttpOnly Cookie 头部：token/cookie 设置 HttpOnly，防止被脚本直接读取（减轻 XSS 后果）。

示例代码 — 安全改造

后端（Express + 转义）

const escapeHtml = s => String(s)
  .replace(/&/g, '&amp;')
  .replace(/</g, '&lt;')
  .replace(/>/g, '&gt;')
  .replace(/"/g, '&quot;')
  .replace(/'/g, '&#39;');

app.get('/search', (req, res) => {
  const q = escapeHtml(req.query.q || '');
  res.send(`<html><body>搜索: ${q}</body></html>`);
});

前端（若必须渲染 HTML，用 DOMPurify）

<!-- npm install dompurify -->
<script src="https://unpkg.com/dompurify@2.<!--version-->/dist/purify.min.js"></script>
<div id="content"></div>
<script>
  // htmlFromServer 来自后端 API，仍需 sanitize
  const htmlFromServer = '<img src=x onerror=alert(1)>';
  document.getElementById('content').innerHTML = DOMPurify.sanitize(htmlFromServer);
</script>

设置 CSP（Nginx/Express header 示例）

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none';

二、CSRF（跨站请求伪造）

原理

利用用户已登录且浏览器会自动带上凭证（cookie）的特性，攻击者诱导用户发起对受信任站点的请求（如通过自动提交表单或图片请求），从而在用户名下执行未授权操作。

最小复现示例（攻击者页面）

如果 bank.com/transfer 接受 GET 或 POST 并依赖 cookie 验证，攻击页面可这样写：

<!-- auto.html（在攻击者域名上） -->
<form action="https://bank.com/transfer" method="POST" id="f">
  <input name="to" value="attacker" />
  <input name="amount" value="1000" />
</form>
<script>document.getElementById('f').submit();</script>

用户在已登录 bank.com 的情况下访问攻击页面时，浏览器会自动带上 bank.com 的 cookie，导致转账。

防护要点

SameSite Cookie：把 session/cookie 设置 SameSite=Lax 或 Strict（Lax 对 POST 有保护，适配大多数情形）。
**CSRF Token（同步/双提交）**：服务端生成随机 token，响应给前端；敏感请求必须携带并校验该 token。

该 token 不同于 jwt token ，此处的 csrf-token 只为配合 session+cookie 传统鉴权策略做安全防护。
检查 Origin/Referer：对跨站请求校验 Origin 或 Referer 头（通常对 POST/PUT/DELETE 生效）。
避免用 cookie 做对外 API 的认证：采用 Authorization: Bearer header 的 token 机制（只有 JS 能读/写），结合 CORS 限制。
敏感操作二次确认：密码/OTP/二次验证。

示例代码（Express + scrf token + csurf）

csurf 使用 **双提交验证机制（CSRF Token）**：

服务端生成一个 CSRF Token，放在 cookie 或 session 中。

前端每次发 POST/PUT/DELETE 请求要带上这个 token，常放在请求头或表单隐藏字段，比如：X-CSRF-Token: ey2423482374823748234

服务端校验 token，是否匹配、是否未过期、是否合法。

后端（Express）

// server.js
const express = require('express');
const cookieParser = require('cookie-parser');
const csurf = require('csurf');

const app = express();
app.use(cookieParser());
app.use(express.json());
app.use(csurf({ cookie: { httpOnly: true, sameSite: 'lax' } }));

app.get('/csrf-token', (req, res) => {
  // 返回 token 给 SPA 前端（用于后续请求 header）
  res.json({ csrfToken: req.csrfToken() });
});

app.post('/transfer', (req, res) => {
  // csurf 中间件会自动校验请求中的 token（_csrf 字段或 X-CSRF-Token header）
  // 执行转账逻辑...
  res.json({ ok: true });
});

app.listen(3000);

前端 SPA（获取 token 并在请求头中发送）

// 初始化时获取 token
async function init() {
  const r = await fetch('/csrf-token', { credentials: 'include' });
  const { csrfToken } = await r.json();
  window.__CSRF_TOKEN = csrfToken;
}

// 发送受保护请求
async function transfer() {
  await fetch('/transfer', {
    method: 'POST',
    credentials: 'include', // 仍然带 cookie
    headers: {
      'Content-Type': 'application/json',
      'X-CSRF-Token': window.__CSRF_TOKEN
    },
    body: JSON.stringify({ to: 'bob', amount: 100 })
  });
}

只用 SameSite（简洁替代，适用多数场景），在服务端设置 cookie：

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax; Path=/;

这就能阻止绝大多数通过第三方页面触发的 POST/跨站敏感操作。

三、XSS 与 CSRF 的关键总结

概念：

XSS：攻击者注入脚本并可读取页面内容（更强），根源是输出/DOM 不安全。
CSRF：攻击者伪造用户请求，无法直接读取响应，根源是浏览器自动带凭证。

防护：

后端统一使用 HTML escape 库；富文本走白名单 sanitizer。
全站 Cookie：HttpOnly; Secure; SameSite=Lax。
对需要的页面开启 CSP（report-only 先观测，再 enforce）。
SPA：首次获取 CSRF token 并在后续请求中以 header 发送；服务端检查 Origin/Referer。
CI/代码审查禁止随意使用 innerHTML/eval/dangerouslySetInnerHTML。
对关键操作实施二次验证（密码/OTP）。

阅读视图

前言

chrome 之替换

一、XSS（跨站脚本）

原理

常见类型

最小复现示例（不安全的后端 + 不安全的前端）