签名验证必须在request.get_data()之前做，因为request.data和request.json会消耗原始请求体，导致后续无法获取完整字节流计算签名；应统一用request.get_data(cache=True)先取原始body再解析业务数据。
签名验证为什么必须在 request.get_data() 之前做
Flask 的 request.data 和 request.json 都会触发底层的 body 读取，而 WSGI/ASGI 环境下 request body 只能被读取一次。如果先调用 request.json 或 request.form，再想拿原始字节算签名，request.get_data() 会返回空 bytes。验证签名的第一步，永远是「先取原始 body，再解析业务数据」。
实操建议：
- 统一用
request.get_data(cache=True)拿原始字节（cache=True 确保后续request.json等仍可用） - 不要在装饰器或中间件里依赖
request.json做签名校验——它已经把 body 解码并丢弃了原始内容 - 若接口同时支持 JSON 和 form-data，需按
request.headers.get('Content-Type')分支处理，但签名始终基于未解析的 raw body
如何用 HMAC-SHA256 正确比对签名值
常见错误是直接用 == 比较签名字符串，这会引发时序攻击。Python 标准库提供了安全的恒定时间比较函数 hmac.compare_digest()，必须用它。
实操要点：
立即学习“Python免费学习笔记（深入）”；
- 签名原文 =
method + path + timestamp + nonce + body_bytes（顺序、分隔符、编码必须和客户端严格一致） - 密钥必须从环境变量或配置中心加载，禁止硬编码在代码里
- 务必用
hmac.compare_digest(received_sig, expected_sig)，而不是== - timestamp 要做窗口校验（如 ±300 秒），防止重放；nonce 需服务端缓存去重（Redis 是常用选择）
Flask 路由中嵌入签名验证的最小可行写法
不依赖第三方扩展，纯 Flask 实现签名校验，关键是在视图函数开头就拦截并验证，失败立即返回 401。
示例逻辑（精简版）：
from flask import request, jsonify
import hmac
import hashlib
import time
import os
<p>def verify_signature():
body = request.get_data(cache=True)
sig = request.headers.get('X-Signature')
ts = request.headers.get('X-Timestamp')
nonce = request.headers.get('X-Nonce')</p><pre class="brush:php;toolbar:false;">if not all([sig, ts, nonce]):
return False
# 时间窗口检查
if abs(int(ts) - int(time.time())) > 300:
return False
# 构造签名原文：注意编码和拼接规则要和客户端完全一致
msg = f"{request.method}{request.path}{ts}{nonce}".encode() + body
key = os.environ['API_SECRET'].encode()
expected = hmac.new(key, msg, hashlib.sha256).hexdigest()
return hmac.compare_digest(sig, expected)@app.route('/api/order', methods=['POST']) def create_order(): if not verify_signature(): return jsonify({'error': 'Invalid signature'}), 401
try:
data = request.get_json()
# 后续业务逻辑...
return jsonify({'ok': True})
except Exception as e:
return jsonify({'error': str(e)}), 400
签名验证容易被绕过的三个盲点
很多团队实现了签名逻辑，却在真实攻防中被绕过，问题往往出在边界细节上。
重点关注：
-
request.path和request.full_path不同：前者不含 query string，后者含。若签名原文用了full_path，但客户端故意在 URL 末尾加?a=1（服务端没校验 query），签名就失效——应明确约定是否包含 query，并统一处理 - 客户端发
Content-Type: application/json; charset=utf-8，服务端用request.get_json()会自动 strip BOM 或 normalize whitespace，导致 body 字节和签名时的不一致。解决方案：签名永远基于request.get_data()返回的原始 bytes，不经过任何 decode/parse - 反向代理（如 Nginx）可能修改 header 大小写或自动添加
Transfer-Encoding: chunked，导致X-Signature丢失或错位。务必在 proxy_pass 配置中显式透传自定义 header：proxy_set_header X-Signature $http_x_signature;
签名这件事，最难的不是算法本身，而是两端对“原始数据”的定义能否咬死——body 是否含换行、timestamp 是秒还是毫秒、path 是否 decode、header key 是否大小写敏感……任何一个点没对齐，验证就形同虚设。
