Advisors

Summary: Data API error rate is persistently high

Ramification: Data API requests are returning 5xx errors, so reads and writes from your app may fail.

How to Resolve

Pull up to five recent 5xx responses on /rest/v1 paths from edge_logs with their IDs, timestamps, and status. You can use Logs in Studio, the MCP query_logs tool, or the Management API. Then follow API error troubleshooting.

Summary: Auth error rate is persistently high

Ramification: Users may be unable to sign in or refresh their session.

How to Resolve

Pull up to five recent errors from auth_logs with their IDs, timestamps, and status. You can use Logs in Studio, the MCP query_logs tool, or the Management API. Then use Auth error codes to interpret them.

Summary: Storage error rate is persistently high

Ramification: File uploads and downloads may fail.

How to Resolve

Pull up to five recent errors from storage_logs with their IDs, timestamps, and status. You can use Logs in Studio, the MCP query_logs tool, or the Management API. Then use Storage error codes to interpret them.

Summary: Edge Function error rate is persistently high

Ramification: Features that call your Edge Functions may fail.

How to Resolve

Pull up to five recent failed invocations from function_edge_logs with their IDs, timestamps, and status. You can use Logs in Studio, the MCP query_logs tool, or the Management API. Then use Edge Functions error codes to interpret them.

Level: INFO

Summary: Unindexed foreign keys

Ramification: Database queries that filter or join on these columns will be slower because there is no index to speed them up.

Rationale

In relational databases, indexing foreign key columns is a standard practice for improving query performance. Indexing these columns is recommended in most cases because it improves query join performance along a declared relationship.

What is a Foreign Key?

A foreign key is a constraint on a column (or set of columns) that enforces a relationship between two tables. For example, a foreign key from book.author_id to author.id enforces that every value in book.author_id exists in author.id. Once the foriegn key is declared, it is not possible to insert a value into book.author_id that does not exist in author.id. Similarly, Postgres will not allow us to delete a value from author.id that is referenced by book.author_id. This concept is known as referential integrity.

Why Index Foreign Key Columns?

Given that foreign keys define relationships among tables, it is common to use foreign key columns in join conditions when querying the database. Adding an index to the columns making up the foreign key improves the performance of those joins and reduces database resource consumption.

1
select
2
    book.id,
3
    book.title,
4
    author.name
5
from
6
    book
7
    join author
8
        -- Both sides of the following condition should be indexed
9
        -- for best performance
10
        on book.author_id = author.id

How to Resolve

Given a table:

1
create table book (
2
    id serial primary key,
3
    title text not null,
4
    author_id int references author(id) -- this defines the foreign key
5
);

To apply the best practice of indexing foreign keys, an index is needed on the book.author_id column. We can create that index using:

1
create index ix_book_author_id on book(author_id);

In this case we used the default B-tree index type. Be sure to choose an index type that is appropriate for the data types and use case when working with your own tables.

Example

Let's look at a practical example involving two tables: order_item and customer, where order_item references customer.

Given the schema:

1
create table customer (
2
    id serial primary key,
3
    name text not null
4
);
5
6
create table order_item (
7
    id serial primary key,
8
    order_date date not null,
9
    customer_id integer not null references customer (id)
10
);

We expect the tables to be joined on the condition

1
customer.id = order_item.customer_id

As in:

1
select
2
    customer.name,
3
    order_item.order_date
4
from
5
    customer
6
    join order_item
7
        on customer.id = order_item.customer_id

Using Postgres' "explain plan" functionality, we can see how its query planner expects to execute the query.

1
Hash Join  (cost=38.58..74.35 rows=2040 width=36)
2
  Hash Cond: (order_item.customer_id = customer.id)
3
  ->  Seq Scan on order_item  (cost=0.00..30.40 rows=2040 width=8)
4
  ->  Hash  (cost=22.70..22.70 rows=1270 width=36)
5
        ->  Seq Scan on customer  (cost=0.00..22.70 rows=1270 width=36)

Notice that the condition order_item.customer_id = customer.id is being serviced by a Seq Scan, a sequential scan across the order_items table. That means Postgres intends to sequentially iterate over each row in the table to identify the value of customer_id.

Next, if we index order_item.customer_id and recompute the query plan:

1
create index ix_order_item_customer_id on order_item(customer_id);
2
3
explain
4
select
5
    customer.name,
6
    order_item.order_date
7
from
8
    customer
9
    join order_item
10
        on customer.id = order_item.customer_id

We get the query plan:

1
Hash Join  (cost=38.58..74.35 rows=2040 width=36)
2
  Hash Cond: (order_item.customer_id = customer.id)
3
  ->  Seq Scan on order_item  (cost=0.00..30.40 rows=2040 width=8)
4
  ->  Hash  (cost=22.70..22.70 rows=1270 width=36)
5
        ->  Seq Scan on customer  (cost=0.00..22.70 rows=1270 width=36)

Note that nothing changed.

We get an identical result because Postgres' query planner is clever enough to know that a Seq Scan over an empty table is extremely fast, so theres no reason for it to reach out to an index. As more rows are inserted into the order_item table the tradeoff between sequentially scanning and retriving the index steadily tip in favor of the index. Rather than manually finding this inflection point, we can hint to the query planner that we'd like to use indexes by disabling sequentials scans except where they are the only available option. To provides that hint we can use:

1
set local enable_seqscan = off;

With that change:

1
set local enable_seqscan = off;
2
3
explain
4
select
5
    customer.name,
6
    order_item.order_date
7
from
8
    customer
9
    join order_item
10
        on customer.id = order_item.customer_id

We get the query plan:

1
Hash Join  (cost=79.23..159.21 rows=2040 width=36)
2
  Hash Cond: (order_item.customer_id = customer.id)
3
  ->  Index Scan using ix_order_item_customer_id on order_item  (cost=0.15..74.75 rows=2040 width=8)
4
  ->  Hash  (cost=63.20..63.20 rows=1270 width=36)
5
        ->  Index Scan using customer_pkey on customer  (cost=0.15..63.20 rows=1270 width=36)

The new plan services the order_item.customer_id = customer.id join condition using an Index Scan on ix_order_item_customer_id which is far more efficient at scale.

Level: ERROR

Summary: User data exposed through a view

Ramification: A view is exposing your users' personal information to anyone who can access your API.

Rationale

Referencing the auth.users table in a view can inadvertently expose more data than intended.

Why shouldn't you expose auth.users with a view?

auth.users is the primary table that backs Supabase Auth. It contains detailed information about each of your projects users, their login methods, and other personally identifiable information.

