能否修改出站HTTP请求的body？Stripe对接支付场景如何防范篡改风险

篡改行为的可行性 #

这种篡改请求的行为完全可以实现。你使用Postman拦截无法编辑只是工具功能限制，实际场景中：

• 用Burp Suite、Fiddler等专业抓包工具可以直接拦截HTTPS请求，任意修改请求体中的价格字段后再转发到你的中间件服务
• 攻击者甚至不需要抓包拦截，只要知道你中间件的接口参数规则，直接用curl、Postman等工具构造自定义请求，传入任意低价参数就能发起请求
  前端侧的所有限制、传输链路的普通拦截限制都无法阻止这类主动篡改行为，你的担心是完全成立的。

风险防范方案 #

核心原则：永远不要信任前端传入的金额类参数 #

所有敏感计算逻辑必须放在后端实现，这是最稳妥的防范方案，具体可以按优先级落地以下措施：

• 价格计算完全移到后端：前端仅需要传递商品ID、购买数量、用户ID、优惠券码这类标识参数，后端收到参数后，从自己的商品库查询对应商品的实时售价，结合购买数量、优惠券规则、运费规则等计算最终应付金额，完全不使用前端传递的价格参数，从根源上避免价格被篡改的可能。
• 敏感参数加签名校验：如果有特殊场景必须让前端传递金额相关参数，要对所有敏感参数做签名校验，校验规则如下：
  1. 前后端预先约定一个不对外公开的固定秘钥
  2. 前端发起请求时，把所有请求参数按字典序排序后拼接成字符串，末尾拼接上约定的秘钥，计算SHA256哈希值作为签名，放在请求头中传给后端
  3. 后端收到请求后用完全相同的规则重新计算签名，和请求头携带的签名做对比，不一致直接拒绝请求
     校验逻辑伪代码示例：

  // 后端Node.js校验示例
  const crypto = require('crypto');
  const SERVER_SECRET = '你的前后端约定秘钥';
  
  function verifySign(params, requestSign) {
    const sortedKeys = Object.keys(params).sort();
    const signStr = sortedKeys.map(key => `${key}=${params[key]}`).join('&') + `&key=${SERVER_SECRET}`;
    const calculatedSign = crypto.createHash('sha256').update(signStr).digest('hex');
    return calculatedSign === requestSign;
  }
  

• 支付流程多节点校验：在调用Stripe创建支付会话之前，必须再次核对订单的商品信息、应付金额是否合法；收到Stripe的支付成功回调后，也要再次比对Stripe返回的实际支付金额和你系统里记录的订单应付金额是否一致，不一致直接标记订单为异常，不触发后续发货等业务逻辑。
• 基础安全加固：全站强制启用HTTPS，避免传输链路中被第三方窃听篡改；接口增加用户登录态校验、请求频率限制，降低被批量攻击的风险。

内容的提问来源于stack exchange，提问作者mfergusson