Supabase Security Advisor: a strong configuration safety net
Supabase Security Advisor is one of the first places every Supabase team should check before production. It catches common database security mistakes early, explains why they matter, and points to remediation. Its job is configuration assurance—not investigating live traffic or deciding whether an attacker is active.
Supabase Security Advisor is a native, automatically run database linter that identifies insecure configuration in a Supabase project. Its checks cover common problems such as Row Level Security gaps, exposed sensitive database objects, risky functions and views, permissive policies, and public Storage listing.
Security Advisor measures security posture: whether known configuration conditions exist. Runtime security monitoring answers a different question: whether current Auth, API, database, Storage, Realtime, or Edge Function activity looks like an attack or unauthorized-access attempt.
What Supabase Security Advisor checks
Supabase describes its Database Security and Performance Advisors as tools for finding database issues such as improperly configured RLS policies. Security Advisor runs a set of database queries, called lints, and presents each finding with context and remediation guidance inside Supabase Studio.
The available checks are broader than a single “RLS on or off” test. They examine several ways data or privileged behavior can become exposed through a Supabase database.
| Area | Examples of issues Security Advisor can flag |
|---|---|
| Row Level Security | RLS disabled in a public schema, policies attached while RLS is disabled, RLS enabled without a policy, and overly permissive policies. |
| Database exposure | Sensitive columns, materialized views, foreign tables, or insecure queues exposed through an API-accessible schema. |
| Functions and views | Security-definer views, mutable function search paths, and security-definer functions executable by broad roles. |
| Auth and policy design | The Auth users table exposed, anonymous sign-ins allowed, and policies that rely on user-editable metadata. |
| Storage and GraphQL | Public bucket listing and tables exposed to anonymous or authenticated GraphQL roles. |
| Database hygiene | Extensions installed in a public schema and outdated extension versions. |
Why Security Advisor is valuable
Supabase combines Postgres, a generated Data API, Auth, Storage, Realtime, and server-side functions. A small database change can therefore affect what an internet-facing application can reach. Security Advisor turns hard-to-notice Postgres conditions into a review queue that a small team can understand and act on.
- It is native. Findings appear in the Supabase dashboard next to the database being reviewed.
- It runs automatically. Teams do not need to remember the SQL for every supported lint.
- It is actionable. Findings include the affected object, an explanation, and remediation guidance.
- It is educational. The advisor teaches Supabase- and Postgres-specific security behavior while it reports the problem.
- It is repeatable. Teams can rerun the advisor after a migration or remediation to confirm the finding has cleared.
How to use Security Advisor well
- Run it before production. Supabase includes Security Advisor in its official production checklist.
- Review every finding. Read the affected schema, object, role, and rationale before changing production.
- Test the remediation. RLS, grants, functions, and views can be application-critical. Validate the fix with the roles your app actually uses.
- Rerun after the change. Confirm that the lint has cleared and that the intended application flow still works.
- Check after migrations. New tables, functions, policies, extensions, and Storage changes can introduce new findings.
- Keep the result in context. No findings means the current lints found no matching conditions; it does not certify the whole application or its live activity.
What Security Advisor is not designed to answer
Security Advisor evaluates database state against known checks. It is not a live incident-detection system and does not replace review of Supabase activity logs. A project can be configured correctly and still receive malicious requests, suffer account takeover, or be abused through credentials that are valid but compromised.
| Question | Security Advisor | What answers it |
|---|---|---|
| Is RLS missing or configured in a known risky way? | Yes, for supported lints | Security Advisor |
| Is an exposed object or privileged function configured unsafely? | Yes, for supported lints | Security Advisor |
| Is one source repeatedly trying to break into accounts? | Not its purpose | Auth log monitoring and attack detection |
| Is a valid account suddenly reading data in a suspicious pattern? | Not its purpose | Runtime activity monitoring and investigation |
| Did related events across services form one incident? | Not its purpose | Correlation and incident workflow |
| What evidence should the responder review? | Configuration finding details | Runtime incident evidence for activity |
Configuration security and runtime security belong together
Use Security Advisor to reduce the attack surface and catch common mistakes. Then use logs and continuous monitoring to see how the production system is actually being used. The first prevents avoidable exposure; the second shortens the time between suspicious activity and a human investigation.
For the runtime side, read the Defencecore vs Supabase Security Advisor comparison or the practical guide to Supabase log monitoring.
Frequently asked questions
- What is Supabase Security Advisor?
- Supabase Security Advisor is a native database security linter in Supabase Studio. It runs checks against a project's database configuration and reports risky conditions such as missing RLS, overly permissive policies, exposed sensitive columns, insecure security-definer objects, and public Storage bucket listing.
- Does Supabase Security Advisor run automatically?
- Yes. Supabase says the database advisors run automatically, and a user can manually rerun them after resolving findings. A clean result describes the configuration checked by the available lints at that time; it is not evidence that no attack or unauthorized access is occurring.
- Does Security Advisor detect brute-force attacks?
- Security Advisor is built to find insecure database configuration, not to correlate authentication events into an attack incident. Detecting password spraying, credential stuffing, or repeated failed sign-ins requires runtime activity monitoring of Auth logs or another security monitoring system.
- Does a clean Security Advisor mean a Supabase project is secure?
- No single check can prove that. A clean result means the available advisor lints did not find the configuration problems they test for. Application authorization bugs, stolen credentials, malicious use of valid access, insecure Edge Function logic, and activity patterns outside those lints may still require testing, logging, and monitoring.
- Should I fix every Security Advisor warning?
- Review every finding, but apply remediation with application context. Some policies or exposed objects may be intentional. Confirm the affected object, understand the advisor's rationale, test the proposed change in a safe environment, and rerun the advisor after deployment.