horizonchapter/checklist-lancement-web

Checklist de lançamento web

Objetivo: nunca publicar um site, uma loja Shopify, um app ou um SaaS com uma falha, uma falta legal ou um percurso de compra quebrado. O lançamento continua sendo uma decisão do usuário: você verifica e prepara, você não publica nada.

Regra de decisão (bloqueante)

NÃO PUBLICAR se um destes pontos persistir:

• uma chave ou segredo privado está exposto (código front-end, repositório Git, build);
• um usuário pode ler ou modificar dados de outro;
• o HTTPS está ausente ou quebrado;
• a RLS (ou equivalente) está ausente ou mal configurada em dados privados;
• rastreadores sujeitos a consentimento são disparados antes do acordo;
• taxas estão ocultas ou enganosas;
• o percurso de compra ou pagamento está defeituoso.

Método

1. Identifique o tipo de projeto (site vitrine, loja, app com contas, SaaS com pagamento) e ignore os controles que não se aplicam, informando isso.
2. Passe pelos 5 blocos abaixo na ordem. Para cada controle: status OK / A CORRIGIR / NÃO APLICÁVEL / NÃO VERIFICÁVEL, com a prova ou teste realizado.
3. Quando tiver acesso ao código ou ao banco de dados (Supabase, Vercel, Shopify), verifique você mesmo; caso contrário, forneça ao usuário o teste exato a ser feito.
4. Termine com o relatório (formato abaixo).

Bloco 1 — Segurança técnica

• HTTPS em todo o domínio, HTTP redirecionado, sem conteúdo misto; HSTS somente após validação. Teste: http:// redireciona.
• Cabeçalhos de segurança: CSP adequada, nosniff, Referrer-Policy, proteção de iframes. Teste: SecurityHeaders.com.
• Segredos apenas no lado do servidor (chaves privadas, tokens de pagamento, chaves de API secretas). Teste: build JS e repositório Git sem segredo.
• Validação no lado do servidor (tipo, tamanho, campos); a validação front-end sozinha pode ser contornada. Teste: uma requisição modificada é rejeitada.
• Direitos em cada recurso: identidade E direito de acesso a cada objeto. Teste: a conta B não lê nem modifica nada de A.
• Injeção SQL / XSS: consultas parametrizadas, escape do framework, nunca HTML de usuário bruto. Teste: texto HTML é exibido sem ser executado.
• CSRF e cookies: Secure, HttpOnly, SameSite, proteção anti-CSRF se autenticação por cookies.
• Dependências atualizadas, nenhum alerta crítico, pacotes desnecessários removidos.
• CORS limitado às origens necessárias (não é uma barreira de acesso).
• Upload controlado: tamanho, formato real, extensões, renomeação, armazenamento isolado.
• Anti-abuso: rate limiting em login, e-mails e formulários; Turnstile ou CAPTCHA se necessário.
• Contas de admin: MFA, acessos limitados, nenhum painel interno visível.
• Modo produção: sem debug, sem .env publicado, sem logs verbosos.
• E-mails enviados com o domínio: SPF, DKIM, DMARC.

Bloco 2 — Dados (Supabase ou equivalente)

• Chave publishable/anon no navegador apenas se RLS estiver correta; chave service_role somente no lado do servidor.
• RLS ativada em todas as tabelas expostas, direitos desnecessários removidos de anon/authenticated.
• Políticas por ação (SELECT, INSERT, UPDATE, DELETE) vinculadas a auth.uid(); testes positivos E negativos com três perfis: visitante, usuário A, usuário B.
• Buckets Storage com regras adequadas (um avatar público não tem os direitos de uma fatura).
• Auth: URLs de redirecionamento autorizadas, expiração de sessões, redefinição e logout testados.
• Security Advisor: nenhum alerta crítico não tratado.
• Backups: opções reais verificadas, restauração testada.
• Logs e alertas (erros 5xx, cotas) sem nunca registrar senhas ou tokens.
• Ambientes separados (local, pré-produção, produção) e rollback pronto.

Bloco 3 — Direito e confiança (França / UE, a verificar conforme a atividade)

• Avisos legais (identidade, contato), política de privacidade (dados, finalidades, base legal, retenção, direitos, contato).
• Termos de Uso; Termos de Venda se houver venda; reembolsos e direito de arrependimento (funcionalidade de arrependimento online a partir de 19/06/2026 para contratos afetados); mediador do consumidor.
• Cookies: política, banner onde recusar é tão simples quanto aceitar, nenhum rastreador antes do consentimento, escolha modificável em cada página.
• Formulários: informação na coleta, caixas desmarcadas, minimização de dados, prazos de purga.
• Inventário de ferramentas de terceiros (analytics, pixels, chat, CAPTCHA, IA) e de transferências fora da UE.
• Nenhum dark pattern, nenhuma urgência falsa, nenhuma taxa oculta (preço total, frete, assinatura exibidos antes do pagamento).
• Nenhum falso depoimento, nenhuma promessa ou número não demonstrável.
• Licenças de imagens, ícones, vídeos, fontes.
• Menores: na França, consentimento conjunto para menores de 15 anos se o tratamento se basear no consentimento.
• Link de descadastro funcional em e-mails promocionais; procedimento de exclusão de conta.
• Procedimento de vazamento de dados (notificação à CNIL em 72h se houver risco).

Bloco 4 — UX, SEO e conversão

• Um CTA principal claro, utilizável com o polegar no celular.
• Title único e meta-descrição útil por página; og:image testada; favicon.
• sitemap.xml, robots.txt, canonical, noindex em páginas privadas; Search Console.
• Página 404 personalizada que retorna o status 404 corretamente; links quebrados verificados.
• FAQ sobre as reais objeções; prazos prometidos realistas; página de agradecimento após ação.
• Acessibilidade: contraste, navegação por teclado, foco visível, textos alternativos, zoom de 200%.
• Performance: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 (PageSpeed mobile e desktop); imagens comprimidas.

Bloco 5 — Testes reais antes da publicação

• Formulários: vazio, inválido, muito longo, erro de servidor, clique duplo, sucesso, recebimento, celular.
• Compra em modo de teste e depois reembolso; preço total, total, fatura corretos.
• E-mails realmente recebidos (cadastro, redefinição, fatura, suporte).
• Webhooks: assinatura verificada, repetição sem duplicação.
• Navegação privada: nenhum rastreador depositado antes do consentimento.
• Domínio e DNS protegidos por MFA; retorno à versão estável possível.

Formato do relatório

1. Veredito em uma linha: PRONTO PARA PUBLICAR / A CORRIGIR ANTES DA PUBLICAÇÃO / BLOQUEADO (ponto bloqueante citado).
2. Pontos bloqueantes, depois pontos a corrigir classificados por gravidade, cada um com a correção exata e onde fazê-la.
3. Pontos não verificáveis e o teste que o usuário deve fazer.
4. Lembrete: o usuário publica por conta própria. Para questões jurídicas, essa verificação não substitui um profissional.