大家好，我是林译川，今天我们来聊聊开放接口防重放的那些事儿。很多人觉得只要加个时间戳就能解决问题，但其实不然。今天我们就来一次讲透，看看nonce、去重窗口和安全边界到底怎么用。
先来个真实案例
很多系统以为加了时间戳就万事大吉，但实际上，同一时间窗口内的重复请求依然可以重放。这就需要我们深入理解防重放的原理，才能设计出真正安全的方案。
防重放怎么做？
首先，我们要校验时间戳是否在允许的窗口内。然后，使用nonce进行一次性去重。对于敏感接口，还要结合业务幂等键一起校验。最后，窗口过期后自动清理nonce记录。
public void checkReplay(OpenApiRequest request) {
long diff = Math.abs(System.currentTimeMillis() - request.getTimestamp());
if (diff > 5 * 60_000L) {
throw new SecurityException("timestamp expired");
}
String key = "openapi:nonce:" + request.getAppKey() + \':\' + request.getNonce();
Boolean first = redisTemplate.opsForValue().setIfAbsent(key, "1", Duration.ofMinutes(5));
if (!Boolean.TRUE.equals(first)) {
throw new SecurityException("replay request");
}
}核心配置和数据模型
建议保留nonce去重表或缓存、窗口配置表、重复请求日志。不同接口可以配置不同时间窗口和去重策略。
系统设计优先级
- 时间窗口层：控制请求可接受的有效时间
- nonce去重层：对同一appKey + nonce做去重
- 幂等协同层：对敏感接口结合业务幂等键更稳
- 异常审计层：重复请求命中后要写日志
上线和治理重点
重点关注timestamp超窗率、nonce重复命中率、敏感接口重复请求量以及防重放拦截后的业务影响。
常见误区
把时间戳当成唯一安全方案是防重放最常见的误区。真正的方案需要结合nonce去重、业务幂等以及异常审计等多层防护。
想要了解更多，欢迎关注新派编程网（www.xjpbg.com），我们下期再见！