In Postgres, the built in mechanism for controlling access to rows within a table is row level security (RLS). By default, views in Postgres are "security definer" which means they do not respect RLS rules associated with the tables in the view's query. Materialized views similarly don't support RLS.

As a result, a public security definer view referencing auth.users exposes all user records to all API users, which is likely not what application developers intended.

How to Resolve

There are 2 recommended solutions for exposing user data to your application.

Trigger on auth.users

This option involves creating a table in the public schema, e.g. public.profiles, containing a subset of columns from auth.users that are appropriate for your application's use case. You can then set a trigger on auth.users to automatically insert the relevant data into public.profiles any time a new user is inserted into auth.users.

Note that triggers execute in the same transaction as the insert into auth.users so you must check the trigger logic carefully as any errors could block user signups to your project.

An additional benefit of this approach is that the public.profiles table provides a logical place to store any additional user metadata that is needed for the application.

To start we need a location to store public user data in the public schema:

1
create table public.profiles (
2
  id uuid not null references auth.users on delete cascade,
3
  first_name text,
4
  last_name text,
5
6
  primary key (id)
7
);

Next, we create a trigger function to copy the data from auth.users into public.profiles when new rows are inserted

1
-- inserts a row into public.profiles
2
create function public.handle_new_user()
3
returns trigger
4
language plpgsql
5
security definer set search_path = public
6
as $$
7
begin
8
  insert into public.profiles (id, first_name, age)
9
  values (new.id, new.raw_user_meta_data ->> 'first_name', new.raw_user_meta_data['age']::integer);
10
  return new;
11
end;
12
$$;
13
14
-- trigger the function every time a user is created
15
create trigger on_auth_user_created
16
  after insert on auth.users
17
  for each row execute procedure public.handle_new_user();

Finally, we can create row level security policies on the public.profiles schema to restrict access to certain operations:

1
alter table public.profiles enable row level security;
2
3
create policy "Public profiles are viewable by everyone."
4
  on profiles for select
5
  using ( true );
6
7
create policy "Users can update own profile."
8
  on profiles for update
9
  using ( auth.uid() = id );

For more information on this approach see the auth docs.

Security Invoker View with RLS on auth.users

The second recommended approach to securely exposing auth.users data is to create a view with the configuration option security_invoker=on. That setting, introduced in Postgres 15, tells the view to respect the RLS policies associated with the underlying tables from the query. Next, we can enable RLS on auth.users and create any policy we need to restrict access to the data.

To enable security invoker mode on the view we can use the with (security_invoker=on) clause:

1
create view public.members
2
    with (security_invoker=on)
3
    as
4
select
5
    id,
6
    raw_user_meta_data ->> 'first_name' as first_name,
7
    created_at
8
from
9
    auth.users;

Next, grant permissions and enable RLS on auth.users:

1
grant select on auth.users to authenticated;
2
alter table auth.users enable row level security;

and finally, create a policy defining which users should be able to see each record:

1
create policy select_self on auth.users
2
  for select
3
  using ((select auth.uid()) = id);

Level: WARN

Summary: Slow security policy detected

Ramification: A security policy is running its check on every single row instead of once per query, which slows down your database as your tables grow.

Rationale

Row-Level Security (RLS) policies are the mechanism for controlling access to data based on user roles or attributes. These policies frequently use the built-in current_setting function and provided helper functions in the auth schema including auth.uid(), auth.role(), auth.email(), and auth.jwt() to retrieve information about the current querying user. Improperly written RLS policies can cause these functions to execute once-per-row, rather than once-per-query. While the current_setting() and auth.<function_name>() functions are efficient, if executed once-per-row they can lead to significant performance bottlenecks at scale.

The Performance Issue

When an RLS policy is applied to a query, the conditions specified in the policy are evaluated for each row that the query touches. This means that if a policy condition calls a helper function like auth.uid(), this function is executed repeatedly for every row. In queries affecting thousands of rows, this behavior can drastically reduce query performance, as the overhead of executing these functions adds up quickly.

How to Resolve

To optimize the performance of RLS policies using auth helper functions we aim to reduce the number of times the helper functions are called. This can be achieved by caching the result of the function call for the duration of the query. Instead of calling the function directly in the policy condition, you can wrap the function call in a subquery. This approach executes the function once, caches the result, and compares this cached value against the column values for all subsequent rows.

For example, consider the policy:

1
create policy "inefficient_document_access" on documents
2
to authenticated
3
using ( auth.uid() = creator_id );

In this policy, auth.uid() is called for every row in the documents table to check if the creator_id matches the current user's ID. If the number of rows in documents is 150,000 the auth.uid() function will be executed 150,000, potentially incurring over 3 seconds of overhead per query.

If we wrap the auth.uid() call in a subquery:

1
create policy "efficient_document_access" on user_data
2
to authenticated
3
using ( (select auth.uid()) = user_id );

Then auth.uid() is called only once at the beginning of the query execution, and its result is reused for each row comparison. That change reduces the overhead from a few seconds to a few microseconds with no impact on the result set.

Since the output values for the auth helper functions are set on a per-query basis there is no downside to aggressively applying this performance optimization.

Level: INFO

Summary: Table has no primary key

Ramification: Without a primary key, rows can't be uniquely identified, which can cause data issues and slower queries.

Rationale

Tables in a relational database should ideally have a key that uniquely identifies a row within that table. Tables lacking a primary key is often considered poor design, as it can lead to data anomalies, complicate data relationships, and degrade query performance.

What is a Primary Key?

A primary key is a single column or a set of columns that uniquely identifies each row in a table.

Primary keys are important because they enable:

1. Uniqueness and Integrity: Ensures that each row in the table is unique and identifiable.
2. Performance: The database automatically creates an index for the primary key, improving query performance when retrieving or manipulating data based on the primary key.
3. Relationships: Unique keys, like primary keys, are a prerequisite for defining foreign keys in other tables, which are critical for relational database design and efficient joins.

How to Resolve

For a table that lacks a primary key, the resolution involves identifying a column (or a set of columns) that can uniquely identify each row and altering the table to designate those columns as the primary key.

Given a table:

1
create table customer (
2
    id integer not null,
3
    name text not null,
4
    email text not null
5
    -- Notice the lack of a PRIMARY KEY constraint
6
);

If we assume id is unique for each customer, we can add a primary key constraint to the table using:

1
alter table customer add primary key (id);

If no single column can serve as a unique identifier, consider using a composite key. A composite key combines multiple columns to form a unique identifier for each row.

Example:

Consider a table event_log that logs user activities without a primary key:

