Breaking Change: Removing access to OpenAPI spec via the anon key

[inian]

What’s Changing?

The Data API returns the full OpenAPI spec for any schema exposed to the Data API at the root path: https://[projectref].supabase.co/rest/v1/

Starting March 11, we will begin deprecating support for accessing this endpoint via the anon key. You will get the following error message if this endpoint is accessed via the anon key

{"message":"Access to schema is forbidden","hint":"Accessing the schema via the Data API is only allowed using a secret API key."}

The endpoint remains accessible and the behaviour doesn't change if you are using the service role keys or the new secret API keys.

This does not affect normal Data API usage. Accessing data via /rest/v1/your_table or any client library will continue to work exactly as they do today.

Why?

Today, the endpoint returns schema details (tables, columns, and types of an exposed schema) to anyone with the anon key. While this does not expose actual row data, it provides more information about your schema than most production applications need.

As part of an ongoing effort to tighten default security across Supabase, we are removing this exposure. In practice, the schema spec is mostly useful during development, where you can use the service_role key. There are few cases where you would need it client-side in production (less than 0.1% of our projects have made a request to this endpoint using the anon key in the last 24 hours), and we do not think supporting those use cases is worth the security tradeoff.

Am I Affected?

You are affected if your app currently uses the anon key to fetch the Swagger spec.

You can check by reviewing requests to the /rest/v1/ endpoint via this log query.

If you see requests:

1. Click into the event.
2. Check whether the request is coming from the anon role.

What Should I Do?

1. Check your logs. Use the log query above to see if any of your application traffic relies on this endpoint with the anon key.
2. Move affected calls server-side If your application fetches the schema spec, move that call to a server-side context like Edge Functions where you can safely use the service_role or the new secret API keys.

Rollout and Communications Timeline

Date	Change
17 Feb	Changelog published
4 March	Change announced in monthly newsletter
6 March	Email notification to customers observed using this endpoint
11 March	Newly created projects cannot access endpoint with anon key
24 March	Final email notification to customers observed using this endpoint
8 April	All existing projects cannot access endpoint with anon key

We may push these dates back based on customer feedback, but we will not move them forward.

What’s Next?

This is the first in a series of changes we are making to tighten default security settings across Supabase. Stay tuned for improvements to RLS usability, default table grants, and additional security features.

Update 23.03.2026

We now have a new Management API endpoint for the CLI and third party integration that only requires the "Read-only project database access" permission. Details are here.

[wysohn]

@inian

Hello,

First, thank you for working on the security tightening.

I have a few concerns:

