supabase-functions

Secure PostgreSQL functions for Supabase use SECURITY INVOKER by default, explicit search_path configuration, and fully qualified object references. This enforces least-privilege execution, prevents privilege escalation, and ensures predictable behavior across schemas and security contexts in production environments.

SECURITY INVOKER makes a PostgreSQL function execute with the caller's privileges rather than the function owner's. This prevents privilege escalation attacks and is the security-first default for Supabase functions, especially critical when functions interact with Row-Level Security policies.

Safe dynamic SQL uses parameterized queries, input validation, and explicit error handling. Avoid string concatenation; use format() with %I for identifiers and %L for literals, validate all inputs before execution, and implement try-catch patterns to prevent SQL injection and uncontrolled failures.

Yes. PostgreSQL functions work with Supabase RLS through helper routines and trigger functions that respect security context. Functions must use SECURITY INVOKER and fully qualified references to integrate safely with RLS policies and client-library authentication.

Set search_path explicitly to the schemas your function needs, typically starting with an empty string to require fully qualified names. This prevents schema conflicts, ensures predictable object resolution, and blocks privilege-escalation attacks via malicious schema precedence.

Yes. Input validation is essential for production-ready Supabase functions. Validate data types, ranges, and formats before use; combine with parameterized queries and error handling to prevent injection attacks, logic errors, and unhandled database failures.