SEUS PROJETOS COM IA
Publique seu projeto com link de teste grátis, receba feedback, inspire outros criadores e permita remix.
Feito com:
Carregando…
Antes de publicar, blinde seu projeto
Vibe coding é rápido, mas 90% dos projetos publicados por aí vazam dados por descuido em RLS, chaves expostas ou colunas sensíveis. Siga este guia — e cole o prompt no final na sua IA favorita para auditar antes de subir.
Ative RLS em TODAS as tabelas
Row Level Security é sua primeira linha de defesa. Sem ela, qualquer pessoa com a chave pública lê e escreve na sua base. Habilite RLS e escreva políticas específicas por operação (SELECT, INSERT, UPDATE, DELETE) escopadas em auth.uid().
Nunca exponha service_role no frontend
A service_role key ignora RLS e dá acesso total. Ela só pode viver em variáveis de ambiente do servidor (edge/server functions). No cliente use apenas a anon/publishable key.
Roles em tabela separada (nunca no perfil)
Guardar 'is_admin' em profiles abre porta para escalada de privilégio. Crie public.user_roles + enum app_role + função has_role() com SECURITY DEFINER e use-a nas policies.
Cuidado com colunas sensíveis
RLS filtra linhas, não colunas — se o usuário pode ler a linha, lê TODAS as colunas. Nunca exponha password_hash, tokens, chaves de API. Use views com security_invoker para esconder campos.
Valide entradas com Zod (cliente E servidor)
Validação apenas no frontend é ilusão de segurança. Use zod nas server functions com .max(), .email(), .trim() e nunca use dangerouslySetInnerHTML com conteúdo do usuário.
Ative proteção contra senha vazada
No painel de Auth, ligue o Password HIBP Check — bloqueia senhas que já vazaram em vazamentos públicos. Exija mínimo de 8+ caracteres e habilite verificação por e-mail.
Rate limiting em funções sensíveis
Endpoints de login, envio de e-mail, uso de IA e criação de conteúdo precisam de limite por IP/usuário. Sem isso, atacantes automatizam brute force e drenam seus créditos.
GRANT explícito em tabelas públicas
No Supabase, o schema public NÃO tem grants por padrão para anon/authenticated. Sem GRANT SELECT/INSERT/UPDATE/DELETE a tabela retorna erro de permissão mesmo com RLS liberado.
Prompt de auditoria — cole na sua IA (Lovable, Claude, ChatGPT, Gemini…)
Antes de finalizar qualquer feature no meu app, faça uma auditoria de segurança seguindo este checklist e me diga o que está errado + como corrigir: 1. RLS: toda tabela em 'public' tem RLS habilitado? Cada política está escopada em auth.uid() e cobre SELECT/INSERT/UPDATE/DELETE separadamente? 2. GRANTs: toda tabela criada em 'public' tem GRANT explícito para os roles corretos (authenticated, service_role, anon apenas se público)? 3. Roles/Permissões: papéis de usuário estão em tabela separada (user_roles) com enum app_role e função has_role() SECURITY DEFINER? Nunca 'is_admin' no profile. 4. Colunas sensíveis: password_hash, tokens, chaves de API, PII, e-mails privados estão fora de policies públicas? Uso views com security_invoker quando necessário. 5. Service role: SUPABASE_SERVICE_ROLE_KEY nunca aparece no cliente, apenas em server/edge functions com autenticação verificada. 6. Validação: toda entrada de usuário é validada com Zod no servidor (não só no cliente), com limites de tamanho, tipo e formato. 7. XSS: nenhum dangerouslySetInnerHTML com conteúdo do usuário; URLs de terceiros passam por encodeURIComponent. 8. Auth: e-mail confirmado obrigatório, senha mínima 8+, HIBP check ativo, sem signup anônimo a menos que eu peça. 9. Rate limiting: endpoints públicos (login, IA, envio de e-mail, criação) têm limite por IP/usuário. 10. Storage: buckets sensíveis são privados; upload valida tipo MIME e tamanho. 11. Segredos: nenhuma chave hardcoded no código; tudo em variáveis de ambiente/secrets. 12. Erros: mensagens não vazam detalhes internos (stack trace, SQL, IDs) para o usuário. Liste cada item como ✅ (ok), ⚠️ (risco), ou ❌ (crítico), com o arquivo/linha e a correção sugerida.