1. The link in the document (https://supabase.com/dashboard/project/_/logs/edge-logs?s=/rest/v1/+) appears to include a trailing +. As written, it does not return any results, but removing the trailing + shows the requests correctly. Is this intentional? It may confuse other users if left as is.

2. It is also unclear how the log should be interpreted when determining whether the anon key is being used. In some requests there is an sb section with apikey where the role is anon, while the authorization section indicates the role is authenticated. It is therefore unclear whether the request is actually using the anon role or an authenticated role. Clarification on how these fields should be interpreted would be helpful.

3. Please provide an option to opt in to this restriction before April 8. I am not comfortable relying on “there should be no issue anymore” without being able to verify it in advance. Currently there does not appear to be an easy way to test this unless a sandbox environment is provided beforehand. We already maintain a separate project for testing, so an early opt-in would allow us to validate this in a controlled manner.

Without such an option, introducing and enforcing a new policy like this with only about a month of lead time feels like a fairly radical change.

Best,
Wooyoung Son

[wysohn]

Hi @wysohn The "Disable JWT based API keys" is not a one way function - it is possible to re-enable. As you say, the best approach would be to test this in a non-production environment, this can be either a completely separate supabase project, or a branch of your production project

Oh we can actually enable it back again! Then that would be the perfect one. Yes, I was assuming it would be a one way function where we can't no longer revert back once applied. Thank you for the clarification

[wysohn]

@doublethink

Sorry for bothering you again, but there is another edge case that makes testing harder for us.

If we use “Disable JWT based API keys”, both the legacy anon key and the legacy service_role key are disabled at the same time.

The issue is that some of our backend services that access Supabase still use the legacy service_role key. Disabling it would cause those backend functions to fail as well.

That is technically acceptable, at least in testing environment, but it is not the ideal setup for testing our migration. What we want to validate is whether any public facing usage is still depending on the legacy anon key, without also breaking backend services that still rely on the legacy service_role key.

Would it be possible to enable or disable the legacy anon key and legacy service_role key separately?

The best option for us would be to disable only the legacy anon key while keeping the legacy service_role key active, so we can test this in a more controlled manner.

Best,
Wooyoung Son

[doublethink]

@wysohn a couple of things:

I was mistaken and the trailing + was intentional. This change only affects /rest/v1/ not /rest/v1/table_names.

There is no way to disable the legacy anon key without also disabling the service_role key.
You may be better off looking at your logs for this. Using the log search in the initial post you can check what type of apikey any requests against that endpoint were using.

[wysohn]

@wysohn a couple of things:

I was mistaken and the trailing + was intentional. This change only affects /rest/v1/ not /rest/v1/table_names.

There is no way to disable the legacy anon key without also disabling the service_role key. You may be better off looking at your logs for this. Using the log search in the initial post you can check what type of apikey any requests against that endpoint were using.

Thank you for the clarification!

And indeed, if + was intentional, I do not get any result, meaning am I good to assume nothing will break?

[doublethink]

@wysohn yes you should be good to go. just be aware the default log filter is a couple hours so extend this to search more of your logs.
Even if you do find requests to this endpoint, its worth looking at the user agent header to ensure it is actually your app and not something else

[erik-beus]

@inian we run a service where users can connect their Supabase project (so we can read the OpenAPI spec + perform a GraphQL introspection query) in order to help them build up their API calls.
From what I understand, our current process will no longer work since the OpenAPI spec now requires a service role. In order to still support this feature for our users, I setup a Supabase OAuth app that would allow us to request it server side as instructed above.
My findings so far:

• After authenticating the user, I can read the OpenAPI spec using a legacy service role key that I can read server side
• I am not able to read the value of any existing secret keys in Supabase from my server
• If I create a new secret key in Supabase from my server, I am not able to read the actual value of the secret key from the response

While I do understand some of the arguments for this change, it would be nice if there was a way for a user to expose their OpenAPI spec to an authenticated OAuth app. Without using service role keys, that does not seem to be possible atm though?

[doublethink]

Assuming that the Typescript types is insufficient for your needs, you are right we have no equivalent for a read only role.
With database write you can obviously use pgmeta to query the schema, but we don't want this change to inadvertantly encourage requiring more privileges for integrations.
This would require a new API endpoint, I will discuss with the team about creating one.

[cullophid]

If the aim is to increase security, then this would be a step in the right direction. That way the service role key does not get passed around as requently. 👍

[doublethink]

I have a /v1/projects/$REF/database/openapi endpoint currently going through approvals and testing. It requires database.read permissions and is a drop-in replacement for /rest/v1/ including different schemas.
Should be live in production very soon.

[erik-beus]

That sounds like a good solution that will ensure we can reduce the scope of our integration as much as possible 🙌
Thank you 😊

[doublethink]

Hi All, update a quick update that the endpoint is now live

[uhudo]

@inian The email to customers using the endpoint that went out today seems to include the link to the query without the trailing +.
Could you confirm that only requests that are shown under https://supabase.com/dashboard/project/_/logs/edge-logs?s=/rest/v1/+ are affected?

[doublethink]

@uhudo yes confirming that the + is intentional.
This change only affects /rest/v1/ strictly, your /rest/v1/table_name requests will be unaffected.

If you received an email from us you would have received a request to that endpoint in the last seven days - but if you aren't seeing it in your logs as a matter of course over a day, it may be safe to say your app doesn't depend on it.