{“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):

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):

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):

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):

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:

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:

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
• Critical Thinking Podcast – Episode 133 page
• Supabase: Row Level Security (RLS)
• PostgreSQL: Row Security Policies
• PostgreSQL: CREATE VIEW (security_invoker, check option)
• PostgREST: OpenAPI documentation

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.