1
create table event_log (
2
    user_id integer not null,
3
    event_time timestamp not null,
4
    action text not null
5
    -- A combination of user_id and event_time can uniquely identify rows
6
);

To resolve the lack of a primary key and ensure that each log entry is uniquely identifiable, we can add a composite primary key on user_id and event_time:

1
alter table event_log add primary key (user_id, event_time);

Ensure every table has a primary key, even if it's a synthetic key that doesn't have a natural counterpart in the data model. When possible, use a simple fixed size types like int, bigint, and uuid as the primary key for maximum efficiency.

Level: INFO

Summary: Unused index found

Ramification: This index is never used by any query but still slows down every insert, update, and delete on the table.

Rationale

Unused indexes in a database are a silent performance issue. While indexes are important for speeding up search queries, every index also adds overhead to the database. This overhead occurs because the database must update each index whenever data in the indexed table are inserted, updated, or deleted. If an index is never used by your queries, it burdens the database with unnecessary work, which can slow down write operations and consume additional storage space.

What is an Index?

An index in a database is similar to an index in a book. It allows the database to find data without scanning the entire table. An index is created on a column or a set of columns in a table. Queries that search or sort data based on these columns can find data more quickly and efficiently by referring the index instead of each row in the table.

What are Unused Indexes

Unused indexes are indexes that have not been accessed by any query execution plans. This might occur if indexes were created proactively to support potential future query patterns or if application usage patterns change after a schema migration.

How to Resolve

Before deleting an index, it's important to confirm that the index is genuinely unused and was unintentionally created:

• Consider future usage patterns. An index might be unused now but could be critical for upcoming features or during specific times of the year.
• Test the impact of removing the index in a development or staging environment to ensure that performance or query plans are not adversely affected.

To remove an unused index, use the drop index statement:

1
drop index <schema_name>.<index_name>;

Replacing schema_name and index_name with the actual names from your database.

Level: WARN

Summary: Multiple permissive policies on a table

Ramification: When several permissive policies exist on one table, access can become broader than intended and queries slower.

Rationale

In Postgres, Row Level Security (RLS) policies control access to rows in a table based on the executing user. When multiple permissive policies are applied to the same table the user may have access to a selected row through any of those policies. This means that, in the worst case, all of the relevant RLS policies must be applied/tested before Postgres can determine if a row should be visible. At scale, these checks add significant overhead to SQL queries and can be a performance bottleneck.

Row Level Security Policies

RLS policies in Postgres are rules applied to tables that determine whether rows can be selected, inserted, updated, or deleted. These policies can be set to PERMISSIVE or RESTRICTIVE. Permissive policies allow actions unless explicitly restricted by a restrictive policy. When multiple permissive policies are defined for a table, they act in a cumulative manner — if any policy allows access, the access is granted. In other words, the policies compose with OR semantics.

Risks with Multiple Permissive Policies

Access Control

Multiple permissive policies on a table can make it challenging to accurately predict and control which rows are accessible to different users. This complexity can inadvertently lead to overly permissive access configurations, undermining data security and integrity.

Performance

Since any one of N permissive policies can provide a user access to a given table's row, in the worst case Postgres must execute all N policies to determine if a row should be visible. These multiple checks raise the probability of a query falling off an index and broadly increase the resource consumption of every query on the impacted table.

How to Resolve

Consider a table employee_data with two permissive policies:

Policy A allows access to employees in the same department. Policy B allows access to employees at or above a certain grade level.

Our intention is for users to be able to see employee data for employees within their own department who are below the querying user's grade level.

1
-- Policy A
2
create policy department_access on employee_data
3
    for select
4
    using (department = current_user_department());
5
6
-- Policy B
7
create policy grade_level_access on employee_data
8
    for select
9
    using (grade_level <= current_user_grade_level());

The implementation contains a logic error. As written, every employee can see employee_data for every other employee within their departemnt. Similarly, every employee can see every other employee's data at or below their own grade level.

To address this issue, we can combine the two policies.

1
drop policy department_access on employee_data;
2
drop policy grade_level_access on employee_data;
3
4
create policy consolidated_access on employee_data
5
    for select
6
    using (
7
        department = current_user_department()
8
        or grade_level >= current_user_grade_level()
9
    );

In addition to addressing the logic bug, we have also improved the Postgres query planner's ability to inline the policy to check access to rows, which reduces the chance of the query falling off index.

While consolidating RLS policies for a given role/action combination is a best practices, it is not a hard rule. If consolidating policies leads to unreadable SQL then you may opt to have multiple policies for maintainability.

Level: INFO

Summary: Security policy not enforced

Ramification: A security policy exists but has no effect because Row-Level Security hasn't been turned on for the table.

Rationale

In Postgres, Row Level Security (RLS) policies control access to rows in a table based on the executing user. Policies can be created, but will not be enforced until the table is updated to enable row level security. Failing to enable row level security is a common misconfiguration that can lead to data leaks.

How to Resolve

To enable existing policies on a table execute:

1
alter table <schema>.<table> enable row level security;

Example

Given the schema:

1
create table public.blog(
2
    id int primary key,
3
    user_id uuid not null,
4
    title text not null
5
);
6
7
create policy select_own_posts on public.blog
8
    for select
9
    using ((select auth.uid()) = user_id);

A user may incorrectly believe that their policies are being applied. Before the policies will take effect, we first must enable row level security on the underlying table.

1
alter table public.blog enable row level security;

Level: INFO

Summary: No access rules defined

Ramification: Row-Level Security is enabled but no policies exist, so no data can be read or written through the API.

Rationale

In Postgres, Row Level Security (RLS) policies control access to rows in a table based on the executing user. If a table has RLS enabled, but no policies exist, no data will be selectable via Supabase APIs.

How to Resolve

If a table has RLS enabled with no policies, you can resolve the issue by creating a policy on the table

For example:

1
create policy select_own_posts on public.blog
2
    for select
3
    using ((select auth.uid()) = user_id);

Example

Given the schema:

1
create table public.blog(
2
    id int primary key,
3
    user_id uuid not null,
4
    title text not null
5
);
6
7
alter table public.blog enable row level security;

No data will be selectable from the public.blog table over Supabase APIs.

To resolve the issue, create a policy on public.blog to grant some level of access

1
create policy select_own_posts on public.blog
2
    for select
3
    using ((select auth.uid()) = user_id);

Note that some users may enable RLS with no policies intentionally to restrict access over APIs. In those cases we recommend making that intent explicit with a rejection policy.

1
create policy none_shall_pass on public.blog
2
    for select
