Segurança

Como se entra em cada projeto, quem são os usuários, se há autenticação, se está aberto ao público e onde estão os pontos a checar.

Atenção: esta aba é um checklist inferido a partir do inventário dos projetos — não é um scan de segurança real. Itens marcados como Inferido precisam de validação; os marcados como Verificado foram confirmados manualmente. Nada aqui afirma que existe vazamento de service role ou tabela aberta: são hipóteses a conferir no scan de cada projeto.

Projetos em risco alto

Sem autenticação identificada

Total analisado

Ações de segurança do portfólio

1.Inventariar chaves: nenhuma service role key pode aparecer em código de tela ou bundle publicado — só em edge function/servidor.
2.Rodar o scan de segurança em todos os projetos com banco e tratar os achados de RLS antes de qualquer publicação.
3.Padronizar papéis em tabela user_roles separada com função security definer (nunca papel gravado no perfil do usuário).
4.Ativar proteção contra senha vazada (HIBP) em todos os projetos com login.
5.Trocar links públicos previsíveis por token aleatório com expiração.
6.Definir política de retenção e log de acesso para projetos com dado pessoal (LGPD).
7.Revisar quem tem acesso ao workspace Lovable e remover contas inativas.
8.Após cada mudança de schema em projeto publicado, revalidar as políticas de RLS.

Reserve Temporada

InferidoRisco AltoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

RBR Central

InferidoRisco AltoAuth não identificadaAcesso a confirmar

Forma de acesso: A confirmar: backend ativo, sem sinal de autenticação no inventário
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?A checar: não encontrei sinal de autenticação no inventário — confirmar se há login antes de tratar como aberto.

Ações

→Revisar RLS: nenhuma tabela com dado real deve ter policy USING (true) para anon.
→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Clinic Supply Connect

InferidoRisco AltoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Simulador Rental | Proprietário

InferidoRisco AltoAuth não identificadaAcesso a confirmar

Forma de acesso: A confirmar: backend ativo, sem sinal de autenticação no inventário
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?A checar: não encontrei sinal de autenticação no inventário — confirmar se há login antes de tratar como aberto.

Ações

→Revisar RLS: nenhuma tabela com dado real deve ter policy USING (true) para anon.
→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

reserve-temporada-teste

InferidoRisco AltoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

rbrfinancepersonalapagar

InferidoRisco AltoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

project-raposa-hub-05

InferidoRisco AltoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.

rbr-lgpd-check

InferidoRisco AltoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

RBRFlow

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

SOL estrateg.IA

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Olimpiaseg

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

RBR Hub

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Recanto Janbor

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Se houver links públicos (propostas/cotações), usar token aleatório e prazo de expiração.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

RBR Scale

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Se houver links públicos (propostas/cotações), usar token aleatório e prazo de expiração.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

ERP Saúde | Atendimento de Pacientes

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Se houver links públicos (propostas/cotações), usar token aleatório e prazo de expiração.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Clube de Compra

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Prospecta

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação simples
Usuários: Usuários cadastrados, todos com o mesmo nível

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Checar se existe hierarquia de papéis (admin / operador / leitura) restringida por RLS.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

rbr-finance (marketplace)

InferidoRisco MédioCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação simples
Usuários: Usuários cadastrados, todos com o mesmo nível

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Checar se existe hierarquia de papéis (admin / operador / leitura) restringida por RLS.
→Se houver links públicos (propostas/cotações), usar token aleatório e prazo de expiração.
→Dado pessoal/financeiro: definir base legal LGPD, retenção e log de acesso.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Orbitta Insights Hub

InferidoRisco BaixoCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Frank.IA

VerificadoRisco BaixoCom autenticaçãoRestrito a usuários

Forma de acesso: Autenticação ativa com área administrativa; acesso adicional restrito por IP no Cloudflare.
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Roof Measure Pro

InferidoRisco BaixoCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Projeto publicado: revalidar as políticas após cada mudança de schema.

RBR Energy Insights

InferidoRisco BaixoCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação simples
Usuários: Usuários cadastrados, todos com o mesmo nível

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Checar se existe hierarquia de papéis (admin / operador / leitura) restringida por RLS.

RBR Energy

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

PowerFit Git Hub

InferidoRisco BaixoCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação simples
Usuários: Usuários cadastrados, todos com o mesmo nível

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Checar se existe hierarquia de papéis (admin / operador / leitura) restringida por RLS.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Canal de Consultores RBR Rental

InferidoRisco BaixoCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação e hierarquia de papéis
Usuários: Equipe interna e parceiros, com níveis distintos de permissão

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Garantir que os papéis ficam em tabela user_roles separada, com função security definer (nunca no perfil do usuário).
→Projeto publicado: revalidar as políticas após cada mudança de schema.

RBR Rental

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Se houver links públicos (propostas/cotações), usar token aleatório e prazo de expiração.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

APP Rental

InferidoRisco BaixoCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação simples
Usuários: Usuários cadastrados, todos com o mesmo nível

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Checar se existe hierarquia de papéis (admin / operador / leitura) restringida por RLS.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

stays-inspired-portal

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.

rbr-consult | antigo

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Rbr Consult

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

pagina-propostas-rbrconsult

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Se houver links públicos (propostas/cotações), usar token aleatório e prazo de expiração.

RBR Finance (pessoal)

InferidoRisco BaixoCom autenticaçãoRestrito a usuários

Forma de acesso: Login com autenticação simples
Usuários: Usuários cadastrados, todos com o mesmo nível

Pontos a checar

Nenhum ponto pendente registrado.

Ações

→Rodar o scan de segurança do projeto e tratar todo achado de RLS.
→Confirmar que a chave usada no front é a publishable/anon — nunca a service role.
→Checar se existe hierarquia de papéis (admin / operador / leitura) restringida por RLS.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

ERP Pessoal | Despesas Pessoais

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.

RBR Tecnolog.IA

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

parcelamento-simples-facil

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Digolin Cachaça Landing

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.
→Projeto publicado: revalidar as políticas após cada mudança de schema.

Project Digest

InferidoRisco BaixoAuth não identificadaAcesso a confirmar

Forma de acesso: Aberto ao público (site/página estática)
Usuários: A confirmar (provavelmente qualquer visitante)

Pontos a checar

?Sem backend: qualquer chave usada pelo front está no bundle e é legível por qualquer visitante.

Ações

→Auditar o bundle publicado atrás de tokens de API (Stays, Make, webhooks) e mover para um proxy no servidor.