搜索框必须禁用字符串拼接，改用参数化查询；LIKE通配符需显式转义；优先白名单校验与后缀匹配；错误响应须收敛，前端校验不可信。
搜索框必须禁用字符串拼接，改用参数化查询
直接把 $_GET['q'] 或 request.GET.get('q') 拼进 SQL 字符串里（比如 "WHERE title LIKE '%" + q + "%'"），是绝大多数搜索型 SQL 注入的根源。过滤单引号、加 addslashes()、甚至转义 % 都拦不住绕过——因为攻击者根本不需要闭合引号，就能用 OR 1=1 改变逻辑。
实操建议：
- PHP（PDO）：必须用
prepare()+bindValue()，$q只能作为参数传入，绝不能出现在 SQL 字符串中 - Python（Django）：优先走 ORM 查询如
filter(title__icontains=q)；若必须写原生 SQL，用cursor.execute("... LIKE %s", ['%' + q + '%']) - Java（JDBC）：禁用
Statement，改用PreparedStatement，调用setString(1, "%" + q + "%")是安全的；而executeQuery(" LIKE '%" + q + "%'")是危险的
LIKE 查询里的 % 和 _ 必须显式转义，不能只靠参数化
参数化能防逻辑篡改，但拦不住通配符语义本身。用户搜 admin%，可能意外匹配到 administrator 或其他敏感前缀字段，这在审计或合规场景下就是数据越界暴露。
实操建议：
- MySQL：在
LIKE子句后加ESCAPE ''，再对q中的%、_、分别替换为%、_、\ - PostgreSQL：用
ESCAPE E'''，且确保客户端连接编码为 UTF-8，否则双字节字符可能绕过转义 - 如果业务允许，直接放弃前缀模糊（
"%" + q + "%"），改用后缀匹配（q + "%"）或全文索引（MATCH ... AGAINST），大幅减少通配符暴露面
白名单校验比黑名单过滤更可靠，尤其对中文搜索
用正则删掉“非中文、非英文、非数字”的字符（如 /[x{4e00}-x{9fa5}a-zA-Z0-9]/u），比拦截 or、union、select 等关键词靠谱得多。后者容易被大小写、编码、注释符（/**/）、空格绕过。
实操建议：
- 先做白名单清洗，再做长度限制（如最多 50 字符），避免超长输入触发数据库异常或 DoS
- 中文搜索慎用
addslashes()+htmlspecialchars()套娃组合——addslashes()在 MySQL 旧版本中对多字节编码有缺陷，已弃用多年 - 若需保留标点（如破折号、括号用于高级搜索），应明确列出允许字符集，而非排除“危险词”
错误响应必须收敛，禁止返回原始数据库报错
搜索框报错时显示 MySQL error: You have an error in your SQL syntax...，等于告诉攻击者当前用的是什么数据库、字段名、甚至表结构。这是盲注和联合注入的起点。
实操建议：
- 所有数据库异常必须捕获，统一返回泛化提示如“搜索失败，请稍后重试”
- 开发环境可记录详细日志，但生产环境日志中不得包含 SQL 片段、参数值、堆栈路径
- 不要依赖前端 JS 校验——它可被绕过；服务端才是唯一可信防线
真正难处理的是那些历史项目里混用多种查询方式的搜索入口：有的走 ORM，有的手写 PDO，有的还残留着 mysql_query()。这类地方最容易漏掉转义或参数化，得逐个函数追踪 q 的流向，而不是统一加个过滤函数就以为万事大吉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
