去年秋天，接口我帮一个做电商的授权朋友看服务器日志。凌晨三点，访问有人用脚本批量请求他们后台的漏洞/api/v1/order/export接口，没带任何token，补丁直接导走了两万多条订单记录。接口朋友说那个接口是授权临时加的，开发图省事，访问觉得“反正前端会传token，漏洞后端不校验也没事”。补丁问题就出在这——前端传不传是接口前端的事，后端不校验，授权等于门没锁。访问

未授权访问漏洞的漏洞补丁，核心就一件事：在服务端把“谁可以访问”这件事重新管起来。补丁听起来简单，但补丁打在哪、怎么打，决定了你是真修好了还是只贴了张创可贴。

补丁不是加个if就完事

最粗暴的修法是在接口入口加一行判断：if (!token) return 401;。这能挡住裸奔的脚本，但挡不住拿着低权限token去访问高权限接口的人。我见过一个系统，普通用户token能调管理员的/admin/user/delete，因为补丁只校验了“有没有token”，没校验“token对应什么角色”。

正确的做法是把鉴权逻辑从散落的接口里抽出来，做成统一的中间件或拦截器。Spring Security、Django的permission类、Express的middleware，都是干这个的。关键点在于：每个接口必须显式声明自己需要什么权限，默认拒绝，而不是默认放行。很多框架的默认行为是“没配规则就放行”，这个默认值本身就是漏洞温床。

补丁要覆盖的三种典型场景

第一种是内部接口忘了加鉴权。开发时想着“这是给内部服务调的”，上线后网络策略没配好，外部也能访问。补丁方式是在网关层做IP白名单或mTLS，别只依赖应用层判断。

第二种是参数越权。接口有鉴权，但只校验了“登录了”，没校验“这条数据是不是你的”。比如/api/user/12345/profile，登录用户把12345改成别人的ID，照样能看。补丁要在数据查询层加where user_id = current_user.id，而不是在应用层判断完就完事。

第三种是HTTP方法绕过。接口只对POST做了鉴权，GET没做，攻击者换个方法就进去了。补丁要按路由+方法粒度配置，别按路径前缀一刀切。

打完补丁之后必须做的事

补丁上线不等于漏洞关闭。我习惯在修完后做三件事：用没token的请求打一遍所有接口，看返回是不是401/403；用低权限token打高权限接口，看是不是403；翻一遍访问日志，看补丁上线前有没有已经被利用的痕迹。第三件事最容易被跳过，但最要命——你修了门锁，不代表之前没人进来过。

还有个细节：补丁的返回信息别太详细。{ "error": "token expired"}和{ "error": "invalid signature"}这种区分，等于告诉攻击者他猜到了什么。统一返回401加一句“unauthorized”就够了。

最后说个观察。很多未授权访问漏洞的根源不是技术问题，是流程问题。接口上线没有安全评审，测试环境没开鉴权，生产环境直接复制配置。补丁能修代码，修不了习惯。我那个电商朋友后来加了鉴权中间件，但真正让他睡好觉的，是上线前多了一道“所有新接口必须过鉴权测试”的卡点。代码补丁是止血，流程补丁才是防复发。