仅靠参数化查询不能防止多租户越权，必须配合行级隔离、最小权限账号和tenant_id显式绑定三者落地。因为参数化查询仅防御sql注入，无法阻止用户提交非法tenant_id值导致的逻辑越权；若未与登录态强绑定或未在所有查询路径强制注入，攻击者可通过报表接口、搜索框等入口读取其他租户数据；postgresql rls将过滤下推至引擎层，自动为所有操作隐式添加where条件，且依赖会话变量和租户专属角色权限才能真正生效。
仅靠参数化查询不能防止多租户越权，必须配合行级隔离 + 最小权限账号 + tenant_id 显式绑定三者落地。
为什么预编译语句拦不住租户间数据泄露
参数化查询只防“语法注入”，不防“逻辑越权”。比如用户 A 提交 tenant_id=2，后端若没校验该值是否归属当前会话，就直接拼进 WHERE tenant_id = ?，攻击者就能读取租户 B 的全部数据。更危险的是：如果连接池用的是高权限账号（如 app_rw），哪怕 SQL 写对了，DBA 或运维脚本误操作也可能绕过应用层过滤。
- 常见错误现象：报表导出接口返回了其他租户的订单；后台搜索框输入
tenant_id=999后查到非本租户客户 - 根本原因：
tenant_id未与登录态强绑定，或未在所有查询路径中强制注入 - ORM 框架（如 MyBatis）的
#{}只保证单条语句安全，不保证跨表 JOIN 或子查询中漏掉tenant_id
PostgreSQL RLS 是最可靠的行级拦截手段
RLS 把权限检查下推到数据库引擎层，无论 SQL 怎么写、谁执行、从哪来，只要没匹配策略表达式，就自动被过滤。比中间件或 ORM 拦截更底层、更不可绕过。
- 必须先开启：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY - 策略要覆盖所有操作：
CREATE POLICY tenant_isolation ON orders FOR ALL TO app_user USING (tenant_id = current_setting('app.tenant_id', true)::int) - 应用连接时需设置会话变量：
SET app.tenant_id = '123'（不能依赖current_user，否则无法支持单库多租户） - 注意：RLS 策略对
UNION、视图嵌套、CTE 默认生效，但对物化视图和外部表需单独配置
连接池账号权限必须按租户粒度切分
即使开了 RLS，如果应用仍用一个超级账号连库，攻击者拿到连接后可直接 RESET app.tenant_id 或 SET app.tenant_id = 0 绕过策略——RLS 依赖会话变量，而变量可被任意有 SET 权限的用户修改。
- 正确做法：每个租户分配独立数据库角色，如
tenant_123_app，只授予USAGE权限到对应 Schema，并禁用SET权限 - 禁止授予
pg_signal_backend、pg_read_all_data等高级角色 - MySQL 场景下无法原生支持 RLS，必须用
SQL SECURITY DEFINER存储过程封装所有查询，且过程内硬编码tenant_id参数 - HikariCP 等连接池要禁用
connection-init-sql，否则初始化语句可能覆盖租户上下文
tenant_id 不能只靠后端校验
所有入口（API、定时任务、管理后台）都必须在第一层就解析并绑定 tenant_id，且不允许前端传入 raw 值。否则，一旦某个接口漏校验，整个租户边界就崩塌。
- 推荐方式：JWT token 中携带
tenant_id，网关层解码后注入请求头，后端统一从 header 取值（而非 query/body） - 对批量操作（如导入、同步），必须在事务开始前显式调用
SET LOCAL app.tenant_id = ...，避免被长事务污染 - 索引必须包含
tenant_id字段，否则 RLS 过滤后仍走全表扫描，性能归零 - 历史数据迁移脚本、DBA 手工 SQL、ETL 工具等“非应用路径”最容易漏
tenant_id，需单独审计
真正难的不是写对一条带 WHERE tenant_id = ? 的 SQL，而是让 tenant_id 在整个数据流转链路里始终唯一、不可篡改、不可绕过。任何环节松动，越权就发生在毫秒之间。
