防范JSONB动态查询SQL注入的核心是：键名等标识符必须用sql.Identifier，值必须参数绑定；错误拼接如f"data->>'{key}'"会导致注入，→和→>后的键名属SQL字符串字面量，须由驱动按参数规则处理。
直接拼接 JSON 字段查询字符串（比如 f"data->>'{key}'"）等于主动交出数据库控制权，所有解析后的键名、路径、排序字段都必须视为不可信输入，必须走参数化或白名单校验。
JSON 键名和路径不能当字符串拼接
PostgreSQL 的 -> 和 ->> 后面的键名是 SQL 字符串字面量，不是普通值。用户传入的 "user_name' OR '1'='1" 会直接变成 data->>'user_name' OR '1'='1'，触发注入。
- ✅ 正确：用参数绑定，
data->>%(key)s，然后execute(..., {"key": "user_name"}) - ❌ 错误：用 f-string、
.format()或+拼接键名 - ⚠️ 注意：
#>>后的路径数组（如{address, city}）也是 SQL 结构，不能用f"data #>> '{{path}}'"；需白名单验证后用sql.Literal或硬编码组合
ORDER BY / GROUP BY 动态字段必须双校验
PostgreSQL 不支持 ORDER BY ? 这类结构参数，所以开发者常妥协拼接——这正是最高危环节。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 白名单必须完整匹配，例如只允许
"data->>'email' ASC"，不能只校验"email"部分 - 正则二次过滤：强制匹配
^data(->>|#>>)(?:\{[^}]+\}|'[a-zA-Z_]+')(\s+(ASC|DESC))?$，拒绝任何 Unicode 空格、控制字符、嵌套引号 - 禁止执行前再做
strip()或replace()—— 这些无法拦截零宽空格等绕过手段
IN 查询和数组操作必须用 ANY() + 参数数组
遇到 {"ids": [1, 2, 3]}，绝不能生成 id IN (1,2,3) 字符串。
- ✅ 正确：用
id = ANY(%s)，然后传入 Pythonlist或 PostgreSQLARRAY[1,2,3]类型参数 - ❌ 错误：手动拼接
"id IN (" + ",".join(map(str, ids)) + ")"，哪怕加了单引号也无效 - MyBatis 中必须用
#{}，禁用${}；JDBC 需调用setArray()或setObject()传数组
别名、表名、schema 名必须用 sql.Identifier
动态生成列别名（如 data->>'email' AS "email"）或跨 schema 查询（如 tenant_data.users）时，这些标识符不能靠字符串处理“看起来安全”。
- 用
psycopg2.sql.Identifier包裹，它会自动转义并拒绝非法字符 - 别名需提前白名单校验：只允许
^[a-zA-Z_][a-zA-Z0-9_]*$，且不以数字开头 - schema 名若来自用户输入（如租户名），必须严格限制为预定义集合，不能仅靠正则——攻击者可用
public--绕过
最易被忽略的是 JSON 嵌套深度和路径长度限制：不限制 #>> '{a,b,c,d,e,f,g,h}' 类路径，可能引发解析耗尽或内存溢出；而没校验路径中是否含 ..、$ 或控制字符，会让白名单形同虚设。
