最小权限是SQL注入成功后唯一能拦住数据泄露的防线；只授SELECT不够，因GRANT SELECT ON .会暴露information_schema、字段未限制致UNION拖库、strict模式关闭可绕过校验，须用列授权、视图封装、角色管理并补sql_mode、public schema、密码硬编码三处漏洞。
只要数据库账号不配成 root 或 sa，绝大多数 SQL 注入连表名都查不到，更别说拖库——最小权限不是“锦上添花”，而是注入成功后唯一能拦住数据泄露的防线。
为什么只给 SELECT 权限还不够？
很多团队以为“只授 SELECT”就安全了，但实际仍可能被扫库、拖敏感字段。关键在于权限粒度没控住：
-
GRANT SELECT ON *.*这类写法会让攻击者直接查information_schema.tables，批量获取所有库表名 - 没限制字段时，哪怕只查
users表，攻击者也能用UNION SELECT password_hash, email FROM users把整列拖出来 - MySQL 关闭
STRICT_TRANS_TABLES后，SELECT 1,2,3 FROM dual可绕过UNION字段数校验，强行拼接系统表
怎么真正落到“库-表-字段”三级控制？
不能靠人肉记，得用数据库原生机制把权限卡死：
- 列级授权（MySQL）：
GRANT SELECT(id, name, price) ON myshop.products TO 'web_app'@'%' - 视图封装敏感字段（通用）：
CREATE VIEW login_view AS SELECT username, password_hash FROM users，再GRANT SELECT ON login_view TO 'auth_user'@'%' - 角色管理跨表需求（PostgreSQL / MySQL 8.0+）：
CREATE ROLE export_role→GRANT SELECT ON sales, customers TO export_role→GRANT export_role TO 'report_user'@'%'
三个常被跳过的“隐形权限漏洞”
配完权限一测能用就上线？这三处不补，前面全白干：
- MySQL 的
sql_mode必须含STRICT_TRANS_TABLES：SELECT @@sql_mode查结果，不含就改配置或启动参数 - PostgreSQL 的
publicschema 默认可读：REVOKE USAGE ON SCHEMA public FROM PUBLIC必须执行，否则SELECT table_name FROM information_schema.tables照样跑通 - 密码明文写在
config.php或application.yml里？服务器一旦失陷，攻击者cat一下就拿到连接凭证——必须走密钥服务（如 HashiCorp Vault）或运行时挂载（如 Kubernetes Secret）
最小权限不是上线前点一次“保存”的配置项，而是每次加新接口时，必须盯着日志看它到底查了哪张表、哪些字段、有没有意外触发跨表 JOIN —— 权限随功能变，不是设完就进回收站。