3
    using (false);

Level: WARN

Summary: Duplicate index found

Ramification: Identical indexes on the same table waste storage and slow down writes with no performance benefit.

Rationale

Each index in a Postgres database adds overhead. This overhead occurs because the database must update each index whenever data in the indexed table are inserted, updated, or deleted. If two or more indexes are exact duplicates in their composition, the database incurs additional write overhead for no performance benefit.

What is an Index?

An index in a database is similar to an index in a book. It allows the database to find data without scanning the entire table. An index is created on a column or a set of columns in a table. Queries that search or sort data based on these columns can find data more quickly and efficiently by referring the index instead of each row in the table.

How to Resolve

When a table contains a duplicate index, drop instances of the index until only one remains.

For example, if the table public.blog has duplicate indexes public.ix_id_1 and public.ix_id_2 drop one using:

1
drop index public.ix_id_2;

Level: ERROR

Summary: View bypasses row-level security

Ramification: A view in the public schema runs with elevated privileges and ignores Row-Level Security, which could expose more data through the API than intended.

Rationale

Postgres' default setting for views is SECURITY DEFINER which means they use the permissions of the view's creator, rather than the permissions of the querying user when executing the view's underlying query. That is an unintuitive default, chosen for backwards compatibility with older Postgres versions, which makes it easy to accidentally expose more data in views than was intended.

Understanding SECURITY DEFINER and SECURITY INVOKER

In PostgreSQL, a view can be defined with either the SECURITY DEFINER or SECURITY INVOKER option.

• SECURITY DEFINER: This setting causes the view or function to run with the privileges of the user who created it, regardless of the user who invokes it. This can be useful for allowing a less-privileged user to perform specific tasks that require higher privileges but poses a significant security risk if not handled carefully. It is common for views to be created by highly privileged users with the ability to bypass row level security which further exacerbates the risk.

• SECURITY INVOKER: Conversely, with SECURITY INVOKER, the view or function executes with the privileges of the user calling it, respecting the principle of least privilege and significantly reducing the risk of unintentional privilege escalation.

The Risk of SECURITY DEFINER Views in Public Schema

Creating a view in the public schema makes that view accessible via your project's APIs. If the view is created through Supabase Studio or using the Supabase CLI in SECURITY DEFINER mode, the view will bypass row level security rules and could expose more data publically over the project's APIs than the developer intended.

How to Resolve

To mitigate the risk, always set with (security_invoker=on) when a view should respect RLS policies.

Given the view:

1
create view public.order_items
2
    as
3
select
4
    id,
5
    ...
6
from
7
    app.order_items;

Enable SECURITY INVOKER mode using:

1
create view public.order_items
2
    with (security_invoker=on)
3
    as
4
select
5
    id,
6
    ...
7
from
8
    app.order_items;

Level: WARN

Summary: Unsecured function search path

Ramification: Without a fixed search path, this function could behave unpredictably or be exploited to reference unintended database objects.

Rationale

In PostgreSQL, the search_path determines the order in which schemas are searched to find unqualified objects (like tables, functions, etc.). Setting search_path explicitly for a function is a best practice that ensures its behavior is consistent and secure, regardless of the executing user's default search_path settings. We recommend pinning functions' search_path to an empty string, search_path = '', which forces all references within the function's body to be fully qualified. This helps prevent unexpected behavior due to changes in the search_path and mitigates potential security vulnerabilities.

What is the Search Path?

The search path in PostgreSQL is a list of schema names that PostgreSQL checks when trying to resolve unqualified object names like profiles. In contrast, a fully qualified name includes the schema like public.profiles, and always resolves the same way, regardless of the user's search_path. By default, search_path includes the user's schema and the public schema. However, this can lead to unexpected behavior if different users have different search_path settings. Specifically, unqualified references will be resolved differently depending on who is executing the function.

The Issue with Not Setting the Search Path in Functions

When a function does not have its search_path explicitly set, it inherits the search_path of the current session when it is invoked. This behavior can lead to several problems:

• Inconsistency: The function may behave differently depending on the user's search_path settings.
• Security Risks: Malicious users could potentially exploit the search_path to direct the function to use unexpected objects, such as tables or other functions, that the malicious user controls.

How to Resolve

To ensure that your functions are secure and behave consistently, set the search path explicitly to an empty string within the function's definition.

Given a function like:

1
create function example_function()
2
  returns void
3
  language sql
4
as $$
5
  -- Your SQL code here
6
$$;

You can create or replace the function and add the search_path setting.

1
create or replace function example_function()
2
  returns void
3
  language sql
4
  set search_path = '' -- LOOK HERE
5
as $$
6
  -- Your SQL code here.
7
$$;

Remember that once you set the search_path = '' all references to tables/functions/views/etc in your function's body must be qualified with a schema name.

Level: INFO

Summary: Anonymous sign-ins enabled

Ramification: Anonymous users share the same database role as permanent users, so existing security policies may unintentionally grant them access.

Rationale

Anonymous users use the same authenticated Postgres role as permanent users when accessing the database. If you have enabled anonymous sign-in for your project, existing RLS policies may allow unintended access to an anonymous user's JWT.

Difference between an anonymous user and a permanent user

An anonymous user is a user created through Supabase Auth. It is just like a permanent user, except the user can't access their account if they sign out, clear browsing data or use another device. An anonymous user can be differentiated from a permanent user by checking if the is_anonymous claim is true. These claims are returned by the auth.jwt() function.

How to Resolve

Determine if existing row level security (RLS) policies are meant to allow access to anonymous users. Affected policies include those that are associated to the authenticated or public roles, and members of those roles that inherit privileges.

For example, consider the policy:

1
create policy "allow_access_to_authenticated" on documents
2
as restrictive
3
to authenticated
4
using (true);

In this policy, any JWT that contains the authenticated role will be allowed to access the documents table. If we want to restrict access to permanent users only, we can modify the policy to:

1
create policy "allow_access_to_permanent_users" on documents
2
as restrictive
3
to authenticated
4
using ( (select (auth.jwt()->>'is_anonymous')::boolean) is false );

Level: ERROR

Summary: Table publicly accessible

Ramification: Anyone with your project URL can read, edit, and delete all data in this table because Row-Level Security is not enabled.

Rationale

Tables in the public schema are accessible over Supabase APIs. If row level security (RLS) is not enabled on a public table, anyone with the project's URL can CREATE/READ/UPDATE/DELETE (CRUD) rows in the impacted table. Publicly exposing full CRUD to the internet is a critically unsafe configuration.

How to Resolve

