// docs / security guides / pre-ship checklist

Checklist de segurança vibe coding: 44 itens antes do deploy

Uma lista de verificação prática e organizada por fases para aplicativos desenvolvidos com Cursor, Claude Code, Lovable, Bolt, v0, Replit e Windsurf. Cada item pode ser acionado em menos de cinco minutos. Execute-o antes de avançar para a produção e novamente antes de cada lançamento principal. Os itens são agrupados em sete categorias — segredos, banco de dados, autenticação, cabeçalhos, terceiros, implantação, monitoramento — e marcados com a fase de implantação à qual se aplicam.

PRE = pré-implantar (audite sua fonte). DEPLOY = no momento da implantação. POST = verificação pós-implantação. Referência de itens FixVibe verifique IDs no formulário category.check-id quando relevante.

Segredos e chaves API (8 itens)

Chaves codificadas são a descoberta mais comum em aplicativos codificados por vibe. Oito itens para mantê-los afastados:

PRE — Audit NEXT_PUBLIC_ env vars. Qualquer coisa com o prefixo NEXT_PUBLIC_ é enviada em pacotes de clientes. Se uma for uma chave Supabase service_role (decodifica para JWT com "role":"service_role"), exclua-a e roteie através de um cliente somente servidor (src/lib/supabase/service.ts com import 'server-only').
PRE — Grep for hardcoded provider keys. Fonte de pesquisa para sk_live_, pk_live_, STRIPE_SECRET, sk-ant-, sk-, AIza, AKIA e JWT- procurando strings (eyJ). Mova cada hit para .env.local e faça referência via process.env.* apenas no lado do servidor.
PRE — Verify .gitignore. Confirme .env*.local, .npmrc, .yarnrc e todos os arquivos de credenciais específicos do provedor serão ignorados. Execute git ls-files canalizado através dos padrões do seu provedor para encontrar qualquer coisa já confirmada.
PRE — Scan the built bundle. Execute npm run build e grep .next/static e qualquer saída dist/ para os mesmos padrões. Se uma chave atingir o pacote, o desenvolvedor nunca teve uma separação de ambiente limpa.
DEPLOY — Set secrets per environment. Vercel: Configurações → Variáveis de ambiente, escopo de cada uma para Produção/Visualização/Desenvolvimento. Nunca compartilhe sk_live_* com o ambiente de visualização. Use o armazenamento env-var criptografado do Vercel, e não os segredos do fluxo de trabalho embutido.
DEPLOY — Disable build-log secret echo. Algumas configurações CI echo env vars durante a construção. Audite seus fluxos de trabalho de vercel.json, GitHub Actions ou Cloudflare Pages para qualquer echo $SECRET que enviaria o valor para logs de construção públicos.
A camada POST — Run a passive scan. FixVibe Free cobre isto: cole o URL implantado, espere cerca de 20s, procure por secrets.* descobertas. A verificação secrets.browser-storage captura chaves que caíram em localStorage ou sessionStorage através do uso indevido de SDK.
POST — Rotate any key that ever shipped. Se uma chave esteve em um pacote público por alguns minutos, trate-a como comprometida. Gire as chaves de função de serviço Supabase por meio do painel, regenere as chaves restritas Stripe, revogue as chaves Anthropic / OpenAI / Google por meio de seus consoles.

Controle de acesso ao banco de dados: RLS e regras do Firestore (6 itens)

Os padrões BaaS são permissivos propositalmente, então o primeiro tutorial funciona. Production precisa de políticas explícitas.

PRE — Force RLS on every public.* table. Em Supabase: cada tabela deve ter ALTER TABLE ... ENABLE ROW LEVEL SECURITY e FORCE ROW LEVEL SECURITY. Force importa: sem ele, o Postgres ignora RLS para proprietários de tabelas.
PRE — Write a policy per (table, role, action). Mínimo: uma política SELECT que se junte a auth.uid(). Melhor: políticas separadas INSERT / UPDATE / DELETE para que um UPDATE não possa contrabandear user_id alterações que redirecionem a propriedade.
PRE — Replace default Firebase rules. As regras padrão do modo de teste são allow read, write: if true;. Substitua por regras vinculadas a autenticação por coleção: match /users/{userId} por allow read, write: if request.auth.uid == userId;
PRE — Lint migrations in CI. Execute supabase db lint ou equivalente antes de mesclar. CI deverá falhar na compilação se qualquer CREATE TABLE public.* não tiver uma política RLS correspondente.
DEPLOY — Confirm RLS survived deploy. Verifique novamente Supabase Studio após a implantação: Tabelas → cada linha → RLS alternância é ON. Production migrações de banco de dados ocasionalmente ultrapassam os arquivos de políticas; verifique se a política está ativa.
POST — Run an active scan against a verified domain. A verificação ativa baas.supabase-rls grava em uma pequena linha inicial usando a tecla anon e informa se a gravação foi bem-sucedida - i.e. RLS não é realmente obrigatório.

