SQL注入能查其他应用表是因为数据库账号权限未最小化隔离，如跨库授权、共用高权账号、INFORMATION_SCHEMA可读等；应为每个应用配专属账号并严格限定库/表权限。
SQL注入成功后，为什么还能查到其他应用的表？
因为数据库用户权限没做最小化隔离，一个应用连的账号能跨库甚至跨 schema 查数据。不是 SQL 注入本身“能横向”，而是它借了这个高权限账号的腿走路。
-
SELECT权限没限制到具体数据库或 schema，比如用GRANT SELECT ON *.*而非GRANT SELECT ON app1_db.* - 多个应用共用同一个 MySQL 用户，且该用户有
INFORMATION_SCHEMA读取权限（默认开启），攻击者靠它枚举库名、表名 - PostgreSQL 中未启用
row_security或没设search_path限制，默认可能搜到public下其他应用的表
怎么让每个应用只能碰自己的库和表？
核心是「连接即隔离」：应用启动时用专属数据库账号连接，且该账号只被授予其业务库的显式权限。
- MySQL：为每个应用创建独立用户，如
CREATE USER 'app2_user'@'%' IDENTIFIED BY 'xxx';，再GRANT SELECT, INSERT ON app2_db.* TO 'app2_user'@'%'; - PostgreSQL：建专用 role + schema，
CREATE SCHEMA app3_schema AUTHORIZATION app3_role;，并确保search_path默认只含该 schema - 禁止使用
root、sa或postgres这类超级用户直连应用——哪怕加了防火墙，密码泄露就全崩
ORM 或查询构建器里，哪些写法会悄悄绕过权限隔离？
权限是数据库层控制的，但代码里某些动态拼接行为会让权限形同虚设——比如把库名/表名当变量插进 SQL。
- 危险示例：
SELECT * FROM ${user_input_table_name}—— 即使账号只授权了app4_db，攻击者传入app4_db.users UNION SELECT * FROM app5_db.users仍可能成功（若权限未按库隔离） - 更隐蔽的是
INFORMATION_SCHEMA查询：如SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE table_schema != 'app6_db'，只要账号有该库读权限，就能扫出其他库结构 - Django 的
extra(tables=['other_app_table'])、SQLAlchemy 的text()原生查询，都可能跳过 ORM 的模型边界，直接撞上数据库权限漏洞
连接池和中间件会不会破坏数据隔离？
会，如果它们复用连接或透传上下文失败。权限在连接建立时就固定了，但连接池可能把 A 应用的连接错分给 B 应用请求。
- Tomcat JDBC Pool、HikariCP 等默认不校验连接归属，必须配置
connectionInitSql（如USE app7_db）或设置search_path初始化语句 - API 网关或数据库代理（如 ProxySQL、pgBouncer）若未按租户路由，可能把请求转发到错误的后端连接，导致权限错位
- 云数据库如 AWS RDS、阿里云 PolarDB 的「数据库账号」粒度通常只到库级，不支持表级自动隔离——得靠应用层配合建独立账号，不能只靠控制台点几下
最常被忽略的一点：开发环境用 root 连接调试，上线时忘了切回受限账号；或者 CI/CD 流水线里硬编码了测试账号，部署时覆盖了生产配置。权限隔离不是设一次就完事，它是每次连接初始化时都要被验证的动作。
