# Ensure views/functions using SECURITY DEFINER are reviewed

- Source: https://support.icompaas.com/support/solutions/articles/a_1790103901624820-ensure-viewsfunctions-using-security-definer-are-reviewed
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Supabase cloud](https://support.icompaas.com/support/solutions/c_1790103054038308) › [supabase checks](https://support.icompaas.com/support/solutions/folders/f_1790103067540538)
- Last updated: 2026-09-22
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure views and functions that run with SECURITY DEFINER are reviewed and kept only where they are truly needed. Views should use security\_invoker so they respect the caller's permissions, and SECURITY DEFINER functions should not be callable by the anon or authenticated roles unless that is intended.

**Rationale**

A SECURITY DEFINER view or function runs with the permissions of its owner, usually a powerful role, instead of the user calling it. This means it can bypass Row Level Security. If such a view or function is exposed through the Data API, any user may be able to read or change data they should not have access to.

**Impact**

-   Views respect the caller's RLS policies
    
-   Reduces the risk of RLS being bypassed
    
-   Some features may need to be redesigned
    

**Default Value**

Views in Postgres run with the owner's permissions by default unless security\_invoker is set. Functions are SECURITY INVOKER by default unless created with SECURITY DEFINER.

**Pre-Requisites**

-   Project Owner or Admin role
    
-   Postgres 15 or later for security\_invoker on views
    

**Test Plan**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open Advisors in the sidebar and select Security Advisor.
    
4.  Check for the findings Security Definer View, and Security Definer Function Executable by anon or authenticated.
    
5.  If any view or function is listed without a clear reason, follow the implementation steps.
    

**Implementation Steps**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open the SQL Editor in the sidebar.
    
4.  For each listed view, run: alter view public.<view\_name> set (security\_invoker = on);
    
5.  For each listed function that should not be public, run: revoke execute on function public.<function\_name> from anon, authenticated;
    
6.  Rerun the Security Advisor and confirm the findings are resolved.
    

**Backout Plan**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open the SQL Editor in the sidebar.
    
4.  For a view, run: alter view public.<view\_name> set (security\_invoker = off);
    
5.  For a function, run: grant execute on function public.<function\_name> to anon, authenticated;
    

**Reference**

-   [https://supabase.com/docs/guides/database/database-advisors?lint=0010\_security\_definer\_view](https://supabase.com/docs/guides/database/database-advisors?lint=0010_security_definer_view)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.