Web 安全基础

是什么，为什么存在

Web 安全（web security）是一组保护浏览器、HTTP 服务及其数据的设计和实现约束。它并不等同于拦截“恶意字符串”，而是要控制不可信数据和身份在系统中能够影响什么。请求参数、Cookie、请求头、上传文件、数据库记录和第三方响应，都可能成为攻击者控制的输入。

Web 应用同时跨越多个信任边界。浏览器按同源策略执行页面，服务器持有数据库与内部服务权限，反向代理和 CDN 又会改写或缓存请求与响应。一段数据从低信任区域进入高权限操作时，控制必须与当前解释方式匹配；对 HTML 文本安全的编码，不会自动让 SQL、URL 或 JavaScript 上下文安全。

最常见的失败可以按边界理解。跨站脚本（cross-site scripting，XSS）让不可信数据被浏览器当作代码或标记解释；注入让数据库或命令解释器把数据当作语法；跨站请求伪造（cross-site request forgery，CSRF）借用浏览器自动附带的凭据；失效的访问控制则让已认证主体操作不属于自己的对象。

这些风险需要组合控制，因为每项控制只回答一个问题。输入校验判断数据是否符合业务契约，认证确认调用方身份，授权决定该身份能否执行当前动作，输出编码保护特定解释上下文。安全响应头和网络策略提供额外约束，但不能替代业务边界上的决策。

你会在处理表单、渲染用户内容、拼装数据库查询、接受对象 ID、使用 Cookie 会话或调用下游服务时遇到这些边界。修复点通常靠近危险操作，而不是集中在一个全局“安全中间件”里。

最小威胁模型

开始实现功能前，先写下要保护的资产、能够影响它的主体和系统信任的假设。一个小型端点不需要庞大文档，但需要回答具体问题：攻击者能控制哪些字节，服务器拥有哪些调用方没有的权限，失败后会留下什么状态。

可以用五项清单建立最小模型：

1. 标出密码、会话、个人数据、资金操作和管理能力等资产。
2. 列出匿名用户、普通用户、管理员、后台作业和第三方服务等主体。
3. 标出浏览器、代理、应用、数据库、队列和外部服务之间的边界。
4. 为每个敏感动作写出允许条件、拒绝结果和可观察副作用。
5. 记录依赖的假设，例如可信代理列表、Cookie 范围和下游身份。

模型必须跟随实现变化。新增批量端点、缓存层、富文本编辑器或服务器出站请求，都会改变数据流和权限范围。代码审查应检查这些变化是否引入了新边界，而不只是确认旧中间件仍然存在。

安全默认值与例外

安全默认值让缺少配置时得到拒绝或最小能力，例如新路由默认需要授权，新输出默认按文本编码，新服务账户默认没有跨租户读取权限。例外需要局部、可搜索并带测试；一个全局关闭转义或允许所有来源的开关，会让远处代码承担不可见风险。

默认值也要能被部署验证。框架配置可能被 CDN 覆盖，代理可能移除请求头，数据库迁移可能扩大服务账户权限。发布检查应观察用户实际经过的路径，并把关键拒绝行为做成自动化回归测试。

边界所有权

每项控制都应有明确所有者。前端团队可以避免危险 DOM 接收器，但服务端团队仍负责授权；平台团队可以配置网络和响应头，但功能团队最清楚哪些状态转换允许当前主体执行。

共享库适合提供安全原语，不适合猜测业务策略。库可以解析来源、绑定查询参数或生成 nonce，调用方仍要传入明确的允许规则。所有权清楚后，告警和修复也能落到真正能够改变边界的代码上。

边界所有者还要维护攻击反例和部署断言。这样，框架升级或 AI 重写局部实现时，安全语义不会只存在于审查者记忆中。

工作原理

先为每条敏感数据流标出来源、转换、执行点和输出点。来源决定哪些值不可信，执行点决定需要哪类控制，输出点决定浏览器将采用哪种解析上下文。身份和数据要分别跟踪，因为格式合法的对象 ID 仍可能属于另一位用户。

流程不是所有端点都必须经过的固定中间件链。例如，公开页面不需要认证，但它仍需要安全渲染；JSON API 可能没有 HTML 输出，却仍要执行对象级授权。关键是每个危险解释器和高权限操作之前都有对应控制，而且拒绝后不产生副作用。

数据与语法分离

解释器无法猜出开发者希望某个字符串是数据还是语法。参数化查询把 SQL 模板与参数分别传给数据库驱动；模板自动转义或 textContent 把用户文本交给 HTML 文本节点。字符串拼接会重新混合两者，之后再用黑名单删除几个字符并不能恢复清晰边界。

编码必须与上下文对应。HTML 文本、HTML 属性、URL、CSS 和 JavaScript 字符串具有不同语法；一个通用 escape() 函数不可能为所有位置提供正确结果。如果确实允许富文本，应使用维护良好且按策略配置的 HTML 净化器，而不是自行编写标签黑名单。

