sqlmodel的filter()/where()默认防注入，但字符串拼接会绕过防护；原生sql必须用text()配命名参数，in子句传tuple；表名、字段名等结构部分需白名单校验；pydantic字段约束须显式声明。
SQLModel的filter()和where()默认防注入，但别碰字符串拼接
只要用select() + where()或filter()这类ORM方法，SQLModel底层走的全是参数化绑定，用户输入不会进SQL解析器。比如select(User).where(User.email == email_input)是安全的；而f"WHERE email = '{email_input}'"或text("SELECT * FROM users WHERE email = '" + email_input + "'")会直接绕过所有防护，哪怕只在日志里拼一句都可能埋雷。
常见错误现象：接口返回500且日志里出现sqlalchemy.exc.ProgrammingError: (psycopg2.errors.SyntaxError) syntax error at or near "admin"——这基本就是拼接导致的语法崩坏。
- 永远不用
+或f""拼SQL片段 - 连调试用的
print(f"WHERE name = {name}")都要删掉，改用logger.debug("query with name=%s", name) - 异步场景下
await session.exec(select(User).where(User.id == user_id))行为一致，无需额外处理
手写原生SQL必须用text()配命名参数，IN子句要传tuple
当你非得用text()（比如动态排序、窗口函数、跨schema查询），参数只能走命名占位符，不能靠位置或字符串插值。例如text("SELECT * FROM users WHERE status = :status AND created_at > :since")，再通过{"status": "active", "since": dt}传参。
IN子句是高频翻车点：SQLAlchemy不接受list，必须转成tuple，且占位符名要带冒号前缀。错例：text("WHERE id IN :ids")配{"ids": [1, 2, 3]}会报TypeError: IN expression only supports tuples。
- 正确写法：
text("WHERE id IN :in_list")+{"in_list": tuple(ids)} - 别用
str(ids)[1:-1]拼字符串，那是退化回SQL注入 - 如果
ids为空列表，先拦截并返回空结果，避免IN ()语法错误
表名、字段名、ORDER BY这些结构部分没法参数化，必须白名单硬校验
SQLAlchemy连text()都不允许对表名、列名、ORDER BY字段做参数化——因为它们属于SQL结构，不是数据。这部分一旦由用户控制（比如?table=logs_202608或?sort=name&order=desc），就必须提前过滤。
典型漏洞场景：多租户系统按tenant_id切表前缀，或搜索接口支持任意字段排序。没校验时，攻击者传?sort=(SELECT%20password_hash%20FROM%20users%20LIMIT%201)就能触发报错泄露信息。
- 表名校验示例：
if schema_name not in ["public", "tenant_a", "tenant_b"]: raise HTTPException(400) - 排序字段校验：
if sort_field not in ["created_at", "name", "email"]: sort_field = "created_at" - 别用
getattr(User, sort_field)反射字段，除非你确认sort_field已过白名单
Pydantic字段约束不能只靠类型声明，得写实min_length/max_length/pattern
Pydantic的str类型本身不拦长度或特殊字符，攻击者仍可传入超长payload（如10MB JSON）或嵌套结构触发下游逻辑异常。SQLModel继承Pydantic，所以字段约束得显式写死。
容易被忽略的点：邮箱字段用EmailStr能防基本格式错，但挡不住"a@b.com' OR 1=1 -- "这种注入——它本身是合法邮箱，但拼进SQL就危险。所以字段级防护只是第一道，不能替代参数化查询。
- 用户名加正则：
username: str = Field(min_length=2, max_length=50, pattern=r'^[a-zA-Z0-9_]+$') - 邮箱用
EmailStr（需装pydantic[email]），URL用HttpUrl - 密码字段必须用
SecretStr，避免日志明文打印
真正危险的操作，往往藏在你自以为“灵活”的地方：动态表名、运行时拼SQL、把用户输入直接喂给getattr或exec。参数化查询解决的是数据注入，白名单校验解决的是结构注入——两者缺一不可，且校验动作必须发生在查询执行之前，而不是事后过滤结果。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