Autenticação e sessões (7 itens)

Bugs de autenticação em aplicativos AI-codificados tendem a ser sutis: uma verificação de token off-by-one, um sinalizador HttpOnly perdido, um getSession() onde deveria haver um getUser().

PRE — Replace getSession() with getUser(). getSession() lê o cookie e confia nele; getUser() verifica com o back-end Supabase. Nas rotas do servidor use sempre getUser().
PRE — Confirm token expiry. Magic-link, tokens de redefinição de senha e tokens de verificação de e-mail precisam de expiração imposta pelo servidor. Os links mágicos Supabase padrão expiram após 1 hora - não substitua isso por um número maior sem um motivo real.
PRE — Verify JWT aud and exp. Se você decodificar tokens manualmente em qualquer lugar, verifique ambas as afirmações. Melhor: use o SDK getUser() que faz isso por você.
PRE — Audit cookie flags. Os cookies de sessão personalizados devem ser Secure; HttpOnly; SameSite=Lax (ou Strict para fluxos não-OAuth). Nenhum material de sessão em localStorage.
PRE — Validate the next redirect param. O parâmetro de consulta next após o login deve começar com / e não // (redirecionamento aberto para attacker.example). Rejeite qualquer outra coisa do lado do servidor.
POST — Test logout. Faça login, saia, inspecione cookies (DevTools → Aplicativo → Cookies). O cookie da sessão deve ser limpo na mesma resposta. Se persistir, o manipulador de logout não está destruindo realmente o estado do lado do servidor.
POST — Active probe. As verificações active.auth-flow e active.account-enumeration revelam limites de autenticação quebrados - respostas diferentes em "usuário existe" versus "senha errada", limite de taxa ausente no login, tokens de redefinição não assinados.

HTTP cabeçalhos de segurança e Política de Segurança de Conteúdo (6 itens)

Os cabeçalhos são o endurecimento mais barato em todo o pipeline e os ignorados de forma mais consistente pelo codegen.

PRE — Ship a real CSP. Mínimo: script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. Não 'unsafe-inline' em script-src. Next.js aplica automaticamente o nonce quando o middleware define o cabeçalho de solicitação x-nonce.
PRE — Add the legacy three. X-Content-Type-Options: nosniff, X-Frame-Options: DENY (ou confie apenas em CSP frame-ancestors), Strict-Transport-Security: max-age=31536000; includeSubDomains.
PRE — Tighten Referrer-Policy. O padrão strict-origin-when-cross-origin é adequado para a maioria dos aplicativos. Não envie unsafe-url ou nenhum cabeçalho.
PRE — Replace Access-Control-Allow-Origin: *. Grep por isso. Substitua por uma lista de permissões de origem explícita. Em qualquer lugar que esteja * ao lado de credentials: include, o navegador recusará a solicitação - mas isso não é defesa contra um back-end mal configurado.
DEPLOY — Verify headers post-deploy. Abra DevTools → Rede → clique no documento raiz → guia Cabeçalhos. CSP, HSTS, X-Frame-Options, X-Content-Type-Options devem estar presentes. CSP não deve ter 'unsafe-inline' em script-src.
POST — Run headers.security-headers. A verificação de cabeçalho passivo relata cada cabeçalho ausente com orientação de correção de plataforma de implantação (Vercel vercel.json, Cloudflare Páginas _headers, Netlify _headers, Next.js middleware).

Integrações de terceiros e APIs (5 itens)

Cada script que você inclui é uma isenção CSP e uma superfície potencial da cadeia de suprimentos. Trate terceiros como parte do seu limite de confiança.