规范化之后再校验

同一个外部值可能有多种表示，例如大小写不同的主机名、百分号编码的路径段或 Unicode 组合形式。如果安全决策基于一种表示，后续组件却解释另一种表示，就会出现校验与使用不一致。应用应先按业务协议解析和规范化一次，再对规范形式执行精确的允许规则，并把同一结果传给危险操作。

规范化也不能随意改变业务数据。密码、签名正文和不透明令牌往往要求逐字节保留，先做大小写转换或 Unicode 归一化会改变含义。需要规范化哪些字段，应由具体协议和数据模型明确规定，而不是由全局输入过滤器统一决定。

身份、动作与对象

认证只说明“调用方是谁”，不说明“可以做什么”。授权决策至少需要可信主体、动作、目标对象和必要的环境条件。服务应采用 默认拒绝（deny by default） ，并在读取或写入对象的边界上检查所有权、租户或明确策略。

不可猜测的 UUID 不是授权。合法 ID 可能从日志、链接、浏览器历史或另一个端点泄露，因此每次对象访问都要重新判断。把租户或所有权条件放进查询，可以减少先取出对象、后检查权限时遗漏分支的机会。

浏览器自动行为

浏览器会自动发送匹配域与路径的 Cookie，也会执行 同源策略（same-origin policy） 。同源策略主要限制脚本读取跨源响应；它不会保证跨源请求无法到达服务器。因此，CORS 是响应共享策略，不是服务端认证、授权或完整的 CSRF 防护。

使用 Cookie 认证的状态变更，应校验不可预测且绑定到会话的 CSRF 令牌，并检查 Origin 等请求上下文。SameSite Cookie 能降低一部分跨站请求风险，但兼容性、导航语义和同站子域意味着它适合作为附加层，而不是唯一控制。

纵深防御

浏览器侧的 内容安全策略（Content Security Policy，CSP） 可以限制脚本来源、内联执行和页面嵌入。它能缩小某些注入成功后的影响，也能通过报告帮助发现策略违规。CSP 不会修复不安全的 DOM 写入、服务端注入或缺失的授权。

服务账户与数据库账户还应遵循 最小权限（least privilege） 。如果一层控制失效，较小的权限范围可以限制可读数据、可写对象和可访问网络。日志需要记录拒绝原因与请求标识，但不能写入密码、完整令牌或敏感正文。

用反例验证控制

安全控制是否存在，不能只从配置文件判断。验证应覆盖允许路径和拒绝路径，并观察最终副作用。至少要交换主体和对象、改变方法与内容类型、缺失或重复关键字段、改变来源，以及让依赖失败。

测试证据应覆盖控制真正执行的位置：数据库查询带有租户条件，浏览器把注入样本显示为文本，跨源状态变更没有落库，最终响应经过代理后仍带预期策略。扫描器适合发现已知模式，但无法替代业务授权和状态转换的反例测试。

示例

为 HTML 文本上下文编码

第一个示例展示同一份不可信显示名称进入 HTML 文本节点时的差异。这里的辅助函数只演示 HTML 文本上下文；生产代码优先使用默认转义的模板或 DOM 的 textContent。

未经编码的字符串会形成一个 img 元素和事件处理器。编码后的字符串只在 HTML 文本节点中显示原字符，不会成为标记。不要把这个函数复用于 href、style 或内联脚本；更好的设计是避免让不可信值进入这些危险上下文。

把授权条件带入参数化查询

第二个示例先对主体与租户做授权，再构造代码和数据分离的查询。数据库驱动收到查询文本与参数数组后，应把参数作为值绑定，而不是把它们重新插回 SQL 字符串。

function buildInvoiceLookup(principal, tenantId, invoiceId) {
  const canReadTenant = principal.tenantIds.includes(tenantId);
  if (!canReadTenant) {
    throw new Error('forbidden');
  }

  return {
    text: 'SELECT id, total_cents FROM invoices WHERE tenant_id = $1 AND id = $2',
    values: [tenantId, invoiceId],
  };
}

const principal = { id: 'user-7', tenantIds: ['tenant-a'] };

for (const tenantId of ['tenant-a', 'tenant-b']) {
  try {
    const query = buildInvoiceLookup(principal, tenantId, "inv-42' OR '1'='1");
    console.log(`${tenantId}: ${query.text}`);
    console.log(JSON.stringify(query.values));
  } catch (error) {
    console.log(`${tenantId}: ${error.message}`);
  }
}

tenant-a: SELECT id, total_cents FROM invoices WHERE tenant_id = $1 AND id = $2
["tenant-a","inv-42' OR '1'='1"]
tenant-b: forbidden

