视图权限溢出源于账号被授予超出视图边界的权限，如未禁用view definition导致可反查表结构，或对基表有直接select权而绕过视图逻辑；sql server和postgresql存在权限穿透风险，mysql则因基表权限残留使视图形同虚设。
视图权限溢出不是视图本身的问题，而是账号被授予了超出视图边界的权限——比如给了 SELECT 权限却没禁用 VIEW DEFINITION，结果用户能反查底层表结构甚至跨表推导；或者视图基于多表 JOIN，但账号对其中某张源表有直接 SELECT 权，绕过视图逻辑直接读原始数据。
为什么 GRANT SELECT ON view 不等于“只能看视图”
SQL Server 和 PostgreSQL 都存在“权限穿透”风险：只要账号对视图引用的任意一张基表有 SELECT 权，它就能绕过视图定义，直接查那张表。MySQL 虽不支持直接跨视图权限继承，但若账号本身已被授予基表权限，视图就形同虚设。
- 常见错误现象：
SELECT * FROM vw_user_summary返回正常，但SELECT * FROM users也成功执行——说明账号本就有users表权限 - 使用场景：BI 工具连接数据库时默认尝试枚举所有表（
SELECT * FROM sys.tables），若未DENY VIEW DEFINITION，就会暴露全部表名和字段 - 实操建议：
– 先回收所有基表权限：REVOKE SELECT ON OBJECT::users FROM [webuser]；
– 再单独授视图权限：GRANT SELECT ON OBJECT::vw_user_summary TO [webuser]；
– 最后堵住元数据通道：DENY VIEW DEFINITION ON DATABASE::[mydb] TO [webuser]。
PostgreSQL 中视图权限 + RLS 才算真正隔离
PostgreSQL 的视图本身不带行级过滤能力，仅靠 GRANT SELECT ON TABLE 无法限制“谁能看到哪些行”。必须配合行级安全策略（RLS）+ 视图封装，否则运营人员用同一个账号查视图和查基表，结果可能完全不同。
- 常见错误现象：给
ops_user授了SELECT在vw_recent_orders上，但它仍能SELECT * FROM orders WHERE user_id = 123查到他人订单 - 实操建议：
– 在基表 orders 上启用 RLS：ALTER TABLE orders ENABLE ROW LEVEL SECURITY；
– 创建策略只允许查本人数据：CREATE POLICY orders_self_only ON orders FOR SELECT USING (user_id = current_setting('app.current_user_id', true)::int)；
– 视图仅作字段裁剪或聚合封装，不再承担访问控制职责。
MySQL 8.0+ 列级权限 + 视图组合防越权
MySQL 的视图权限检查较松，且不支持 RLS，但 8.0 开始支持列级 GRANT。如果业务只要求用户通过视图看到部分字段，就不能只依赖视图定义，还要从源头掐断对敏感列的访问能力。
- 常见错误现象：视图
vw_customer_light只选了id, name, city，但账号仍有对customers.ssn列的SELECT权，可直接查出身份证号 - 实操建议：
– 显式收回敏感列权限：REVOKE SELECT (ssn, phone) ON mydb.customers FROM 'report_user'@'%'；
– 对视图单独授权：GRANT SELECT ON mydb.vw_customer_light TO 'report_user'@'%'；
– 确保没有残留的全表 SELECT：SELECT table_name, column_name FROM information_schema.role_column_grants WHERE grantee = "'report_user'@'%'" AND privilege_type = 'SELECT'。
最易被忽略的一点是：视图定义里用了函数或子查询，而账号对那些函数有 EXECUTE 权——这可能间接暴露额外数据源。哪怕视图本身干净，执行时调用的 fn_get_config() 若返回数据库密码，权限链就断了。