To enable RLS on a table execute:

1
alter table <schema>.<table> enable row level security;

Note that after enabling RLS you will not be able to use the anon role to read or write data to the table via Supabase APIs until you create row level security policies to control access.

Example

Given the schema:

1
create table public.blog(
2
    id int primary key,
3
    user_id uuid not null,
4
    title text not null
5
);

Any user with access to the project's URL will be able to perform CRUD operations on the public.blog table. To restrict access to users specified in row level security policies, enable RLS with:

1
alter table public.blog enable row level security;

If data APIs are not being used, another option is to remove the relevant schema, e.g. public, from the Exposed schemas in API settings. That change secures your project by making all entities in the removed schema inaccessible over APIs.

Level: WARN

Summary: Extension installed in public schema

Ramification: The extension's internal functions and tables are visible in your API, cluttering it and potentially exposing unintended functionality.

Rationale

Entities like tables and functions in the public schema are exposed through Supabase APIs by default. When extensions are installed in the public schema, the functions, tables, views, etc that they contain appear to be part of your project's API.

How to Resolve

To relocate an extension from the public schema to another schema, execute:

1
alter extension <some_extension> set schema <some_schema>;

Example

If the ltree extension was initially created in the public schema with

1
create extension ltree;

or

1
create extension ltree schema public;

You can relocate its components to the extensions schema by running

1
alter extension ltree set schema extensions;

Level: ERROR

Summary: Security policy relies on user-editable data

Ramification: A security policy references user_metadata, which end users can freely modify, allowing them to bypass access controls.

Rationale

Supabase Auth user_metadata is used to set metadata about the user on sign up. It is designed to be manipulated by the user themselves. Because the user can change it (either directly or indirectly by sending a user update API call) to any value (there is no validation) this should not be used to base security policies.

The Risk

Row-Level Security (RLS) policies are the mechanism for controlling access to data based on user roles or attributes. Supabase Auth user_metadata allows metadata to be assigned to users, but that metadata can also be manipulated by the end user using client libraries. For example, in supabase-js:

1
updateUser({ data: { is_admin: true } })

For that reason, it is not safe to rely on the contents of user_metadata in row level security policies.

An example insecure policy could be:

1
create policy bad_policy on public.foo
2
for select
3
  to authenticated
4
  using ( (( select auth.jwt() ) -> 'user_metadata' ->> 'is_admin' )::bool );

The policy is insecure because end users could execute updateUser({ data: { is_admin: true } }) to bypass the security check.

How to Resolve

There is no one-size-fits-all solution to replacing a RLS policy that references user_metadata.

If you're unsure how to refactor your policy to remove its dependance on user_metadata open a ticket with support for assistance.

Level: WARN

Summary: Materialized view exposed in API

Ramification: Materialized views can't be protected by Row-Level Security, so all their data is visible to every API user.

Rationale

Materialized views in Postgres can present a security risk if they are accessible to API roles anon and authenticated. Unlike regular views, materialized views can not be configured to respect Row Level Security (RLS) policies of the underlying tables they are built upon, nor can they cannot be secured with RLS directly. Therefore, if materialized views are accessible over APIs, all rows are always visible, which may not be intended.

The Risk of Materialized Views Accessible by Anon or Authenticated Roles

If materialized views are exposed in APIs and accessible by the anon or authenticated roles, API users bypass any Row-Level Security (RLS) policies implemented on the underlying tables. This can lead to unintended exposure of sensitive data as all users will be able to select all rows of data from the materialized views.

How to Resolve

To mitigate the risk it is recommended to revoke select access from API roles anon and authenticated.

1
revoke select on public.some_mat_view from public, anon, authenticated;

Note that the public role is a role that sets default permissions for all other roles. If the public role allows access by default (as it does in the public schema) you must also revoke select accesss from it.

You can test if your permissions update worked sucessfully by running

1
select pg_catalog.has_table_privilege('anon', 'public.some_mat_view'::regclass::oid, 'select')
2
-- Should return: 'false'

Substituting in the appropriate role and view name.

Level: WARN

Summary: Foreign table exposed in API

Ramification: Foreign tables can't be protected by Row-Level Security, so all their data is visible to every API user.

Rationale

Foreign Tables in Postgres can present a security risk if they are accessible to API roles anon and authenticated. Unlike regular tables, foreign tables can not be configured to respect Row Level Security (RLS) policies. Therefore, if foreign tables are accessible over APIs, all rows are always visible, which may not be intended.

How to Resolve

If the foreign table does not need to be accessible over the API you can resolve the issue by revoking select access from API roles anon and authenticated.

1
revoke select on public.some_foreign_table from public, anon, authenticated;

Note that the public role is a role that sets default permissions for all other roles. If the public role allows access by default (as it does in the public schema) you must also revoke select accesss from it.

You can test if your permissions update worked sucessfully by running

1
select pg_catalog.has_table_privilege('anon', 'public.some_foreign_table'::regclass::oid, 'select')
2
-- Should return: 'false'

Substituting in the appropriate role and view name.

If you do need to access data from the foreign table over APIs we recommend moving the foreign table out of the API's exposed schemas and then creating a function, accessible over RPC, that implements security rules on top of the foreign table. For example, if we wanted to confirm that the Supabase Auth user matches the author_id column of the foreign table the function might look like:xt

1
-- Create a new schema
2
create schema private;
3
4
-- Move the foreign table out of the API's exposed schemas
5
alter foreign table public.some_foreign_table set schema private;
6
7
-- Make sure the API roles still have access to the FDW
8
grant select on public.some_foreign_table to anon, authenticated;
9
10
-- Create a function/RPC target with security rules
11
create or replace function fdw_wrapping_function()
12
  returns table (id integer, data text, author_id uuid)
13
  language sql
14
  set search_path = ''
15
as $$
16
  select
17
    id,
18
    data,
19
    author_id
20
  from
21
    private.some_foreign_table
22
  where
23
    author_id = (select auth.uid()); -- SECURITY RULE
24
$$;

Level: WARN

Summary: Column type blocks Postgres upgrades

Ramification: A table uses a Postgres internal type that is not supported by pg_upgrade, which will prevent you from upgrading to future Postgres versions.

Rationale

Referencing reg* types that describe Postgres internals like types, namespaces, procedures, etc is a risk as these types are not supported by pg_upgrade, the standard tool for upgrading between Postgres versions.

How to Resolve

If a reference to an disallowed reg* type is needed:

1
create table public.bad_table(
2
  id int primary key,
3
  -- Not Allowed
4
  my_collation regcollation
5
);

