标准答案
- 权限条件的输入必须来自可信认证上下文，而不是直接信任请求里的 userId、tenantId 或角色字段。
- 查询构造层适合默认加入租户、软删除和组织范围条件，减少每个业务 SQL 手工拼接遗漏。
- 应用服务仍要校验资源归属和操作权限，特别是按 ID 查询、导出、异步任务和管理操作。
- 数据库视图或行级安全可为多工具、直连分析或高风险表提供纵深防御，但要评估性能、迁移和运维复杂度。
- 应通过自动化测试、审计日志和权限变更回归，覆盖 API、后台任务、脚本、报表与缓存读取等路径。
题目解析
把权限放在单一层非常脆弱。只靠前端隐藏会被直接请求绕过；只靠服务约定会被新脚本遗漏；只靠数据库策略可能难表达复杂业务上下文。分层的目的是让任一层出错时仍有其他检查阻止越权。
默认安全比显式补条件更可靠。开发者不应在每条查询前记住“要加 tenant_id”，而应让数据访问 API 天然要求权限范围，只有经过审查的特权路径才能绕过。
常见误区
- 从请求参数读取 tenantId 直接查询，攻击者修改 ID 就能查看其他租户数据。
- 只为普通 API 做权限过滤，忘记导出、定时任务和缓存 Key 也是数据访问路径。