别让一个请求毁了整个系统
早上刚到公司，咖啡还没泡好，运维就在群里@所有人：‘服务挂了，赶紧看看！’一查日志，原因出乎意料——某个用户提交了一个超长的 URL 参数，后端没做限制，直接把内存打满了。这种事听起来离谱，但在实际开发中并不少见。客户端请求处理看似简单，稍不注意就会埋下大雷。
验证输入是第一道防线
用户提交的数据永远不能轻信。无论是表单、URL 参数还是 JSON Body，都得当成潜在威胁来对待。比如手机号字段，前端显示只能输 11 位数字，但攻击者用抓包工具一改，发个 1000 位的字符串过来，后端如果不校验，轻则数据库报错，重则引发拒绝服务。
常见的做法是在接口入口处统一做参数校验：
if (!phoneNumber.matches("^\\d{11}$")) {
throw new IllegalArgumentException("手机号格式不正确");
}别嫌麻烦，这一步能挡住大部分低级攻击。
限制请求频率，防刷也防误操作
有个电商客户曾经遇到过问题：他们的优惠券接口被人用脚本狂刷，几分钟内发了几万次请求，导致库存瞬间清空。后来排查发现，根本没有做限流。普通用户点一下按钮没问题，但机器人可不会手抖，它能一秒发起上百次请求。
引入简单的令牌桶或滑动窗口机制就能有效控制：
// 伪代码示例：每秒最多允许 10 次请求
RateLimiter limiter = RateLimiter.create(10.0);
if (!limiter.tryAcquire()) {
response.setStatus(429);
return;
}不仅是防攻击，也能避免用户误触导致系统压力过大。
敏感操作必须二次确认
删除账户、修改密码这类操作，不能光靠前端弹个确认框就完事。用户点了‘确定’，请求直接发出去，中间没有任何服务端验证。攻击者完全可以绕过页面，直接构造 DELETE 请求调用接口。
正确的做法是：关键操作要求携带一次性 Token 或短信验证码，并在服务端核对。哪怕请求来自合法用户设备，也得再确认一次意图。
日志记录要有分寸
调试时喜欢把完整请求体打到日志里？小心泄露用户隐私。曾经有团队把包含身份证号和银行卡号的请求原样写进日志，结果日志文件被意外上传到公网，造成严重数据泄露。
记录日志时要脱敏：
String maskedBody = requestBody.replaceAll("\\d{16,}", "[REDACTED]");
logger.info("收到请求：{}", maskedBody);既保留了排查问题的能力，又避免了敏感信息外泄。
别忽视 HTTPS 和头部安全
明文传输等于把钥匙挂在门把手上。即使你的应用只做内部使用，局域网也不是绝对安全。开启 HTTPS 不只是加个小绿锁，更是防止中间人篡改请求内容。
同时注意设置安全头部：
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY这些看似无关紧要的配置，能在关键时刻阻止 XSS 或点击劫持攻击。
客户端请求处理不是写完接口就完事了。每一个 incoming request 都像一个陌生访客，得问清楚来意、查证件、限制活动范围，才能保证系统安稳运行。