Store the test representation of the object instead so that it will be compatible with upgrade.

1
create table public.good_table(
2
  id int primary key,
3
  -- Not Allowed
4
  my_collation_name text
5
);

Level: ERROR

Summary: Queue exposed without protection

Ramification: Anyone with your project URL can read, modify, and delete messages in this queue because it lacks access controls.

Rationale

Queues exposed over Data APIs must be secured by Postgres permissions or row level security (RLS). Without this protection, anyone with a project's URL can manipulate queue data. That is a critically unsafe configuration.

How to Resolve

To secure a queue, enable RLS on the queue's underlying table pgmq.q_<queue_name>:

1
alter table pgmq.q_<queue_name> enable row level security;

Note that after enabling RLS you will not be able to access data in the queue over APIs until you create row level security policies to control access.

Example

Given a queue named foo and underlying table pgmq.q_foo:

1
create table pgmq.q_foo(
2
    msg_id bigint generated always as identity,
3
    read_ct int default 0 not null,
4
    enqueued_at timestamp with timezone default now() not null,
5
    vt timestamp with time zone not null,
6
    message jsonb
7
);

If Data APIs are enabled, and anon or authenticated have permissions on the table, any user with access to the project's URL and public API key will be able to manipulate messages in that Queue. To restrict access to users specified in row level security policies, enable RLS with:

1
alter table pgmq.q_foo enable row level security;

If queues are not being accessed through data APIs, an alternative is to remove the pgmq_public schema from the Exposed schemas in API settings. That change secures your project by making all queues inaccessible over APIs.

Level: WARN

Summary: Excess table bloat detected

Ramification: The table has accumulated significant unused space from old row versions, which increases storage costs and slows down queries.

Rationale

In PostgreSQL, bloat occurs when tables contain extra, unused space due to deleted or updated rows. PostgreSQL doesn’t immediately reclaim the space used by these rows but instead marks it as reusable for future operations. Over time, if this space isn’t efficiently reused, the table becomes bloated, meaning it takes up more storage than necessary, slowing down database performance and increasing I/O overhead.

What Causes Bloat?

Updates: When a row is updated, PostgreSQL creates a new version of the row, leaving the old version in the table as "dead space." Deletes: Deleting rows leaves behind empty space that’s not automatically removed. Table Design: Frequent changes to large tables with many columns or high variability in row size can lead to fragmentation.

PostgreSQL’s autovacuum process is designed to clean up these "dead tuples" and prevent excessive bloat. It works in the background to reclaim space and make it available for future use. However, autovacuum may not always keep up with bloat in certain situations, such as:

• Large or high-traffic tables with frequent updates/deletes.
• Inefficient vacuum settings in your database configuration.
• Tables requiring a more aggressive maintenance operation (e.g., vacuum full or cluster).

Excessive table bloat increases the size of your database on disk and slows down operations like reads, writes, and sequential scans. Left unresolved, it can cause noticeable degradation in application performance and higher costs for storage and computing resources.

If this lint repeatedly flags the same table for high bloat, it indicates an issue with your database's maintenance processes. Possible causes include:

• Autovacuum not running frequently enough.
• Maintenance operations being blocked or ineffective.
• Application-level behavior (e.g., frequent updates or deletes) creating excessive dead tuples.

In such cases, you should reach out to Supabase Support for assistance in diagnosing and resolving the underlying problem. They can help you tune autovacuum settings, optimize table design, or recommend appropriate maintenance strategies.

How to Resolve

Vacuuming a table repacks it to remove fragmentation. However, be cautious when running vacuum full on large tables (>300k rows) in a production environment because vacuum full locks the table, blocking all other accesses until it finishes. For large and heavily used tables, this can lead to significant downtime or performance stalls.

For very large tables a less intrusive alternative might be using pg_repack.

Example of running vacuum full:

1
vacuum full public.some_table;

Important Note:

If vacuum full is not an option (due to locking concerns), consider plain vacuum (with or without analyze) or tools like pg_repack. Always test in a staging environment if you are unsure about the impact on live traffic. You can verify your maintenance steps by checking the size of the table before and after vacuuming:

1
-- size before
2
select pg_size_pretty(pg_table_size('public.some_table'));
3
4
-- run vacuum or other maintenance
5
6
-- size after
7
select pg_size_pretty(pg_table_size('public.some_table'));

If your maintenance was successful, you should see a noticeable decrease in table size and improved query performance.

Level: ERROR

Summary: Foreign key blocks Auth upgrades

Ramification: A foreign key references a constraint in the auth schema that is scheduled for removal, which will prevent future Auth updates and security patches.

Rationale

Supabase Auth does not support user-defined foreign keys that reference non-primary key unique constraints in the auth schema. These unique constraints are scheduled for removal, and any foreign keys referencing them will block Supabase Auth's database migrations from completing successfully. If Supabase Auth is unable to upgrade, it prevents the rollout of new features and critical security updates.

How to Resolve

To ensure successful migrations and continued updates:

1. Drop Foreign Keys: Remove any foreign key constraints that reference unique constraints in the auth schema.

1
alter table public.some_tablee
2
drop constraint some_foreign_key;

2. Reference Primary Keys Instead: If applicable, replace references to unique constraints with references to the corresponding table's primary key.

Level: WARN

Summary: Extension out of date

Ramification: An installed extension is running an older version that may be missing security patches and is not covered by the Supabase SLA.

Rationale

Keeping PostgreSQL extensions up to date is important for maintaining database security and stability. Extension developers regularly release updates that include:

• Security patches that fix known vulnerabilities
• Bug fixes that resolve functional issues
• Performance improvements that optimize database operations

Using outdated extension versions can expose your database to security risks and prevent you from benefiting from the latest improvements. Additionally, Supabase's Service Level Agreement (SLA) for issues resulting from extensions only applies to the default (recommended) version of each extension.

Why Keep Extensions Updated?

Security: Outdated extensions may contain known security vulnerabilities that have been patched in newer versions. These vulnerabilities could potentially be exploited by malicious actors.

Support: Supabase provides support and SLA coverage only for the default (recommended) versions of extensions. Running outdated versions may result in limited support options if issues arise.

Consistency: Maintaining consistent extension versions across all projects helps ensure predictable behavior and reduces compatibility issues.

Performance: Newer versions frequently include performance optimizations and improvements that can benefit your database operations.

Warning

• Always test extension updates in a development environment before applying them to production
• Some extension updates may include breaking changes, so review the extension's changelog before updating
• Back up your database before performing extension updates

How to Resolve

