elasticsearch 的 _sql 接口不支持 preparedstatement，因其底层为文本解析器，无预编译与参数绑定机制，? 占位符不被识别，用户输入必须严格校验字段名、值及函数名以防止注入。
ES 的 SQL 接口不是真正的 SQL 引擎，它不支持参数化查询，所有字段名、值、函数名都靠字符串解析——这意味着你用 _sql endpoint 做查询时，WHERE 条件里的用户输入必须手动校验，否则就是注入入口。
为什么 Elasticsearch 的 _sql REST 接口无法用 PreparedStatement 防护？
Elasticsearch 的 _sql 接口（如 POST /_sql）底层是文本解析器，不是 JDBC 驱动。它接收 JSON 或 SQL 字符串，然后自己 tokenize、parse、生成执行计划。没有预编译阶段，也没有绑定参数机制。传入的 query 字段哪怕写成 "SELECT * FROM logs WHERE message = ?"，? 也不会被识别为占位符，而是字面量报错或直接忽略。
- 错误认知：以为加了
?就安全 —— 实际上 ES 不认这个语法 - 真实行为：整个 SQL 字符串被当作模板展开，字段名、值、函数名全走正则/AST 解析
- 后果：攻击者可构造
SELECT * FROM logs WHERE message = 'a' OR 1=1 --直接绕过逻辑
在 ES + MySQL 混合架构中，如何切断“ES 查询结果 → SQL 字符串拼接”链路？
典型高危路径是：前端搜关键词 → 后端用该词查 ES 获取文档 ID 列表 → 再拿这些 ID 去 MySQL 执行 SELECT * FROM orders WHERE id IN (1,2,3...)。如果没校验 ES 返回的 id 字段类型和格式，就可能把恶意字符串塞进 SQL。
- ES 返回的
_id或自定义字段可能是字符串、数字、甚至嵌套对象 —— 必须显式校验typeof id === 'string' && /^[0-9a-f]{24}$/.test(id)（MongoDB ObjectId）或/^\d+$/.test(id)（MySQL 自增） - 禁止对 ES 返回结果做
JSON.stringify()后直接插进 SQL —— 对象会变成"{"_id":"abc"}"，拼进去就是语法错误或意外行为 - IN 子句必须用参数化：Node.js 中用
pg的$1, $2, $3占位；Java 用PreparedStatement动态生成问号序列；不要拼IN ('"+ids.join("','")+"')
当必须用 ES 的 _sql 接口时，哪些字段允许动态插入？哪些必须硬编码？
_sql 请求体里只有 query 字段是用户可控的 SQL 字符串，其余如 fetch_size、time_zone 是配置项，但字段名、表名、函数名一旦来自用户输入，就等于开放语法控制权。
- 绝对禁止动态字段名：不能让用户决定查
message还是user_id，必须白名单校验，例如allowedFields = ['message', 'timestamp', 'status'] - 表名必须固定：ES 中的索引名不能由用户输入拼接，
FROM logs_v2可以，FROM ${userIndex}不行 - 函数名限制：禁用
SCRIPT、CAST、EXTRACT等高风险函数；模糊匹配只允许LIKE，且值必须走params字段（ES 支持params替换，但仅限值，不包括字段或操作符） - 示例安全写法：
{"query": "SELECT * FROM logs WHERE message LIKE ? AND status = ?", "params": ["error%", "active"]}—— 注意：ES 的params仅对值生效，且只支持简单类型
最常被忽略的一点是：ES 的 _sql 接口默认开启，但生产环境应通过 xpack.security.enabled: true 和角色权限限制访问；即使做了所有输入校验，未授权的用户若能直连 ES，仍可能绕过应用层逻辑发起原始请求。
