# Supabase Security

{{#include ../banners/hacktricks-training.md}}

## Basic Information

As per their [**landing page**](https://supabase.com/): Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings.

### Subdomain

Gdy projekt zostanie utworzony, użytkownik otrzyma subdomenę supabase.co, np.: **`jnanozjdybtpqgcwhdiz.supabase.co`**

## **Database configuration**

> [!TIP]
> **This data can be accessed from a link like `https://supabase.com/dashboard/project/<project-id>/settings/database`**

Ta **baza danych** zostanie wdrożona w którymś regionie AWS, a żeby połączyć się z nią można użyć: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (ta została utworzona w us-west-1).  
Hasło to **hasło ustawione wcześniej przez użytkownika**.

Dlatego, ponieważ subdomena jest znana i jest używana jako username, a regiony AWS są ograniczone, może być możliwe próbowanie **brute force the password**.

Ta sekcja zawiera również opcje:

- Reset the database password
- Configure connection pooling
- Configure SSL: Reject plain-text connections (by default they are enabled)
- Configure Disk size
- Apply network restrictions and bans

## API Configuration

> [!TIP]
> **This data can be accessed from a link like `https://supabase.com/dashboard/project/<project-id>/settings/api`**

URL do dostępu do supabase API w Twoim projekcie będzie wyglądał tak: `https://jnanozjdybtpqgcwhdiz.supabase.co`.

### anon api keys

Wygeneruje też **anon API key** (`role: "anon"`), np.: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`, którego aplikacja będzie musiała użyć, aby komunikować się z API.

It's possible to find the API REST to contact this API in the [**docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), but the most interesting endpoints would be:

<details>

<summary>Signup (/auth/v1/signup)</summary>
```
POST /auth/v1/signup HTTP/2
Host: id.io.net
Content-Length: 90
X-Client-Info: supabase-js-web/2.39.2
Sec-Ch-Ua: "Not-A.Brand";v="99", "Chromium";v="124"
Sec-Ch-Ua-Mobile: ?0
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.60 Safari/537.36
Content-Type: application/json;charset=UTF-8
Apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk
Sec-Ch-Ua-Platform: "macOS"
Accept: */*
Origin: https://cloud.io.net
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://cloud.io.net/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Priority: u=1, i

{"email":"test@exmaple.com","password":"SomeCOmplexPwd239."}
```
</details>

<details>

<summary>Logowanie (/auth/v1/token?grant_type=password)</summary>
```
POST /auth/v1/token?grant_type=password HTTP/2
Host: hypzbtgspjkludjcnjxl.supabase.co
Content-Length: 80
X-Client-Info: supabase-js-web/2.39.2
Sec-Ch-Ua: "Not-A.Brand";v="99", "Chromium";v="124"
Sec-Ch-Ua-Mobile: ?0
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.60 Safari/537.36
Content-Type: application/json;charset=UTF-8
Apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk
Sec-Ch-Ua-Platform: "macOS"
Accept: */*
Origin: https://cloud.io.net
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://cloud.io.net/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Priority: u=1, i

{"email":"test@exmaple.com","password":"SomeCOmplexPwd239."}
```
</details>

Więc za każdym razem, gdy odkryjesz klienta korzystającego z supabase z przydzielonym subdomeną (możliwe, że subdomena firmy ma CNAME wskazujący na ich subdomenę supabase), możesz spróbować **utworzyć nowe konto na platformie używając supabase API**.

### secret / service_role api keys

Zostanie również wygenerowany sekretne klucz API z **`role: "service_role"`**. Ten klucz API powinien być tajny, ponieważ będzie mógł omijać **Row Level Security**.

Klucz API wygląda tak: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`

### JWT Secret

Zostanie też wygenerowany **JWT Secret**, aby aplikacja mogła **tworzyć i podpisywać niestandardowe tokeny JWT**.

## Authentication

### Signups

> [!TIP]
> Domyślnie supabase pozwala **nowym użytkownikom tworzyć konta** w Twoim projekcie, używając wcześniej wspomnianych endpointów API.

Jednak te nowe konta, domyślnie, **będą musiały zweryfikować swój adres e-mail**, aby móc się zalogować do konta. Możliwe jest włączenie **"Allow anonymous sign-ins"**, aby pozwolić ludziom logować się bez weryfikacji adresu e-mail. To może dać dostęp do **nieoczekiwanych danych** (otrzymują role `public` i `authenticated`).\
To bardzo zły pomysł, ponieważ supabase nalicza opłaty za aktywnego użytkownika, więc ludzie mogliby tworzyć użytkowników i logować się, a supabase będzie za to naliczać opłaty:

<figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

#### Auth: Server-side signup enforcement

Ukrycie przycisku rejestracji w frontendzie to za mało. Jeśli **Auth server nadal pozwala na rejestracje**, atakujący może wywołać API bezpośrednio używając publicznego klucza `anon` i utworzyć dowolnych użytkowników.

Szybki test (z nieuwierzytelnionego klienta):
```bash
curl -X POST \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-d '{"email":"attacker@example.com","password":"Sup3rStr0ng!"}' \
https://<PROJECT_REF>.supabase.co/auth/v1/signup
```
Zalecane zabezpieczenia:
- Wyłącz rejestracje email/hasło w Dashboard: Authentication → Providers → Email → Disable sign ups (invite-only), lub ustaw równoważne ustawienie GoTrue.
- Zweryfikuj, że API teraz zwraca 4xx dla poprzedniego wywołania i żaden nowy użytkownik nie zostaje utworzony.
- Jeśli korzystasz z zaproszeń lub SSO, upewnij się, że wszystkie pozostałe providery są wyłączone, chyba że są wyraźnie potrzebne.

## RLS and Views: Write bypass via PostgREST

Użycie Postgres VIEW do „ukrycia” wrażliwych kolumn i udostępnienie go przez PostgREST może zmienić sposób oceniania uprawnień. W PostgreSQL:
- Zwykłe widoki wykonują się z uprawnieniami właściciela widoku domyślnie (definer semantics). W PG ≥15 możesz wybrać `security_invoker`.
- Row Level Security (RLS) ma zastosowanie do tabel bazowych. Właściciele tabel omijają RLS, chyba że na tabeli ustawiono `FORCE ROW LEVEL SECURITY`.
- Widoki aktualizowalne mogą przyjmować INSERT/UPDATE/DELETE, które następnie są stosowane do tabeli bazowej. Bez `WITH CHECK OPTION` zapisy, które nie pasują do predykatu widoku, nadal mogą zakończyć się sukcesem.

Obserwowany wzorzec ryzyka:
- Widok z ograniczoną liczbą kolumn jest udostępniony przez Supabase REST i przydzielony `anon`/`authenticated`.
- PostgREST pozwala na DML na aktualizowalnym widoku, a operacja jest oceniana z uprawnieniami właściciela widoku, skutecznie omijając zamierzone polityki RLS na tabeli bazowej.
- Skutek: klienci o niskich uprawnieniach mogą masowo edytować wiersze (np. bio/awatar profilu), których nie powinni móc modyfikować.

Ilustracyjny zapis przez widok (próba z publicznego klienta):
```bash
curl -X PATCH \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=representation" \
-d '{"bio":"pwned","avatar_url":"https://i.example/pwn.png"}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/users_view?id=eq.<victim_user_id>"
```
Hardening checklist for views and RLS:
- Prefer exposing base tables with explicit, least-privilege grants and precise RLS policies.
- If you must expose a view:
- Make it non-updatable (e.g., include expressions/joins) or deny `INSERT/UPDATE/DELETE` on the view to all untrusted roles.
- Enforce `ALTER VIEW <v> SET (security_invoker = on)` so the invoker’s privileges are used instead of the owner’s.
- On base tables, use `ALTER TABLE <t> FORCE ROW LEVEL SECURITY;` so even owners are subject to RLS.
- If allowing writes via an updatable view, add `WITH [LOCAL|CASCADED] CHECK OPTION` and complementary RLS on base tables to ensure only allowed rows can be written/changed.
- In Supabase, avoid granting `anon`/`authenticated` any write privileges on views unless you have verified end-to-end behavior with tests.

Detection tip:
- From `anon` and an `authenticated` test user, attempt all CRUD operations against every exposed table/view. Any successful write where you expected denial indicates a misconfiguration.

### Sondowanie CRUD oparte na OpenAPI z ról anon/auth

PostgREST exposes an OpenAPI document that you can use to enumerate all REST resources, then automatically probe allowed operations from low-privileged roles.

Fetch the OpenAPI (works with the public anon key):
```bash
curl -s https://<PROJECT_REF>.supabase.co/rest/v1/ \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Accept: application/openapi+json" | jq '.paths | keys[]'
```
Wzorzec sondowania (przykłady):
- Odczytaj pojedynczy wiersz (oczekuj 401/403/200 w zależności od RLS):
```bash
curl -s "https://<PROJECT_REF>.supabase.co/rest/v1/<table>?select=*&limit=1" \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>"
```
- Test UPDATE jest zablokowany (użyj nieistniejącego filtra, aby uniknąć modyfikacji danych podczas testów):
```bash
curl -i -X PATCH \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=minimal" \
-d '{"__probe":true}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"
```
- Sprawdź, czy INSERT jest zablokowany:
```bash
curl -i -X POST \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=minimal" \
-d '{"__probe":true}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>"
```
- Sprawdź, że DELETE jest zablokowany:
```bash
curl -i -X DELETE \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"
```
Zalecenia:
- Zautomatyzuj poprzednie sondy zarówno dla `anon`, jak i minimalnie `authenticated` użytkownika i zintegruj je z CI, aby wychwycić regresje.
- Traktuj każdą wystawioną table/view/function jako pełnoprawną powierzchnię. Nie zakładaj, że view „dziedziczy” tę samą postawę RLS co jej bazowe tabele.

### Hasła i sesje

Można określić minimalną długość hasła (domyślnie), wymagania (domyślnie brak) oraz zabronić używania leaked passwords.\
Zaleca się **zaostrzyć wymagania, ponieważ domyślne są słabe**.

- User Sessions: Można skonfigurować sposób działania sesji użytkownika (timeouts, 1 sesja na użytkownika...)
- Bot and Abuse Protection: Można włączyć Captcha.

### Ustawienia SMTP

Można skonfigurować SMTP do wysyłania e-maili.

### Ustawienia zaawansowane

- Ustaw czas wygaśnięcia access tokenów (domyślnie 3600)
- Skonfiguruj wykrywanie i unieważnianie potencjalnie kompromitowanych refresh tokenów oraz timeout
- MFA: Określ, ile czynników MFA może być zarejestrowanych jednocześnie na użytkownika (domyślnie 10)
- Max Direct Database Connections: Maksymalna liczba połączeń używanych do auth (domyślnie 10)
- Max Request Duration: Maksymalny czas trwania żądania Auth (domyślnie 10s)

## Storage

> [!TIP]
> Supabase pozwala **przechowywać pliki** i udostępniać je przez URL (używa S3 buckets).

- Ustaw limit rozmiaru przesyłanych plików (domyślnie 50MB)
- The S3 connection is given with a URL like: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
- Można **zażądać S3 access key** które składają się z `access key ID` (np. `a37d96544d82ba90057e0e06131d0a7b`) oraz `secret access key` (np. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)

## Edge Functions

W supabase można również **przechowywać secrets**, które będą **dostępne dla edge functions** (można je tworzyć i usuwać z poziomu web, ale nie można bezpośrednio odczytać ich wartości).

## References

- [Building Hacker Communities: Bug Bounty Village, getDisclosed’s Supabase Misconfig, and the LHE Squad (Ep. 133) – YouTube](https://youtu.be/NI-eXMlXma4)
- [Critical Thinking Podcast – Episode 133 page](https://www.criticalthinkingpodcast.io/episode-133-building-hacker-communities-bug-bounty-village-getdisclosed-and-the-lhe-squad/)
- [Supabase: Row Level Security (RLS)](https://supabase.com/docs/guides/auth/row-level-security)
- [PostgreSQL: Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)
- [PostgreSQL: CREATE VIEW (security_invoker, check option)](https://www.postgresql.org/docs/current/sql-createview.html)
- [PostgREST: OpenAPI documentation](https://postgrest.org/en/stable/references/api.html#openapi-documentation)

{{#include ../banners/hacktricks-training.md}}