To update an extension to its default (recommended) version, use the ALTER EXTENSION command:

1
ALTER EXTENSION extension_name UPDATE;

For example, to update the uuid-ossp extension:

First, check the version of the extension that is installed:

1
-- Check current extension version
2
SELECT name, installed_version, default_version
3
FROM pg_catalog.pg_available_extensions
4
WHERE name = 'uuid-ossp';

This could return:

1
name     | installed_version | default_version
2
-------------+-------------------+-----------------
3
 uuid-ossp   | 1.0               | 1.1

To update to the installed version:

1
ALTER EXTENSION "uuid-ossp" UPDATE;

After updating, verify the installed version matches default:

1
SELECT name, installed_version, default_version
2
FROM pg_catalog.pg_available_extensions
3
WHERE name = 'uuid-ossp';

Should now return:

1
name     | installed_version | default_version
2
-------------+-------------------+-----------------
3
 uuid-ossp   | 1.1               | 1.1

Level: ERROR

Summary: Sensitive data publicly accessible

Ramification: A table with columns that likely contain sensitive data (like passwords or personal identifiers) is accessible through the API without any access restrictions.

Rationale

Tables exposed via the Supabase Data APIs that contain columns with potentially sensitive data (such as passwords, SSNs, credit card numbers, API keys, or other PII) pose a significant security risk when Row Level Security (RLS) is not enabled. Without RLS, anyone with access to the project's URL and an anonymous or authenticated role can read all data in these tables, potentially exposing sensitive user information.

This lint identifies tables that:

1. Are accessible via the Data API (in exposed schemas like public)
2. Have RLS disabled
3. Contain columns with names matching common sensitive data patterns

Sensitive Column Patterns Detected

The following categories of sensitive data are detected:

Authentication & Credentials:

• password, passwd, pwd, secret, api_key, token, jwt, access_token, refresh_token, session_token, auth_code, otp, 2fa_secret

Personal Identifiers:

• ssn, social_security, driver_license, passport_number, national_id, tax_id

Financial Information:

• credit_card, card_number, cvv, bank_account, account_number, routing_number, iban, swift_code

Health & Medical:

• health_record, medical_record, patient_id, insurance_number, diagnosis

Device & Digital Identifiers:

• mac_address, imei, device_uuid, ssh_key, pgp_key, certificate

Biometric Data:

• fingerprint, biometric, facial_recognition

How to Resolve

Option 1: Enable Row Level Security (Recommended)

Enable RLS on the table and create appropriate policies:

1
-- Enable RLS
2
alter table <schema>.<table> enable row level security;
3
4
-- Create a policy that restricts access
5
create policy "Users can only view their own data"
6
on <schema>.<table>
7
for select
8
using (auth.uid() = user_id);

Option 2: Remove sensitive columns from the table

If the data doesn't need to be stored, remove the sensitive columns:

1
alter table <schema>.<table> drop column <sensitive_column>;

Option 3: Move sensitive data to a separate, protected table

Store sensitive data in a separate table with proper RLS:

1
-- Create a protected table for sensitive data
2
create table <schema>.<table>_secure (
3
    id uuid primary key references <schema>.<table>(id),
4
    <sensitive_column> text
5
);
6
7
-- Enable RLS on the secure table
8
alter table <schema>.<table>_secure enable row level security;
9
10
-- Remove from the exposed table
11
alter table <schema>.<table> drop column <sensitive_column>;

Option 4: Remove the schema from API exposure

If the table should not be accessible via APIs at all, remove the schema from the Exposed schemas in API settings.

Example

Given the schema:

1
create table public.users(
2
    id uuid primary key,
3
    email text not null,
4
    password_hash text not null,
5
    ssn text,
6
    created_at timestamptz default now()
7
);
8
9
grant select on public.users to anon, authenticated;

This table is flagged because it contains sensitive columns (password_hash, ssn) and is accessible via the API without RLS protection. Any user with the project URL can query this table and retrieve all user passwords and social security numbers.

To fix, enable RLS and create appropriate policies:

1
alter table public.users enable row level security;
2
3
-- Allow users to only read their own data
4
create policy "Users can view own profile"
5
on public.users
6
for select
7
using (auth.uid() = id);

Level: WARN

Summary: Security policy allows unrestricted access

Ramification: An RLS policy uses an always-true condition like USING (true), which defeats the purpose of having Row-Level Security enabled.

Rationale

Row Level Security (RLS) policies that use always-true expressions like USING (true) or WITH CHECK (true) effectively bypass the security that RLS is meant to provide. While RLS appears to be enabled on the table, these permissive policies allow unrestricted access to all rows for the specified roles.

This is a common misconfiguration that occurs when:

• Developers create placeholder policies during development and forget to update them
• Policies are incorrectly configured with the assumption that other policies will restrict access
• Copy-paste errors from documentation examples

Patterns Detected

The lint identifies policies with these always-true patterns:

USING Clause (controls which rows can be read):

• USING (true) - explicitly allows reading all rows
• USING (1=1) - tautology that always evaluates to true
• USING ('a'='a') - string comparison tautology
• Missing USING clause on permissive SELECT policies

WITH CHECK Clause (controls which rows can be written):

• WITH CHECK (true) - allows writing any row
• WITH CHECK (1=1) - tautology that always evaluates to true
• Missing WITH CHECK clause on permissive INSERT/UPDATE policies

Security Impact

When a permissive policy with USING (true) exists:

• For SELECT: Any user with the specified role can read ALL rows in the table
• For INSERT: Any user can insert ANY data into the table
• For UPDATE: Any user can modify ANY row in the table
• For DELETE: Any user can delete ANY row from the table

This is particularly dangerous when the policy applies to anon or authenticated roles, as it exposes data to all API users.

How to Resolve

Option 1: Add proper row-level conditions

Replace the permissive policy with one that properly restricts access:

1
-- Instead of: USING (true)
2
-- Use a proper condition:
3
drop policy "allow_all" on public.posts;
4
5
create policy "users_own_posts"
6
on public.posts
7
for select
8
using (auth.uid() = user_id);

Option 2: Use restrictive policies in combination

If you need a base permissive policy, combine it with restrictive policies:

1
-- Base permissive policy
2
create policy "authenticated_access"
3
on public.posts
4
for select
5
to authenticated
6
using (true);
7
8
-- Restrictive policy to limit access
9
create policy "only_published"
10
on public.posts
11
as restrictive
12
for select
13
to authenticated
14
using (status = 'published' or auth.uid() = user_id);

Option 3: Remove the policy if RLS is not needed

If you don't need row-level restrictions, consider whether RLS should be disabled:

