Segurança

Última atualização: 21 de outubro de 2026.

Nenhum sistema é 100% seguro, e desconfie de quem prometer isso. O que dá para prometer é uma arquitetura em que os dados mais sensíveis nem passam por nós, controles em camadas e um processo de revisão contínua. Esta página explica o que já está implementado e o que faz parte da rotina.

1. O que nunca guardamos

Número de cartão. O pagamento com cartão acontece na página da instituição de pagamento (Asaas; Stripe nos demais países). O número do cartão nunca chega aos nossos servidores.
Senha em texto. Senhas são guardadas apenas como hash (bcrypt) pelo Supabase Auth.
Saldo dos vendedores. O dinheiro fica na conta do vendedor na instituição de pagamento, não com a plataforma.

2. Como os dados ficam protegidos

Dado	Onde fica	Proteção
Endereço de entrega	pedido, visível só para comprador e vendedor daquele pedido	regras de acesso por linha (RLS) no banco; apagado 180 dias após o fim da garantia
CPF / documento	perfil do vendedor e instituição de pagamento	RLS: só o dono lê; a plataforma não exibe em nenhuma tela pública
Chave da conta de recebimento (Asaas)	tabela separada sem acesso público	criptografada com AES-256-GCM antes de gravar; só o servidor descriptografa
Vídeos e fotos	armazenamento com pasta por usuário	só o dono grava/apaga na própria pasta; limite de 50 MB e tipos permitidos
Documentos de verificação (RG, selfie, comprovante)	bucket privado, pasta por usuário	nenhum acesso público; a equipe vê por link temporário de 10 minutos; apagados 30 dias após a decisão
Conversas do atendimento	tabelas sem acesso público	lidas só pelo servidor e pelo painel do atendente; visitante identificado por cookie aleatório
Localização	só cidade/estado/país, escolhidos pelo próprio usuário	nunca gravamos coordenadas nem endereço IP de forma permanente

3. Defesas contra ataques comuns

Injeção de SQL: todas as consultas usam parâmetros (cliente Supabase); o termo de busca é sanitizado.
XSS: o React escapa todo texto; a renderização de Markdown das páginas institucionais não aceita HTML; política de segurança de conteúdo (CSP) bloqueia scripts externos.
Clickjacking: `frame-ancestors 'none'` e `X-Frame-Options: DENY`.
CSRF: as ações de servidor do Next.js verificam a origem; cookies com `SameSite=Lax`.
Sessão: cookies de sessão `HttpOnly` gerenciados pelo Supabase; renovação pelo middleware.
Redirecionamento aberto: o parâmetro `next` do login só aceita caminhos internos.
Webhooks falsos: o Asaas precisa enviar o token secreto no cabeçalho; eventos repetidos são ignorados (idempotência).
Cron falso: a rota de liberação automática exige `CRON_SECRET`.
Força bruta no login: limites de tentativa do Supabase Auth; recomendado ativar o CAPTCHA (hCaptcha/Turnstile) no painel do Supabase antes do lançamento.
Vazamento de chaves: `SUPABASESERVICEROLEKEY`, `ASAASAPIKEY`, `APPENCRYPTIONKEY` existem só no servidor; nenhuma delas tem prefixo `NEXTPUBLIC_`.
Transporte: HTTPS obrigatório com HSTS; `upgrade-insecure-requests` na CSP.
Cabeçalho de servidor: `X-Powered-By` removido; `Referrer-Policy` restrita; `Permissions-Policy` desliga câmera/microfone/geolocalização para terceiros.

4. Segurança das pessoas (não só dos dados)

Sem encontro presencial. Não existe retirada em mãos: todo envio é por transportadora com rastreio. Isso elimina o golpe do "encontro para entrega".
Dinheiro em garantia. O vendedor só recebe após confirmação de entrega; o comprador tem mediação.
Identidade verificada do vendedor pela instituição de pagamento (CPF/documento, endereço, telefone).
Contato por telefone só após a venda, e nunca mostrado publicamente.

5. Rotina de segurança (antes e depois do lançamento)

[ ] Ativar CAPTCHA no Supabase Auth e confirmação de e-mail obrigatória.
[ ] Ativar o firewall/WAF da Vercel com limite de requisições por IP nas rotas de login, checkout e webhook.
[ ] Rodar a revisão de segurança automática (`/security-review`) a cada mudança no código.
[ ] Rotacionar `ASAASWEBHOOKTOKEN`, `CRON_SECRET` e chaves do Supabase a cada 6 meses ou ao sair alguém da equipe.
[ ] Backups diários do banco (Supabase Pro inclui) e teste de restauração trimestral.
[ ] Registro de acessos (logs) por 6 meses, como exige o Marco Civil.
[ ] Plano de resposta a incidentes: comunicar usuários afetados e a ANPD em até 3 dias úteis (LGPD).
[ ] Contratar um teste de invasão (pentest) externo antes de abrir para o público.

6. Como reportar uma falha

Encontrou uma vulnerabilidade? Escreva para [seguranca@desapegodotenista.com.br] com os passos para reproduzir. Respondemos em até 2 dias úteis e não processamos pesquisadores que agem de boa-fé.