Prompt · Blindagem

1. Abra o projeto, salve a versão atual.
2. Cole o prompt abaixo no chat.
3. Revise cada migration antes de aplicar — espera-se só ADD/CREATE.
4. Confirme login + 3 fluxos críticos depois.

PROMPT BLINDAGEM v1.1 • SC CORE E SISTEMAS SANCRUZA

Aplique blindagem de segurança e performance sem alterar produto, fluxo, UI ou schema de negócio.

Este prompt é ADITIVO.

Não renomeie tabelas.
Não remova tabelas.
Não remova colunas.
Não altere tipos.
Não altere UI.
Não altere fluxo de login.
Não altere regras de negócio.
Não crie nova arquitetura.
Não refatore por estética.
Não "melhore" nomenclatura.

Apenas avaliar e, quando seguro, adicionar:
- RLS
- policies
- GRANTs
- índices
- validação Zod
- rate limit
- ajustes de auth
- correções recomendadas pelo linter

REGRA PRINCIPAL

Antes de aplicar qualquer mudança, responda:
1. Qual risco real esta mudança reduz?
2. A mudança é aditiva?
3. Pode quebrar algum fluxo existente?
4. Como testar a não regressão?

Se houver risco de regressão, pare e reporte antes de aplicar.

================================================================
FASE 1 • AUDITORIA, SEM ALTERAR NADA
================================================================
Primeiro, faça apenas diagnóstico.

