php数据库安全最常踩的坑是习惯性忽略基础防护：未用参数化查询导致sql注入；数据库账号权限过大；配置文件明文暴露；日志记录敏感信息；错误页面泄露详情。
PHP 数据库安全设计最常踩的坑，不是技术做不到，而是习惯性忽略或误信“差不多就行”。真正导致 SQL 注入、敏感信息泄露、权限失控的，往往是开发初期几个看似微小的决策。
把用户输入直接拼进 SQL 语句
这是 SQL 注入的根源。哪怕加了 trim()、htmlspecialchars() 或前端做了校验，只要没用参数化查询，后端拼接字符串就等于敞开大门。
正确做法只有一条：所有变量一律走预处理（PDO::prepare / mysqli::prepare），绑定参数（bindParam / bind_param），绝不拼接。
- 错误示例：
$sql = "SELECT * FROM user WHERE id = " . $_GET['id']; - 正确示例：
$stmt = $pdo->prepare("SELECT * FROM user WHERE id = ?"); $stmt->execute([$_GET['id']]); - 注意：即使类型是整数，也别用 (int) 强转后拼接——绕过强转的攻击手段早有成熟利用链
数据库账号权限过大，一套账号打天下
开发环境用 root，生产环境还用 root；一个账号同时拥有 SELECT、INSERT、UPDATE、DELETE、DROP、CREATE 权限；甚至给 Web 应用赋予 FILE、PROCESS 等高危权限。
立即学习“PHP免费学习笔记（深入）”；
最小权限原则必须落地到具体账号：
- Web 应用连接账号只授予它真正需要的表和操作（如仅对 orders 表有 INSERT+SELECT）
- 禁用 SHOW DATABASES、LOAD_FILE、SELECT INTO OUTFILE 等非业务必需功能
- 分离读写账号：列表页用只读账号，提交页用受限写入账号
把数据库配置明文写在 Web 可访问目录下
常见错误包括：config.php 放在 public/ 下、.env 文件未屏蔽、Git 提交了含密码的配置文件、phpinfo() 页面暴露 DB 连接串。
关键防护动作要闭环：
- 数据库配置文件必须放在 Web 根目录之外（如与 public 同级的 config/ 目录）
- Web 服务器（Nginx/Apache）明确禁止访问 .env、*config*、*secret* 类文件
- Git 忽略敏感文件（.env、config/database.php 等），CI/CD 阶段通过环境变量注入配置
日志里记录完整 SQL 和敏感字段值
调试时开启 PDO::ATTR_EMULATE_PREPARES = true，再配合全量 SQL 日志，等于把用户手机号、身份证、密码哈希原样记进日志文件。
日志策略需主动收敛：
- 关闭 SQL 原始语句输出（尤其生产环境），改用结构化日志记录操作意图（如 “用户登录失败，ID: 12345”）
- 若必须记录 SQL，应脱敏处理：替换掉 WHERE 后的值、隐藏手机号中间四位、截断长文本
- 禁止在错误页面显示数据库报错详情（如 MySQL 错误号 1064），启用自定义错误页 + 错误 ID 查日志
不复杂但容易忽略。安全不是加一层过滤器，而是从连接方式、账号体系、文件布局、日志边界开始重新定义数据流动的规则。
