受限账号不能修复SQL注入漏洞，但能限制攻击后果：通过最小权限原则，使恶意SQL因权限不足而报错，如“permission denied for table users”。
为什么用受限账号能防SQL注入
SQL注入本身是代码漏洞，但受限账号能大幅降低攻击后果——它不修复漏洞，只让漏洞“打不中要害”。比如攻击者通过 user_input 注入了 UNION SELECT password FROM users，如果 Web 服务数据库账号只有 SELECT 权限且仅限 public_posts 表，那这条语句直接报错：ERROR: permission denied for table users。权限越细，攻击者能读/写/删的数据边界就越窄。
常见错误现象：开发环境用 root 或 sa 账号连库，测试时一切正常；上线后哪怕 SQL 漏洞没修，只要换用最小权限账号，很多高危操作（如 DROP TABLE、LOAD_FILE()、跨库查询）会直接失败。
实操建议：
- 为每个 Web 应用创建独立数据库账号，不要复用开发或 DBA 账号
- 只授予
SELECT、INSERT、UPDATE（按需）、DELETE（极少需要），禁用CREATE、DROP、ALTER、EXECUTE、FILE等高危权限 - 限制访问范围：PostgreSQL 用
REVOKE CONNECT ON DATABASE ...+GRANT USAGE ON SCHEMA ...；MySQL 用GRANT ... ON database.table TO 'user'@'host'，避免用*通配库名 - 确认应用连接字符串里填的是这个受限账号，不是硬编码的
root或配置文件里被覆盖的默认值
PHP/Python/Node.js 中如何安全传参给数据库
受限账号只是兜底，真正要防注入，必须杜绝拼接 SQL 字符串。所有主流驱动都支持参数化查询，原理是把用户输入当纯数据传给数据库引擎，和 SQL 语法结构完全分离。
常见错误现象："SELECT * FROM users WHERE id = " . $_GET['id']（PHP）、f"SELECT * FROM logs WHERE level = '{level}'"（Python f-string）——这类写法哪怕用受限账号，也可能触发基于布尔/时间的盲注，或绕过权限做信息探测。
实操建议：
- PHP PDO：用
prepare()+execute()，绑定变量用:id或?占位符，不要用mysql_real_escape_string()（已废弃且不彻底） - Python psycopg2：只用
cursor.execute("SELECT * FROM t WHERE x = %s", [value])，禁用.format()或%插值 - Node.js pg：用
client.query("SELECT * FROM t WHERE id = $1", [id])，$1 是占位符，别写成"... WHERE id = " + id - ORM 用户注意：Django 的
filter(name__contains=request.GET['q'])安全；但extra(where=["name LIKE '%{}%'".format(q)])不安全——绕过 ORM 封装就等于自己拼 SQL
Web 服务进程账号也要受限（不只是数据库账号）
很多人只改了数据库连接账号，却忽略 Web 服务自身运行身份。如果 PHP-FPM、Gunicorn 或 Node 进程以 root 或高权限用户运行，攻击者一旦 RCE（远程代码执行），就能直接读取服务器文件、启动反弹 shell、修改系统配置。
常见错误现象：Nginx + PHP-FPM 配置里 user root;；Dockerfile 里用 USER root 启动应用；systemd service 文件没设 User=www-data。
实操建议：
- Linux 上为 Web 服务创建专用低权限用户（如
webapp），用useradd -r -s /bin/false webapp - Nginx：在
nginx.conf顶部设user webapp;；PHP-FPM pool 配置里设user = webapp和group = webapp - Docker：用
USER 1001:1001（非 root UID/GID），并在镜像里提前创建对应用户 - 验证方式：
ps aux | grep nginx或ps aux | grep gunicorn，确认进程 USER 列不是root
权限收紧后最容易被忽略的兼容性问题
权限收太紧会直接导致功能异常，但错误提示往往很模糊，比如 PostgreSQL 报 permission denied for schema public，其实是因为没给 USAGE 权限；MySQL 报 Access denied; you need (at least one of) the PROCESS privilege(s)，可能只是监控脚本调用了 SHOW PROCESSLIST。
实操建议：
- 上线前在预发环境完整走一遍核心链路：登录、搜索、提交表单、分页、导出——不是只测首页是否 200
- 查日志重点看数据库错误码：
ERROR: permission denied（PostgreSQL）、Access denied for user（MySQL）、SQLSTATE[HY000]（PDO 通用） - 临时加权限要精确到对象：比如缺序列读权限，就
GRANT USAGE ON SEQUENCE orders_id_seq TO webapp，而不是直接GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO webapp - 应用日志里如果出现
pg_last_error()或mysqli_error()输出，说明底层错误没被正确捕获，得先修这部分再调权限
权限模型不是开关，是持续校准的过程。每次加新功能、换数据库版本、升级 ORM，都要重新核对账号权限是否还匹配实际需求——昨天刚好的配置，今天加了一行 ORDER BY RAND() 可能就需要额外函数执行权。