1
drop policy "allow_all" on public.posts;
2
alter table public.posts disable row level security;

Note: Only disable RLS if you're certain the table should be fully accessible.

Example

Given this problematic configuration:

1
create table public.user_data(
2
    id uuid primary key,
3
    user_id uuid references auth.users(id),
4
    sensitive_info text
5
);
6
7
alter table public.user_data enable row level security;
8
9
-- This policy defeats the purpose of RLS!
10
create policy "allow_all_select"
11
on public.user_data
12
for select
13
to authenticated
14
using (true);

The allow_all_select policy allows ANY authenticated user to read ALL rows, including other users' sensitive information.

Fix by adding a proper condition:

1
drop policy "allow_all_select" on public.user_data;
2
3
create policy "users_own_data"
4
on public.user_data
5
for select
6
to authenticated
7
using (auth.uid() = user_id);

False Positives

In some cases, USING (true) may be intentional:

• Public read-only tables (e.g., blog posts, product catalogs)
• Tables where access is controlled by other means (e.g., API layer)

If the policy is intentional, you can document why in a comment or consider suppressing this lint for specific tables.

Level: WARN

Summary: Detects public storage buckets whose broad SELECT policies on storage.objects make their contents listable.

Ramification: Clients can enumerate the files in a public bucket, which often exposes more information than intended even though public object URLs would still work without the policy.

Rationale

Supabase public buckets are already readable by URL. They do not need a SELECT policy on storage.objects for clients to fetch known object paths.

The footgun appears when a public bucket also has one or more broad permissive SELECT or ALL policies on storage.objects, for example bucket_id = 'avatars' or true. That combination allows API clients to list objects in the bucket through Storage APIs, which is often broader access than the project intended.

This lint is intentionally narrow. It does not warn on all public buckets. It only warns when a public bucket also has a matching SELECT policy that makes its contents enumerable.

How to Resolve

Option 1: Remove the unnecessary SELECT policy

1
drop policy if exists "Public bucket listing" on storage.objects;

Object URLs for the public bucket will continue to work after removing the SELECT policy.

Option 2: Make the bucket private if listing is actually required

1
update storage.buckets
2
set public = false
3
where id = 'avatars';

Use private bucket access patterns if the project truly needs authenticated listing behavior.

Example

Given this problematic configuration:

1
insert into storage.buckets (id, name, public)
2
values ('avatars', 'avatars', true);
3
4
create policy "Public bucket listing"
5
on storage.objects
6
for select
7
to authenticated
8
using (bucket_id = 'avatars');

Fix:

1
drop policy if exists "Public bucket listing" on storage.objects;

False Positives

This lint may fire when broad bucket listing is intentional for a public bucket. In that case, keep the policy and handle the warning as an accepted risk.

The lint is also intentionally conservative. It detects broad permissive policies for the public, anon, or authenticated roles with direct bucket-only bucket_id = '<bucket id>' matches or always-true policy expressions such as true or 1 = 1. It does not warn on restrictive-only policies or policies that add additional object, path, or user constraints such as bucket_id = 'avatars' and owner = auth.uid().

Level: WARN

Summary: This object is visible in your GraphQL schema to anyone using the public anon key.

Ramification: If anon can SELECT any column on a table, view, materialized view, or foreign table, pg_graphql exposes that object's name, columns, relationships, and generated mutations through /graphql/v1 introspection. RLS does not change that because it protects rows, not schema visibility. If this object should not be discoverable before sign-in, revoke SELECT from anon or disable pg_graphql if you do not use GraphQL.

See also: lint 0027_pg_graphql_authenticated_table_exposed. In default Supabase projects anon and authenticated start with identical default-privilege grants, so revoking from anon alone often leaves the same introspection response served to any signed-up user. Address findings from both lints together.

If you are not using pg_graphql, disable it

The simplest mitigation — and the right one if your app does not use the GraphQL endpoint — is to drop the extension. With pg_graphql not installed, this lint and 0027 stop firing entirely and the /graphql/v1 endpoint returns nothing exposing your schema.

In the Supabase SQL Editor:

1
drop extension pg_graphql;

Or in the dashboard: Database → Extensions, search for pg_graphql, and toggle it off.

If your project does use pg_graphql, leave it installed and follow the remediation below.

Rationale

pg_graphql introspection is by design: the GraphQL schema reflects the Postgres privileges of the calling role. The Supabase anon key maps to the anon Postgres role, so any relation anon can SELECT is visible in the GraphQL introspection response from /graphql/v1, regardless of RLS. Visibility through introspection is governed entirely by GRANT / REVOKE. This lint flags the objects currently discoverable through the public anon key so you can confirm each one is intentionally public.

The relkinds covered match pg_graphql's own filter (load_sql_context.sql:395-400): regular tables (r), views (v), materialized views (m), and foreign tables (f). Partitioned table roots (relkind='p') are not covered because pg_graphql does not expose them via introspection; their leaf partitions (relkind='r') are still picked up individually.

You can confirm what is visible using only the public anon key:

1
curl -X POST https://<PROJECT_REF>.supabase.co/graphql/v1 \
2
  -H 'apiKey: <ANON_KEY>' \
3
  -H 'Authorization: Bearer <ANON_KEY>' \
4
  -H 'Content-Type: application/json' \
5
  --data-raw '{"query": "{ __schema { types { name fields { name } } } }"}'

The response includes one entry per exposed table (e.g. internal_api_keysCollection, ordersCollection), the full column list for each table, and Mutation entries like insertIntointernal_api_keysCollection, updateinternal_api_keysCollection, deleteFrominternal_api_keysCollection.

How to Resolve

The fix is always a standard Postgres GRANT / REVOKE run in the SQL Editor. No support ticket, no config file, no extension toggle.

Important: revoking from anon does not, on its own, hide the relation from pg_graphql introspection — authenticated is checked separately by lint 0027 and typically has the same default grants. Address both lints' findings together (see "Hide all tables from both roles" in 0027).

Option 1: Hide every table from anon (most thorough)

1
revoke all on all tables in schema public from anon;

Then prevent future tables from auto-exposing:

1
alter default privileges in schema public
2
  revoke select on tables from anon;

Re-grant access to authenticated for tables your app needs after login:

1
grant select on public.profiles to authenticated;
2
grant select on public.products to authenticated;
3
grant select, insert on public.orders to authenticated;
4
-- Sensitive tables receive no grant from anon and remain invisible to
5
-- the public introspection endpoint. Make sure to also handle 0027 for
6
-- the authenticated-side exposure.