恶意外观的发票 ID 留在参数数组中，不会改变查询结构。租户条件也属于查询本身，避免只按发票 ID 读取后再依赖某个调用方记得检查。真实服务还要从经过认证的服务端会话或令牌验证结果构造 principal，不能相信请求正文提供的角色或租户。

保护 Cookie 会话的状态变更

第三个示例模拟转账处理器的入口门禁。它只接受预期方法与源，并要求请求令牌匹配会话中保存的令牌；这些检查通过后，业务层仍要授权收款账户和金额。

const { timingSafeEqual } = require('node:crypto');

function tokensMatch(requestToken, sessionToken) {
  const left = Buffer.from(requestToken ?? '');
  const right = Buffer.from(sessionToken ?? '');
  return left.length === right.length && timingSafeEqual(left, right);
}

function checkTransfer(request, session) {
  if (request.method !== 'POST') return { status: 405, reason: 'method' };
  if (request.origin !== 'https://bank.example') {
    return { status: 403, reason: 'origin' };
  }
  if (!tokensMatch(request.csrfToken, session.csrfToken)) {
    return { status: 403, reason: 'csrf' };
  }
  return { status: 204, reason: 'accepted' };
}

const session = { userId: 'user-7', csrfToken: 'session-token-91' };
const requests = [
  { method: 'POST', origin: 'https://bank.example', csrfToken: 'session-token-91' },
  { method: 'POST', origin: 'https://evil.example', csrfToken: 'session-token-91' },
  { method: 'POST', origin: 'https://bank.example', csrfToken: 'wrong-token' },
];

for (const request of requests) {
  const result = checkTransfer(request, session);
  console.log(`${result.status} ${result.reason}`);
}

204 accepted
403 origin
403 csrf

比较函数先检查长度，避免 timingSafeEqual() 因长度不同而抛错。生产系统必须用密码学安全随机源生成令牌，把令牌绑定到服务端认可的会话，并在一次性操作需要时定义轮换与失效。代理必须保留或可靠重建原始来源信息，否则源检查会基于错误边界。

构造每个响应的浏览器策略

最后一个示例把浏览器策略集中为可测试的纯函数。测试使用固定 nonce 以得到稳定输出；生产请求必须从密码学安全随机源生成新 nonce，并把同一个值注入获准的脚本标签。

function buildDocumentHeaders(nonce) {
  if (!/^[A-Za-z0-9+/_=-]{20,}$/.test(nonce)) {
    throw new Error('invalid nonce');
  }

  return {
    'Content-Security-Policy': [
      "default-src 'self'",
      `script-src 'self' 'nonce-${nonce}'`,
      "object-src 'none'",
      "base-uri 'none'",
      "frame-ancestors 'none'",
    ].join('; '),
    'X-Content-Type-Options': 'nosniff',
    'Referrer-Policy': 'no-referrer',
  };
}

// 固定值仅用于可复现测试；生产环境需要为每个响应生成新值。
const headers = buildDocumentHeaders('dGVzdC1ub25jZS0xMjM0NTY3OA==');
for (const [name, value] of Object.entries(headers)) {
  console.log(`${name}: ${value}`);
}

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-dGVzdC1ub25jZS0xMjM0NTY3OA=='; object-src 'none'; base-uri 'none'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer

这里的 CSP 默认只允许同源资源，脚本还需要匹配同源或当前响应 nonce。object-src 'none'、base-uri 'none' 和 frame-ancestors 'none' 分别限制插件内容、基础 URL 改写和页面嵌入。真实策略需要按应用资源清单收紧或扩展，并在浏览器中验证，不能盲目复制示例。

陷阱

修复方法： 在入口按业务契约校验类型、长度和允许值，在危险接收器处再使用参数化、上下文编码或固定 API。不要通过删除 <script>、引号或 SQL 关键字来猜测所有攻击语法。

修复方法： 为每个动作和对象执行默认拒绝的授权，把租户或所有权约束带入数据访问，并测试其他用户、其他租户和不同 HTTP 方法。拒绝路径必须不产生写入、事件或下游调用。

修复方法： CORS 只允许明确的页面源读取响应；服务端仍要认证和授权。使用 Cookie 的状态变更还要校验 CSRF 令牌和来源，且不能把带凭据响应与通配源组合。

修复方法： 先消除不安全接收器，再把 CSP、点击劫持限制和其他响应头作为附加层。每个响应生成新的不可预测 CSP nonce，并在重定向、认证失败、404 与错误响应上检查最终经过 CDN 的头。

修复方法： 记录主体标识、动作、目标、结果、原因码和请求 ID，并对敏感字段做结构化删除或掩码。限制日志读取权限和保留期，同时验证错误响应不会暴露堆栈、查询或内部地址。

延伸阅读

• OWASP 授权备忘单
• OWASP REST 安全备忘单
• MDN 同源策略
• MDN CORS 指南