Levante:
- tabelas public
- tabelas sem RLS
- policies existentes
- GRANTs existentes
- funções SECURITY DEFINER
- índices existentes
- foreign keys sem índice
- endpoints públicos
- createServerFn sem validação
- rotas /api/public/*
- warnings do Supabase linter
- configurações de Auth relevantes

Cole o output do linter.
Não corrija nada ainda.

================================================================
FASE 2 • CLASSIFICAÇÃO DE RISCO
================================================================
Classifique cada item como:

- CRÍTICO: risco de exposição de dados, bypass de permissão, role escalation, service_role no client
- ALTO: ausência de RLS, endpoint público sem validação, webhook sem assinatura
- MÉDIO: FK sem índice, query frequente sem índice, validação incompleta
- BAIXO: melhoria de organização, warning sem exploração direta

Só aplicar automaticamente itens CRÍTICOS, ALTOS e índices seguros.
Itens que podem alterar comportamento devem ser reportados antes.

================================================================
FASE 3 • RLS
================================================================
Para cada tabela public sem RLS:
- Identifique o padrão real de uso no código.
- Verifique se a tabela é:
  · dados do usuário
  · configuração global
  · administrativa
  · catálogo autenticado
  · catálogo público
  · tabela técnica
- Proponha policy mínima.

Regras:
- Não criar policy permissiva para INSERT, UPDATE ou DELETE com USING true.
- Não liberar anon sem motivo explícito.
- Não bloquear comportamento que já existia sem avisar.
- Não criar policy baseada em suposição fraca.
- Se houver dúvida, pare e reporte a tabela.

Padrões permitidos:
- Dados do próprio usuário: auth.uid() = user_id
- Configuração lida por usuários logados: SELECT TO authenticated USING (true)
- Administração: public.has_role(auth.uid(), 'admin')
- Acesso por sistema: public.has_app_access(auth.uid(), '<slug>')
- Catálogo público: SELECT TO anon USING (true) somente se for público por design.

================================================================
FASE 4 • GRANTs
================================================================
Ajuste GRANTs conforme as policies.
Não conceder verbos desnecessários.
Se a tabela só tem SELECT, conceda apenas SELECT.

Exemplo:
    GRANT SELECT ON public.<tabela> TO authenticated;

Para service_role:
    GRANT ALL ON public.<tabela> TO service_role;

Nunca conceder anon sem policy anon explícita.

================================================================
FASE 5 • ESCALONAMENTO DE PRIVILÉGIO
================================================================
Verifique se existe role, is_admin, admin, permission ou equivalente diretamente em tabela editável pelo usuário.

Se existir, não remova.
Crie proteção aditiva:
- trigger BEFORE UPDATE
- função SECURITY DEFINER
- bloqueio de alteração por não-admin

Funções de role devem ter:
- SECURITY DEFINER
- SET search_path = public
- retorno false quando auth.uid() for null
- sem depender de dados manipuláveis no client

================================================================
FASE 6 • ÍNDICES
================================================================
Adicionar somente índices seguros e idempotentes:
- CREATE INDEX IF NOT EXISTS em foreign keys sem índice
- índices em colunas usadas em filtros frequentes
- índices em colunas usadas em ordenação frequente
- índice DESC em timestamp usado para paginação
- GIN apenas se já existir busca textual no app

Nunca dropar índice.
Nunca renomear índice existente.
Nunca alterar estrutura de tabela.

================================================================
FASE 7 • INPUT VALIDATION
================================================================
Para cada createServerFn e endpoint público:
Adicionar validação Zod sem mudar comportamento esperado.

Regras:
- string com min e max
- email com email e max 255
- uuid com uuid
- number com min e max
- array com max
- objeto com strict quando seguro

Input inválido deve retornar erro claro.
Não alterar lógica interna da função.
Não alterar formato de resposta se o input for válido.

================================================================
FASE 8 • ENDPOINTS PÚBLICOS
================================================================
Para cada /api/public/*:
- adicionar validação Zod
- adicionar rate limit por IP
- adicionar assinatura HMAC apenas quando o endpoint for webhook ou receber payload sensível

Atenção:
Não exigir HMAC em endpoint público legítimo que hoje não possui emissor capaz de assinar.
Nesse caso, reporte como recomendação, não aplique automaticamente.

Rate limit padrão:
- público comum: 60 req/min por IP
- webhook autenticado: 600 req/min

Se não existir infraestrutura segura para rate limit, reporte a recomendação antes de criar tabela nova.

================================================================
FASE 9 • CONFIGURAÇÕES AUTH
================================================================
Verifique e reporte:
- email/password desabilitado quando o projeto usa Google corporativo
- signup público desabilitado
- anonymous users desabilitado
- JWT expiry coerente
- password_hibp_enabled ativo se senha estiver disponível em qualquer cenário

Não alterar fluxo de login aprovado.

================================================================
FASE 10 • NÃO REGRESSÃO
================================================================
Após aplicar mudanças permitidas, testar:
- login
- dashboard
- usuário ativo
- usuário inativo
- usuário sem permissão
- leitura de dados próprios
- criação
- edição
- exclusão
- endpoints públicos
- responsividade básica

Se algo quebrar, rever a policy ou validação. Não mascarar erro.

================================================================
ENTREGÁVEL FINAL
================================================================
Entregar:

1) Confirmação de escopo:
   - nenhuma tabela renomeada
   - nenhuma tabela removida
   - nenhuma coluna removida
   - nenhum tipo alterado
   - nenhuma UI alterada
   - nenhum fluxo de login alterado

2) Linter antes e depois.

3) Lista de mudanças aplicadas:
   - ENABLE RLS
   - CREATE POLICY
   - GRANT
   - CREATE INDEX
   - CREATE FUNCTION
   - CREATE TRIGGER
   - validações Zod
   - rate limits

4) Lista de itens NÃO aplicados por risco de regressão.

5) Lista de testes realizados.

6) Checklist final:
   - todas as tabelas public avaliadas
   - RLS habilitado onde aplicável
   - GRANTs coerentes com policies
   - sem service_role no client
   - sem escalonamento de privilégio
   - FKs críticas indexadas
   - serverFns validadas
   - endpoints públicos protegidos
   - Auth revisado
   - linter sem ERROR não tratado
   - fluxos críticos funcionando

Se qualquer item crítico não puder ser resolvido sem risco de regressão, pare e reporte.