Securing your API

The data APIs are designed to work with Postgres Row Level Security (RLS). If you use Supabase Auth, you can restrict data based on the logged-in user.

To control access to your data, you can use Policies.

Enabling row level security#

Any table you create in the public schema will be accessible via the Supabase Data API.

To restrict access, enable Row Level Security (RLS) on all tables, views, and functions in the public schema. You can then write RLS policies to grant users access to specific database rows or functions based on their authentication token.

Any table created through the Supabase Dashboard will have RLS enabled by default. If you created the tables via the SQL editor or via another way, enable RLS like so:

With RLS enabled, you can create Policies that allow or disallow users to access and update data. We provide a detailed guide for creating Row Level Security Policies in our Authorization documentation.

Safeguards towards accidental deletes and updates#

By default, all projects have the safeupdate Postgres extension enabled for API queries. This ensures that delete() and update() requests will fail if there are no filters provided.

To confirm that safeupdate is enabled for API queries, run the following query:

The expected value for useconfig should be:

Enforce additional rules on each request#

Using Row Level Security policies may not always be adequate or sufficient to protect APIs.

Here are some common situations where additional protections are necessary:

• Enforcing per-IP or per-user rate limits.
• Checking custom or additional API keys before allowing further access.
• Rejecting requests after exceeding a quota or requiring payment.
• Disallowing direct access to certain tables, views or functions in the public schema.

You can build these cases in your application by creating a Postgres function that will read information from the request and perform additional checks, such as counting the number of requests received or checking that an API key is already registered in your database before serving the response.

Define a function like so:

And register it to run on every Data API request using:

This configures the public.check_request function to run on every Data API request. To have the changes take effect, you should run:

Inside the function you can perform any additional checks on the request headers or JWT and raise an exception to prevent the request from completing. For example, this exception raises a HTTP 402 Payment Required response with a hint and additional X-Powered-By header:

When raised within the public.check_request function, the resulting HTTP response will look like:

Use the JSON operator functions to build rich and dynamic responses from exceptions.

If you use a custom HTTP status code like 419, you can supply the status_text key in the detail clause of the exception to describe the HTTP status.

If you're using PostgREST version 11 or lower (find out your PostgREST version) a different and less powerful syntax needs to be used.

Accessing request information#

Like with RLS policies, you can access information about the request by using the current_setting() Postgres function. Here are some examples on how this works:

To access the IP address of the client look up the X-Forwarded-For header in the request.headers setting. For example:

Read more about PostgREST's pre-request function.

Examples#