Explain Secure Views & Row Access Policies in Databases

61 / 66

Snowflake

Secure Views & Row Access Policies

Restrict which rows and query internals users can see based on their role or attributes.

A secure view hides its underlying query definition and execution details from users who have access to query the view but not to the underlying base tables directly — regular views can leak information through query optimizer behavior (e.g., a WHERE clause pushed into the view revealing data that should be hidden) and through SHOW/DESCRIBE exposing the view's SQL text. Secure views close both gaps at a modest performance cost, since the optimizer can no longer freely rewrite/merge the view's logic with the outer query in the same aggressive ways.

A row access policy is like a security guard checking ID at each row of a filing cabinet drawer, only handing over the folders that match your clearance, while a secure view is like a one-way mirror that lets you see the result of a computation without seeing the notes on how it was calculated.

Key Concepts

Row access policies go further, implementing row-level security: a policy function is attached to a table (or view) and evaluated for every row, returning true/false to determine whether the querying user's context (typically their current role, via CURRENT_ROLE(), or a custom mapping table) is permitted to see that row. This centralizes row-level authorization logic in one policy object rather than duplicating WHERE clause filtering logic across every view or query that touches the table.

row-level securityRow access policiesCURRENT_ROLE()WHERE

Row access policies are typically driven by a small mapping table (e.g., role -> allowed region) that the policy function joins against, so updating access rules means updating the mapping table's data, not redeploying SQL logic across dozens of views.

role -> allowed region

Both mechanisms are commonly combined with dynamic data masking (masking column values) to build a comprehensive, centrally-managed data governance layer — restricting which rows are visible (row access policies), what those visible rows show (masking), and hiding the mechanics of how views compute results (secure views) — all enforced consistently regardless of which tool or user queries the data.

dynamic data masking