PRE — Reverse-proxy analytics where possible. PostHog, Plausível, Umami suportam proxy através de seu próprio domínio (e.g. /api/posthog). Isso mantém connect-src na mesma origem e sobrevive aos bloqueadores de anúncios.
PRE — CSP-allowlist the rest. Para Google Analytics, Stripe.js, Sentry, Intercom, GTM, etc., adicione as origens de cada fornecedor à diretiva CSP correspondente (script-src para carregadores, connect-src para telemetria, frame-src para iframes, img-src para pixels).
PRE — Use Stripe Checkout, not raw card forms. Stripe Checkout é um redirecionamento de nível superior; nenhuma entrada CSP necessária para o script. A superfície PCI hospedada reside inteiramente no domínio de Stripe. Faça o seu próprio apenas se tiver um motivo forte.
PRE — Lock package-lock.json in CI. Execute npm ci (não npm install) em compilações de produção. Audite as dependências com npm audit ou Snyk antes de cada lançamento.
POST — Watch discovery.tech-fingerprint. A descoberta passiva da pilha de tecnologia apresenta versões da biblioteca visíveis para um rastreador. Se você enviar um EOL React, jQuery ou Bootstrap, FixVibe sinaliza-o e vincula-o a CVEs conhecidos.

Higiene e infraestrutura de implantação (8 itens)

A forma como você implanta é tão importante quanto o que você implanta. AI-aplicativos codificados se beneficiam especialmente da proteção de implantação explícita.

PRE — Disable x-powered-by. Em next.config.js: poweredByHeader: false. Remove um sinal de divulgação de versão gratuita.
PRE — Confirm middleware lives at src/middleware.ts. Com o layout de diretório src/, Next.js ignora um middleware.ts de nível raiz. O middleware mal colocado falha silenciosamente em definir CSP / cabeçalhos de autenticação / limites de taxa.
PRE — Sanity-check Vercel deployment protection. Proa redução deve ser pública; A visualização deve ser protegida por senha ou limitada aos membros da organização. discovery.platform-vercel relata a superfície.
PRE — Block dotfile and config probes at the edge. Adicione uma regra de reescrita ou negação para padrões /.env, /.git/*, /.aws/*, /.next/trace. Vercel retorna 403 para muitos deles por padrão; verificação cruzada.
DEPLOY — Separate environments. Produção, visualização, desenvolvimento. Cada um recebe seu próprio conjunto de segredos. As teclas ativas nunca alcançam a visualização, o modo de teste Stripe nunca atinge a Produção.
DEPLOY — Enable Vercel Web Application Firewall. Pro e os planos Enterprise incluem WAF com regras gerenciadas. Cloudflare Pages tem modo Bot Fight. Ambos reduzem o abuso do scanner automatizado e a carga de pulverização de senhas.
POST — Verify TLS configuration. SSL Labs ou testssl.sh em seu domínio de produção. TLS 1.2 mínimo, prefira TLS 1.3, sem cifras fracas, HSTS pré-carregamento elegível.
POST — Confirm health-check endpoints are minimal. Um /api/health deve retornar 200 OK sem corpo. Não faça eco do ambiente, crie hash ou implante carimbo de data/hora sem autenticação.

Monitoramento contínuo e nova verificação (4 itens)

A segurança não é uma auditoria única pré-navio. O desvio acontece em cada implantação.

Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT ou HTTP verificação de arquivo. Isso desbloqueia novas verificações agendadas, investigação ativa e monitoramento de ameaças ao vivo.
Schedule passive re-scans. Pro os planos suportam cadência de 3 horas; Unlimited suporta cadência de 6 horas. Cada verificação agendada que revela uma nova descoberta aciona um e-mail (e um webhook, se você tiver conectado um).
Wire outbound webhooks. Account → Webhooks → adicione um endpoint HTTPS, inscreva-se em scan.completed + finding.created + scan.active_api.first_used. Direcione para Slack/Discord/PagerDuty.
Enable live threat monitoring on Unlimited. Diferenças de log de transparência de certificados, DNS alterações, JS vazamentos de segredos de pacotes, listagens de informações de ameaças - acionados no momento em que são detectados, não na próxima verificação agendada.

Próximas etapas

Quer o pano de fundo educacional sobre por que esses itens são importantes? Leia AI-generated code security scanning. Quer trechos de código concretos para cada etapa de proteção? Consulte How to secure an app built with AI coding tools.