最小权限原则不能阻止SQL注入发生，但能限制攻击者利用注入账号所能获取的数据范围和操作能力；它通过列级授权、视图封装、禁用高危权限及修复配置漏洞（如关闭严格模式、public schema可读、密码明文存储）来降低危害。
最小权限原则不能阻止SQL注入发生，但能决定攻击者拿到账号后能干成什么事——权限越小，爆出来的数据越少，甚至查不到表名。
SQL注入本质是“借号执行”，不是提权
注入代码最终是以数据库账号身份运行的。如果这个账号只有SELECT (id, username)权限，那UNION SELECT @@version, user(), database()就会报错或返回空；INSERT INTO users、DROP TABLE logs直接被拒绝。
常见错误现象：
- 误以为“防住了拼接就安全了”，结果上线用
root账号连库，一注入就全盘沦陷 - 只配了
GRANT SELECT ON myapp.users TO 'web'，没写字段列表，等于把密码哈希、手机号全敞开
列级授权比表级关键得多
很多团队卡在表级授权就停了，但敏感字段（如password_hash、phone）必须单独控制。
实操差异：
- MySQL：必须显式写
GRANT SELECT (id, username, email) ON myapp.users TO 'web_ro'@'%'，不写字段就是全列授权 - PostgreSQL：用视图封装更稳妥，比如
CREATE VIEW login_view AS SELECT username, password_hash FROM users WHERE status = 'active' WITH CHECK OPTION - SQL Server：得用
GRANT SELECT ON OBJECT::users(username, password_hash) TO app_user，还得确认db_datareader角色没覆盖掉它
三个权限陷阱，踩中一个前功尽弃
配得再细，也挡不住这些配置漏洞：
- MySQL关闭严格模式：
sql_mode缺失STRICT_TRANS_TABLES时，SELECT 1,2 FROM dual可绕过UNION字段数校验 - PostgreSQL的
publicschema默认可读：REVOKE USAGE ON SCHEMA public FROM PUBLIC不执行，攻击者就能跑SELECT table_name FROM information_schema.tables扫库 - 账号密码明文写在配置文件里：哪怕只剩
SELECT权限，服务器一旦被拿shell，cat config.yml | grep password就直接连库成功
最小权限不是上线前配一次就完事的事——每次加个报表接口、改个JOIN表、新增搜索字段，都要重走一遍权限评审：这个SQL真的需要查syslogins？那个导出功能真要FILE权限？别让“先开了再说”变成生产环境里的永久后门。
