视图安全的最大漏洞是系统表元数据泄露——information_schema、pg_catalog和sql server系统视图暴露基表结构与脱敏逻辑，必须严格限制普通用户对其的访问权限。
INFORMATION_SCHEMA 和 pg_catalog 是视图安全的最大漏洞口——只要用户能查这些系统表，就能反推出视图里用了哪些基表、哪些字段、甚至脱敏逻辑。光靠“不写敏感列”没用，元数据一暴露，视图就等于裸奔。
MySQL 中必须禁用 SHOW DATABASES 并隔离 information_schema
普通用户默认能查 information_schema.TABLES，这是 SQL 注入后枚举表名的起点。回收 SELECT 权限无效（MySQL 8.0+ 不认这个 revoke），真正有效的组合是：
- 在
my.cnf加skip-show-databases：让非 super 用户执行SHOW DATABASES返回空 - 创建账号时只授目标库权限，例如
GRANT SELECT ON app_db.* TO 'app'@'%'，**绝不授**mysql或information_schema任何权限 - 避免用
WITH GRANT OPTION，防止权限被二次传播
PostgreSQL 必须撤回 pg_catalog 的 USAGE 和关键视图 SELECT
PostgreSQL 默认开放程度更高，pg_tables、pg_views、pg_columns 全部可读。单靠 REVOKE SELECT 不够，因为部分系统视图依赖 superuser 权限，直接 revoke 会失败：
- 先确认用户不在
pg_read_all_data角色中（该角色默认可读所有系统表） - 执行
REVOKE USAGE ON SCHEMA pg_catalog FROM app_user—— 这会让SELECT * FROM pg_catalog.pg_tables直接报permission denied for schema pg_catalog - 再逐个撤回关键视图：
REVOKE SELECT ON pg_tables, pg_views, pg_columns FROM app_user
SQL Server 要严控 VIEW DEFINITION 权限
SQL Server 默认对普通用户隐藏系统视图内容，但一旦授予 VIEW DEFINITION，或用户属于 db_owner，sys.tables、sys.columns 就全量可见：
- 检查所有应用账号：
SELECT name, type_desc FROM sys.database_principals WHERE name = 'app_user' - 撤销权限：
REVOKE VIEW DEFINITION ON SCHEMA::dbo TO app_user - 禁用
SHOWPLAN权限——它也能间接暴露查询结构和表依赖
所有数据库都得关掉 SHOW CREATE VIEW 类命令
这个命令会原样返回视图定义，包括字段别名、CASE WHEN 脱敏逻辑、甚至注释里的业务规则。攻击者拿到定义，就能推断出原始字段名和掩码规律：
- MySQL：执行
REVOKE SHOW VIEW ON *.* FROM 'app'@'%' - PostgreSQL：确保用户没有
pg_read_all_data，且未被显式授予pg_get_viewdef()执行权限 - SQL Server：撤销
VIEW DEFINITION后，sp_helptext和sys.dm_exec_describe_first_result_set也会受限
真正的风险不在视图本身是否写了 password_hash，而在于攻击者能不能通过元数据知道“这张视图背后一定有张叫 users 的表，且它有 email 和 phone 字段”。一旦路径暴露，绕过视图直查基表、构造联合注入、甚至猜解字段名，就只是时间问题。
