{"email":"test@exmaple.com","password":"SomeCOmplexPwd239."}

</details>

<details>

<summary>Вхід (/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>

Отже, коли ви виявляєте клієнта, який використовує supabase з піддоменом, що йому було надано (можливо, піддомен компанії має CNAME, спрямований на їхній піддомен supabase), ви можете спробувати **створити новий акаунт на платформі, використовуючи supabase API**.

### секретні / service_role api keys

Також буде згенеровано секретний API key з **`role: "service_role"`**. Цей API key має залишатися секретним, оскільки він дозволяє обходити **Row Level Security**.

The API key looks like this: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`

### JWT Secret

Також буде згенеровано **JWT Secret**, щоб додаток міг **створювати та підписувати кастомні JWT tokens**.

## Аутентифікація

### Реєстрація

<div class="mdbook-alerts mdbook-alerts-tip">
<p class="mdbook-alerts-title">
  <span class="mdbook-alerts-icon"></span>
  tip
</p>


За **замовчуванням** supabase дозволяє **новим користувачам створювати акаунти** у вашому проєкті, використовуючи вказані вище API endpoints.

</div>


Однак ці нові акаунти за замовчуванням **повинні підтвердити свою електронну пошту**, щоб мати змогу увійти в акаунт. Можна увімкнути опцію **"Allow anonymous sign-ins"**, щоб дозволити людям входити без підтвердження email. Це може надати доступ до **неочікуваних даних** (вони отримують ролі `public` та `authenticated`).\
Це дуже погана ідея, оскільки supabase стягує плату за активного користувача, тож люди можуть створювати користувачів і заходити в систему, а supabase буде стягувати за них плату:

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

#### Auth: Server-side signup enforcement

Приховування кнопки реєстрації на фронтенді недостатньо. Якщо **Auth сервер все ще дозволяє реєстрацію**, зловмисник може викликати API напряму з використанням публічного `anon` ключа і створити довільних користувачів.

Швидкий тест (з неавторизованого клієнта):
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">bash</span></div>

```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

Expected hardening:

• Disable email/password signups in the Dashboard: Authentication → Providers → Email → Disable sign ups (invite-only), or set the equivalent GoTrue setting.
• Перевірте, що API тепер повертає 4xx на попередній виклик і новий користувач не створюється.
• Якщо ви покладаєтесь на invites або SSO, переконайтесь, що всі інші провайдери вимкнені, якщо вони явно не потрібні.

RLS and Views: Write bypass via PostgREST

Використання Postgres VIEW для «приховування» чутливих стовпців і експонування його через PostgREST може змінити спосіб оцінки привілеїв. У PostgreSQL:

• Ordinary views execute with the privileges of the view owner by default (definer semantics). In PG ≥15 you can opt into security_invoker.
• Row Level Security (RLS) applies on base tables. Table owners bypass RLS unless FORCE ROW LEVEL SECURITY is set on the table.
• Updatable views can accept INSERT/UPDATE/DELETE that are then applied to the base table. Without WITH CHECK OPTION, writes that don’t match the view predicate may still succeed.

Risk pattern observed in the wild:

• A reduced-column view is exposed through Supabase REST and granted to anon/authenticated.
• PostgREST allows DML on the updatable view and the operation is evaluated with the view owner’s privileges, effectively bypassing the intended RLS policies on the base table.
• Result: low-privileged clients can mass-edit rows (e.g., profile bios/avatars) they should not be able to modify.

Illustrative write via view (attempted from a public client):

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:

• Віддавайте перевагу експонуванню базових таблиць з явними наданнями найменших привілеїв і точними RLS-політиками.
• Якщо потрібно експонувати представлення:
• Зробіть його неоновлюваним (наприклад, включіть вирази/joins) або забороніть INSERT/UPDATE/DELETE на представленні для всіх ненадійних ролей.
• Забезпечте виконання ALTER VIEW <v> SET (security_invoker = on) — щоб використовувалися привілеї того, хто викликає (invoker), замість привілеїв власника.
• Для базових таблиць використовуйте ALTER TABLE <t> FORCE ROW LEVEL SECURITY; — щоб навіть власники підлягали RLS.
• Якщо дозволяєте запис через updatable view, додайте WITH [LOCAL|CASCADED] CHECK OPTION і доповнювальні RLS на базових таблицях, щоб гарантувати, що записуються/змінюються лише дозволені рядки.
• В Supabase уникайте надання anon/authenticated будь-яких прав на запис у представлення, якщо ви не перевірили end-to-end поведінку за допомогою тестів.

Detection tip:

• Від імені anon та тестового користувача authenticated спробуйте виконати всі CRUD-операції проти кожної відкритої таблиці/представлення. Будь-який успішний запис у місці, де ви очікували відмови, свідчить про неправильну конфігурацію.

OpenAPI-driven CRUD probing from anon/auth roles

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[]'

Шаблон перевірки (приклади):

• Прочитати один рядок (очікується 401/403/200 залежно від 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>"

• Перевірте, що UPDATE заблоковано (використовуйте неіснуючий filter, щоб уникнути зміни даних під час тестування):

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"

• Тест INSERT заблоковано:

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>"

• Перевірте, що DELETE заблоковано:

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"

Рекомендації:

• Автоматизуйте попередні перевірки для обох anon та мінімально authenticated користувачів і інтегруйте їх у CI, щоб виявляти регресії.
• Розглядайте кожну відкриту table/view/function як первинну поверхню. Не припускайте, що view «успадковує» ту ж RLS політику, що й її базові таблиці.

Паролі та сесії

Можна вказати мінімальну довжину пароля (за замовчуванням), вимоги (за замовчуванням відсутні) та заборонити використання leaked passwords.
Рекомендується покращити вимоги, оскільки значення за замовчуванням слабкі.

• User Sessions: Можна налаштувати, як працюють сесії користувачів (таймаути, 1 сесія на користувача...)
• Bot and Abuse Protection: Можна увімкнути Captcha.

SMTP Settings

Можна вказати SMTP для відправки листів.

Advanced Settings

• Set expire time to access tokens (3600 by default)
• Set to detect and revoke potentially compromised refresh tokens and timeout
• MFA: Вказати, скільки MFA факторів може бути зареєстровано одночасно для одного користувача (за замовчуванням 10)
• Max Direct Database Connections: Максимальна кількість з'єднань, що використовуються для auth (за замовчуванням 10)
• Max Request Duration: Максимальний час для Auth request (за замовчуванням 10s)

Storage

• Встановіть обмеження на розмір файлу для завантаження (за замовчуванням 50MB)
• The S3 connection is given with a URL like: https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3
• Можна запитати S3 access key які складаються з access key ID (e.g. a37d96544d82ba90057e0e06131d0a7b) та secret access key (e.g. 58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628)

Edge Functions

У Supabase також можна зберігати secrets, які будуть доступні by edge functions (їх можна створювати та видаляти з веба, але неможливо безпосередньо прочитати їх значення).

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