视图安全需三层控制：定义层必须显式列字段禁用SELECT*，权限层须单独授予视图SELECT权限，元数据层须限制INFORMATION_SCHEMA等系统表访问，缺一不可。
很多人以为创建了视图就万事大吉，其实不然。视图本身并不会自动隐藏敏感列，你必须显式地写出字段名；同时，视图的权限也不从基表继承，必须单独授予——这两点如果没做到，那这个视图基本等于没设防。
视图定义必须显式列出字段，禁用 *
用 SELECT * 来创建视图，是列级信息泄露的典型起点。你想想看，哪怕基表后来只新增了一列 password_hash，视图也会立刻将其暴露无遗。用户只需要执行一句 SELECT * FROM my_view，就能轻松拿到这个敏感字段。
- 正确写法：
SELECT user_id, username, created_at FROM users - 错误写法：
SELECT * FROM users（开发时是省事了，上线后可能就出事了） - 这里有个细节需要注意：MySQL 8.0+ 和 PostgreSQL 都支持这种动态星号写法，但 SQL Server 的视图不会随基表自动更新。这意味着，一旦改了基表结构，你必须手动执行
ALTER VIEW，否则视图可能报错或返回空值。
视图权限必须显式 GRANT SELECT，不能依赖基表权限
这是一个常见的认知误区：用户有基表的 SELECT 权限，不等于就能查视图；反过来，用户没有基表权限，也不等于不能查视图。视图的权限是独立生效的。
- MySQL 授权：执行
GRANT SELECT ON my_user_view TO 'analyst'@'%' - PostgreSQL 授权：执行
GRANT SELECT ON my_user_view TO analyst - 常见错误：只给
users表授权了，却忘了给视图单独授权，结果用户查询时报permission denied for relation users（PostgreSQL）或类似的拒绝提示。 - PostgreSQL 的权限机制更灵活一些。默认情况下，视图会以调用者的身份执行权限检查（
SECURITY INVOKER）。如果你想让它以创建者的身份执行，从而绕过调用者对基表的权限限制，就需要显式设置CREATE VIEW ... WITH (security_invoker = false)，或者在创建后用ALTER VIEW ... SET (security_invoker = false)来修改。
别让视图定义本身变成信息源
这一点往往被忽视。攻击者只要能查询 INFORMATION_SCHEMA.VIEWS 或调用 pg_get_viewdef() 这类函数，就能直接看到视图的完整定义。这意味着，你精心设计的字段列表、用于脱敏的 CASE WHEN 逻辑，甚至背后隐藏的敏感字段名，都可能一览无余。
- MySQL：执行
REVOKE SELECT ON INFORMATION_SCHEMA.VIEWS FROM 'app_user'@'%'（这个权限默认是开放的，需要特别注意） - PostgreSQL：执行
REVOKE SELECT ON pg_views FROM app_user，并确保app_user不在拥有pg_read_all_data权限的角色中。 - 生产环境：务必禁用普通账号的
SHOW CREATE VIEW权限。哪怕这个账号只有SELECT权限，这个命令也会直接返回完整的视图定义。 - 还有更隐蔽的风险：如果你在视图里用了自定义函数做脱敏处理，那么函数体本身也可能被查询（例如通过
pg_get_functiondef()）。更要命的是，如果这个函数内部又去查询了别的配置表，那风险链就被进一步拉长了。
元数据访问必须掐断，否则视图再严也白搭
这是最后一道，也是至关重要的一道防线。只要用户能查询 INFORMATION_SCHEMA.TABLES 或 pg_tables 这类系统表，他就能枚举出数据库里所有的表和列。有了这份“地图”，攻击者就可以有针对性地构造查询，轻松绕过视图的限制。
- MySQL 8.0.29+：可以在配置文件
my.cnf中加入skip-show-databases参数。这样，非超级用户执行SHOW DATABASES时将返回空结果。 - PostgreSQL：关键一步是执行
REVOKE USAGE ON SCHEMA pg_catalog FROM app_user。如果不这么做，用户依然可以执行SELECT * FROM pg_catalog.pg_tables。 - SQL Server：要避免误授
VIEW DEFINITION这类权限，普通账号绝不应该属于db_owner或sysadmin这类高权限角色。 - 值得注意的是，在 MySQL 中回收
information_schema的权限需要显式执行REVOKE。但在部分旧版本中，这可能不生效，这时候就需要依靠关闭元数据访问开关来兜底。
说到底，视图安全最容易被忽略的真相是：它绝非“建完就完”的一次性操作。一个真正安全的视图，依赖于三层控制的紧密配合——定义层（字段必须显式写）、权限层（视图必须单独授权）、元数据层（彻底堵死 schema 查询路径）。这三层，少了任何一层，攻击者都能找到缝隙，从视图之外将你的防御打穿。
