PostgREST 的 filter 和 or 参数危险，因其不校验字段名、操作符或JSON路径合法性，直接翻译为SQL片段，导致权限绕过、函数注入或JSON解析攻击。
PostgREST 的 filter 和 or 参数为什么危险？
因为 PostgREST 不校验字段名、操作符或嵌套表达式是否合法，它直接把 URL 参数翻译成 SQL 片段。比如 ?or=(id.gt.0,role.eq.admin) 看似只是逻辑组合，实则可能绕过业务层权限判断；?select=id,custom_func(*) 会触发未授权的数据库函数调用；?filter=profile->>'email' 则利用 JSON 操作符触发非预期解析路径。
这些都不是传统意义上的字符串拼接注入，而是把 PostgREST 当作“SQL 表达式执行器”来滥用。关键点在于：它不拒绝动态字段、不拦截非法操作符、不对 JSON 路径做语法预检。
- 所有出现在
select、order、filter中的字段名必须来自服务端白名单，禁止前端传入任意列名 - 禁用低频/高危操作符，如
cs（正则匹配）、cd（包含字典）、fuzzystr等非标准扩展 - 对
->、->>、#>等 JSON 操作符后的路径做基础语法检查，拒绝含;、$、@的输入
Django REST Framework 中 django_filters.FilterSet 怎么用才安全？
直接用 request.query_params.dict() 做 filter(**params) 是最常见也最危险的做法——它等于把用户输入原样喂给 ORM，字段名、值、甚至嵌套关系全由前端控制。
django_filters.FilterSet 本身不自动防御，它的安全性取决于你是否显式定义每个可过滤字段，并限制其行为范围。
- 每个字段必须在
FilterSet类中声明，不能靠Meta.fields = '__all__'开放全部模型字段 - 敏感字段（如
is_staff、password、deleted_at）绝不能出现在filterset_fields中 - 对字符串字段加
lookup_expr='icontains'而非'exact'时，要确认前端是否真需要模糊搜索，避免被用于盲注探测 - 禁用
BaseInFilter或自定义CharFilter(method='filter_custom')时，必须手动校验传入值是否在白名单内
Flask-RESTful 的 RequestParser 如何堵住参数注入口？
RequestParser 默认不做任何约束，add_argument('name') 就等于放行任意字符串。攻击者可以传 name=foo%27%3B%20DROP%20TABLE%20users%3B%20--，如果后端再拿这个值去拼 SQL，就完了。
真正起作用的是显式约束：类型、长度、正则、取值范围。
- 字符串字段必须设
regex，例如用户名：parser.add_argument('username', type=str, regex=r'^[a-zA-Z0-9_]{3,20}$') - ID 类整数字段要用
type=int+min/max，而不是靠 Pythonint()强转后不做校验 - 禁止使用
action='append'接收数组，除非你明确处理了每个元素的合法性；默认用store - 所有参数都应设
required=True，避免空值绕过后续校验逻辑
Go 的 database/sql 查询里，哪些写法看似安全实则危险？
用 fmt.Sprintf 拼接 WHERE 条件、把字段名或表名当参数传进 Query、甚至用 sqlx.Named 但没校验命名参数键名——这些都会让占位符机制失效。
真正安全的只有两种模式：预编译语句 + 严格绑定；或字段白名单 + 手动映射。
-
db.Query("SELECT * FROM users WHERE "+field+" = ?", value)—— 字段名field未白名单校验，就是注入点 -
db.Query("SELECT * FROM ? WHERE id = ?", table, id)—— 表名不能用占位符，必须查白名单 - 用
sqlx.In处理 IN 查询时，必须配合sqlx.Rebind重写占位符，否则IN (?)只能绑一个值 - JSONB 查询如
data->>'email'，其右侧字符串必须走json.Unquote或正则校验，防止注入email'; DROP TABLE--
实际中最容易被忽略的，是字段名和操作符的合法性校验——它们不在传统“参数值”范畴内，却直接决定 SQL 结构。只要没做白名单或语法预检，哪怕用了 PreparedStmt 或 #{} ，照样被绕过。
