sql视图本身不接受参数，所谓“视图注入”实为应用层拼接用户输入导致；防范关键在于调用时使用参数化查询且数据库账号遵循最小权限原则。
SQL视图本身不接受参数，无法直接被注入
视图（VIEW）是预定义的 SELECT 语句的命名结果集，它不接收运行时参数，也不支持动态拼接。所谓“视图被注入”，实际发生场景一定是：应用层把用户输入拼进 SQL 字符串，再用该 SQL 去查视图——问题出在调用侧，而非视图定义本身。
因此，防范重点不在视图创建语法，而在两点：调用视图的代码是否安全、数据库账号是否有过度权限。
调用视图时必须用参数化查询，不能字符串拼接
常见错误是后端代码把用户输入直接拼进 SQL：
SELECT * FROM user_summary_view WHERE dept = ' + request.query.dept
这等同于绕过所有视图防护。正确做法是使用数据库驱动原生支持的参数占位符：
- PostgreSQL / MySQL / SQL Server：一律用
$1、?或@param占位，由驱动做类型绑定 - 绝不要对用户输入做“转义后拼接”——
pg_escape_string或mysql_real_escape_string已被证明不可靠 - ORM 如 SQLAlchemy、Sequelize 默认启用参数化，但需确认未手动触发
text()或raw()执行
限制视图访问账号只能 SELECT，且仅限必要列
即使调用代码写对了，如果数据库账号有 INSERT/UPDATE/DELETE 权限或能查系统表，攻击者仍可能通过报错、延时等方式探测结构。最小权限原则必须落地：
- 为应用创建专用账号，只授予
SELECT权限到具体视图，例如：GRANT SELECT ON user_summary_view TO app_reader - 视图定义中显式列出字段，避免用
*；敏感字段（如salary、id_card）不要包含在视图里 - 禁用该账号对
pg_catalog、information_schema的查询权限（PostgreSQL）或sys（SQL Server）
复杂视图嵌套时注意定义者权限模型差异
不同数据库对视图执行时的权限检查时机不同，容易误以为“加了视图就安全”：
- PostgreSQL 默认用
SECURITY INVOKER（调用者权限），即检查当前连接账号是否有底层表权限 —— 这意味着若账号本就有表权限，视图形同虚设 - MySQL 5.7+ 支持
SQL SECURITY DEFINER，可让视图以定义者身份执行，从而隔离底层表权限 —— 但要求定义者账号本身权限也必须严格限制 - SQL Server 视图不自动继承
EXECUTE AS，需显式设置执行上下文，否则仍走调用者权限链
真正起作用的是“账号权限 + 调用方式”组合，不是视图语法本身。漏掉任意一环，防护就失效。
