如何安全比对路由对应用户与当前登录会话用户身份？

你的判断完全正确：仅直接比对资料侧、会话侧的用户名/明文传参的用户ID，存在非常明确的越权风险——用户名属于可修改字段，客户端传参完全可被篡改，这类校验逻辑很容易被绕过。生产环境可以按照以下规则落地校验：

核心校验原则 #

所有身份、权限校验的唯一可信源是服务端存储的已认证会话上下文，绝对不能信任客户端传递的路由参数、请求体字段、前端存储内容作为身份判定依据。

具体实现逻辑 #

场景1：必须保留/username这类带用户标识的语义化路由 #

如果因为SEO、产品路由设计要求，必须保留路径中带用户名的路由形式，严格按照3步走：

• 第一步：请求进入服务端后，优先从已认证会话上下文中取出当前登录用户的不可变唯一主键ID（即数据库中用户表的主键user_id，这类ID一旦生成终身不会变更、不会重复分配），不要取用户名、手机号、邮箱这类可修改字段作为身份凭证。
• 第二步：根据路由路径中的username参数查询数据库，拿到对应用户资料记录的归属owner_user_id，将这个值和会话中取出的当前登录user_id做严格类型等值比对，禁止比对用户名：用户名支持修改的场景下，用户修改用户名后旧用户名可能被其他用户抢注，直接比对用户名会直接导致越权。
• 第三步：比对通过才返回可编辑状态、允许执行资料修改操作；比对不通过直接返回403 Forbidden状态码，不要返回404或带具体用户存在性提示的内容，避免被遍历枚举全站用户资料。

场景2：可调整路由设计（更推荐，从根源规避越权） #

直接废弃编辑类接口路径中携带用户标识的设计：

• 所有查询、修改当前登录用户自身资料的接口，统一使用固定路由比如/profile/me、/api/user/profile/edit，接口逻辑内直接从会话上下文取user_id查询对应用户资料、执行更新操作，完全不接受客户端传递任何用户ID、用户名类的归属参数，从接口设计层面堵死参数篡改的可能。
• 只有访问其他用户公开资料的场景，才使用/username这类带参数的路由，这类接口默认只返回公开可读字段，不开放任何编辑权限。

常见错误避坑 #

• 不要把用户ID、权限标识存在前端localStorage、sessionStorage或明文Cookie中，直接读取前端存储的字段做前端校验，这类校验可以被任意篡改，完全没有安全性。
• 不要在查询资料接口做一次校验就放行后续修改操作：所有POST/PUT类的资料更新请求，必须在执行更新逻辑前独立再做一次同主体校验，避免查询和更新逻辑脱节、被篡改更新参数绕过校验。
• 如果使用JWT作为会话凭证，不要直接信任JWT payload中存储的用户名、角色这类可变字段：要么将不可变的user_id作为JWT的核心身份字段，要么每次校验时用JWT对应的会话标识查库确认用户状态，同时做好JWT的过期、吊销逻辑，避免被盗用后长期有效。

额外加固措施 #

• 修改密码、换绑手机号、注销账号这类高敏感操作，除了校验同主体归属，还要增加二次验证（比如当前登录密码验证、绑定手机号短信验证）。
• 所有用户资料类接口增加请求频率限制，避免被恶意遍历参数探测越权漏洞。
• 上线前做专项越权测试：覆盖未登录用户、普通登录用户、管理员等不同角色，验证跨用户访问他人资料编辑接口时会被直接拦截。

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