FixVibe

// docs / security guides / pre-ship checklist

Checklist de segurança vibe coding: 51 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 = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

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:

  1. 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').
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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 in JavaScript Bundles captura chaves que caíram em localStorage ou sessionStorage através do uso indevido de SDK.
  8. 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.

  1. PRE — Enable RLS on every public.* table. In Supabase: each table needs ALTER TABLE ... ENABLE ROW LEVEL SECURITY plus explicit policies for each role. RLS is what stops the anon and authenticated API roles; FORCE ROW LEVEL SECURITY only extends it to the table owner and is optional defence in depth.
  2. 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.
  3. 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;
  4. 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.
  5. 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.
  6. POST — Run an active scan against a verified domain. A verificação ativa Supabase Row-Level Security 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().

  1. 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().
  2. 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.
  3. 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ê.
  4. 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.
  5. 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.
  6. 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.
  7. POST — Active probe. As verificações Auth Flow Defects e 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. POST — Run HTTP 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.

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. POST — Watch Technology Fingerprinting. 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.

  1. PRE — Disable x-powered-by. Em next.config.js: poweredByHeader: false. Remove um sinal de divulgação de versão gratuita.
  2. 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.
  3. 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. Vercel-Specific Exposure relata a superfície.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

  1. Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT or HTTP file verification. Active scans require Hobby or above, scheduled scans require Pro or Unlimited, and live threat monitoring requires Unlimited.
  2. Schedule passive re-scans on Pro or Unlimited. Choose an available cadence for your verified domain. Scheduled runs share your scan allowance; enable completion notifications and signed webhooks as needed. A scheduled scan observes the app at run time, not continuously.
  3. 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.
  4. Enable live threat monitoring on Unlimited. Periodic certificate, DNS, bundle, and threat-intelligence checks can surface changes between scheduled scans. Coverage and alert timing depend on the signal and successful polling.

Replit Agent

If you build with Replit Agent, also check:

  1. Don't paste keys into the Agent prompt. Add them in Secrets and give the Agent the variable name instead, so the value never appears in generated code or chat history.
  2. Test CORS on the production domain. The preview pane and your deployed URL are different origins. Check your CORS allowlist against the domain users actually load.
  3. Replit Agent sometimes hardcodes test values. O Agente pode gerar código com API_URL = 'http://localhost:5000</code>. Antes do envio, substitua por <code>os.environ[API_URL'].

Firebase Studio

If you build with Firebase Studio, also check:

  1. Test-mode rules are temporary by intent, not by default. Test mode lets anyone read and overwrite data. If the generated rule carries a date cutoff, client access stops on that date; if not, the database stays open. Replace test rules before launch either way.
  2. Security rules protect data, not Hosting. Firestore and Storage rules don't govern what Firebase Hosting serves: everything in the public directory is public. Keep exports, backups and admin pages out of it.

Claude Code

If you build with Claude Code, also check:

  1. PRE — Keep personal Claude Code settings out of git. Commit .claude/settings.json for shared project settings, but keep .claude/settings.local.json out of the repo: Claude Code excludes it from git when it creates the file, so check it if you created it by hand. Session history lives in ~/.claude, outside the project (Claude Code docs).
  2. Bash operations are unverified. Claude Code executa comandos bash diretamente. git commit -m "fix" é conveniente, mas se o diretório de trabalho tiver um arquivo .env e um glob o incluir, ele será confirmado. Sempre revise git diff --cached antes de Claude Code confirmar.

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.

// escaneie seu app

Pare de ler. Comece a encontrar as falhas no seu.

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • Free tier — 3 scans / mês, sem cartão.
  • Scans passivos contra qualquer URL — sem verificação de domínio.
  • Afinado para Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Rodar um scan grátis →

sem cadastro

Checklist de segurança vibe coding: 51 itens antes do deploy · FixVibe