已使用参数化写法的SQL查询是否存在SQL注入安全风险？

你这段代码的风险点并不在参数化查询逻辑本身，主要是以下几个易被忽略的问题： #

• 越权访问风险：你直接读取路由参数中的userId执行查询，没有校验当前登录用户是否具备查看该用户数据的权限，恶意攻击者可以遍历userId字段批量拉取全表的队友信息，数据泄露风险极高。
• 敏感字段泄露风险：你使用了SELECT *语法查询全表所有字段，如果teammates表中存在敏感字段（如密码哈希、内部联系方式、保密薪酬信息等），即使你当前没有在接口返回中输出这些字段，后续代码迭代、debug 信息泄露都可能导致敏感数据流出。建议明确声明需要查询的字段，比如：

  SELECT uid, name, team_id, position FROM teammates WHERE uid = $1
  

• 输入类型校验缺失：如果数据库中uid字段为数值类型，你直接传入从路由中拿到的字符串格式userId，部分数据库驱动的隐式类型转换逻辑可能被利用绕过查询条件，也可能触发类型异常导致服务报错。建议提前对req.params.userId做类型合法性校验，比如判断是否为纯数字、转换为数值类型后再传入查询参数。
• 额外确认项：请确认你使用的数据库操作库确实支持$1格式的参数占位符，部分库的占位符语法为?，如果占位符格式不匹配，参数化逻辑会失效，直接触发SQL注入风险。同时检查后续逻辑中是否存在拿本次查询出的字段值直接拼接SQL语句的操作，这类操作也会引入注入风险。

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