A security definer function is a database function that runs with the privileges of its owner rather than the caller. It is used to expose controlled operations through stored code, so access to underlying tables or actions can be granted indirectly while limiting direct permissions on the data or objects involved.
What a security definer function changes in PostgreSQL
A security definer function shifts execution from the caller’s privilege set to the function owner’s privilege set. That makes it useful for narrowly exposing operations the caller should not run directly, while keeping the underlying tables, views, or actions protected.
The practical effect is not “full access through a shortcut.” It is delegated authority, so the security boundary moves from direct object permissions to the code, its owner, and the conditions under which it executes.
Why this pattern exists
Security definer functions are used when you want to publish a controlled interface rather than grant broad table permissions. Common examples include write operations that must enforce business rules, read paths that should hide base tables, and administrative actions that should be callable only through vetted stored code.
This model can simplify access design, but it also concentrates trust in the function body. If the function contains unsafe SQL, unsafe dynamic execution, or unexpected object references, callers may gain more than the intended operation.
For PostgreSQL environments, the surrounding hardening matters. PostgreSQL Security Guide covers the related controls that keep privileged database code safe, including least-privilege roles and search_path safety.
How privilege elevation is constrained
The owner’s privileges do not remove the need for explicit design. A well-constructed security definer function should do only the minimum necessary work, reference only intended objects, and avoid relying on caller-controlled name resolution or hidden defaults.
Because the function executes with elevated authority, the code itself becomes part of the trust boundary. That means the function owner, schema placement, object lookup behavior, and any embedded dynamic SQL can all affect the security outcome.
In practice, this is why many database teams pair this pattern with strict role design and defensive schema control. The goal is to make the function the only sanctioned path to the privileged action, not a general-purpose privilege bridge.
Supabase Keys Security Guide is relevant because it discusses the same indirect-access problem in a platform context, including how stored code, row-level security, and controlled operations can interact.
Security failure modes and operational consequences
The main failure mode is privilege amplification through unsafe code. If a definer function can be influenced by a caller, or if it accesses objects through an unsafe search path, the caller may be able to trigger actions the database owner never intended.
Another common issue is assuming the function itself is the control, when in reality the surrounding database posture decides whether the control is safe. Weak role separation, overly permissive schema access, and poor code review can turn a narrow interface into an escalation path.
Operationally, these functions also complicate review because access no longer maps cleanly to table grants. Security teams need to understand which stored routines execute with elevated authority and whether those routines still match the intended business boundary after schema or application changes.
When to use it, and what to verify
Use a security definer function when you need a precise privileged capability, not when you simply want to avoid designing permissions. The pattern works best when the privileged action is small, stable, and easy to audit.
Verify ownership, schema placement, object references, and the exact set of actions the function can perform. If the function has to call out to multiple objects, dynamic SQL, or rapidly changing logic, the risk of accidental privilege expansion rises quickly.
Security Operating Model and Organisation Design Guide is useful when you need to decide who owns review, approval, and ongoing oversight for privileged database code.
PostgreSQL Security Guide also helps here because the same guide covers the role, schema, and hardening choices that keep elevated database routines bounded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Security definer functions depend on constrained delegated authority. |
| IA-5 — Authenticator Management | Privileged database routines depend on protected secrets and credentials. | |
| Recommendation — Limit routine owners and execution paths to the minimum privileges needed. Protect and rotate the credentials that can invoke or manage privileged database code. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged access rights | Definer functions create privileged execution paths that need formal control. |
| Recommendation — Treat privileged database routines as controlled access paths with defined ownership and review. | ||
| CIS Controls v8 | CIS-5 — Account Management | Database ownership and execution rights must be assigned and reviewed carefully. |
| Recommendation — Review who owns privileged routines and remove unnecessary execution rights. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org