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

</details>

<details>

<summary>Entrar (/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>

Então, sempre que você descobrir um cliente usando supabase com o subdomínio que lhe foi concedido (é possível que um subdomínio da empresa tenha um CNAME sobre o subdomínio supabase deles), você pode tentar **criar uma nova conta na plataforma usando a API do supabase**.

### secret / service_role api keys

Uma chave API secreta também será gerada com **`role: "service_role"`**. Essa chave API deve ser mantida em segredo porque será capaz de contornar o **Row Level Security**.

A chave API se parece com isto: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`

### JWT Secret

Um **Segredo JWT** também será gerado para que a aplicação possa **criar e assinar tokens JWT personalizados**.

## Authentication

### Signups

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


Por **padrão** o supabase permitirá que **novos usuários criem contas** no seu projeto usando os endpoints de API mencionados anteriormente.

</div>


No entanto, essas novas contas, por padrão, **precisarão validar seu endereço de email** para conseguir fazer login na conta. É possível habilitar **"Allow anonymous sign-ins"** para permitir que pessoas façam login sem verificar seu email. Isso pode conceder acesso a **dados inesperados** (eles recebem os papéis `public` e `authenticated`).\
Isso é uma péssima ideia porque o supabase cobra por usuário ativo, então pessoas poderiam criar usuários e fazer login e o supabase cobraria por esses:

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

#### Auth: Server-side signup enforcement

Esconder o botão de cadastro no frontend não é suficiente. Se o **Auth server ainda permite signups**, um atacante pode chamar a API diretamente com a `anon` key pública e criar usuários arbitrários.

Teste rápido (a partir de um cliente não autenticado):
<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

Endurecimento esperado:

• Desative cadastros por email/senha no Dashboard: Authentication → Providers → Email → Disable sign ups (invite-only), ou defina a configuração equivalente do GoTrue.
• Verifique que a API agora retorna 4xx para a chamada anterior e que nenhum novo usuário é criado.
• Se você depende de invites ou SSO, garanta que todos os outros providers estejam desativados, a menos que sejam explicitamente necessários.

RLS and Views: Write bypass via PostgREST

Using a Postgres VIEW to “hide” sensitive columns and exposing it via PostgREST can change how privileges are evaluated. In 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.

Padrão de risco observado no mundo real:

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

• 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.

Sondagem CRUD via OpenAPI a partir das roles 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.

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

Padrão de sondagem (exemplos):

• Ler um único registro (esperar 401/403/200 dependendo do 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>"

• Teste se UPDATE está bloqueado (use um filtro inexistente para evitar alterar dados durante os testes):

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"

• Teste INSERT está bloqueado:

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

• Testar se DELETE está bloqueado:

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"

Recommendations:

• Automatize as sondagens anteriores para tanto anon quanto um usuário minimamente authenticated e integre-as no CI para detectar regressões.
• Trate every exposed table/view/function como uma superfície de primeira classe. Don’t assume uma view “inherits” the same RLS posture as its base tables.

Passwords & sessions

É possível indicar o tamanho mínimo da senha (por padrão), requisitos (nenhum por padrão) e proibir o uso de leaked passwords.
Recomenda-se melhorar os requisitos, pois os padrões são fracos.

• User Sessions: É possível configurar como as user sessions funcionam (timeouts, 1 session per user...)
• Bot and Abuse Protection: É possível habilitar Captcha.

SMTP Settings

É possível configurar um SMTP para enviar e-mails.

Advanced Settings

• Definir tempo de expiração para access tokens (3600 por padrão)
• Configurar para detectar e revogar refresh tokens potencialmente comprometidos e timeout
• MFA: Indicar quantos fatores MFA podem ser registrados ao mesmo tempo por usuário (10 por padrão)
• Max Direct Database Connections: Número máximo de conexões diretas usadas para autenticação (10 por padrão)
• Max Request Duration: Tempo máximo permitido para uma requisição de Auth durar (10s por padrão)

Storage

• Defina o limite de tamanho de arquivo para upload (padrão 50MB)
• A conexão S3 é fornecida com uma URL como: https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3
• É possível solicitar S3 access key que são formadas por um access key ID (e.g. a37d96544d82ba90057e0e06131d0a7b) e um secret access key (e.g. 58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628)

Edge Functions

Também é possível armazenar segredos no supabase que serão acessíveis por edge functions (eles podem ser criados e deletados pela web, mas não é possível acessar seus valores diretamente).

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