VulnStrike | ExpoStacker

PRODUTO EM PRODUÇÃO

vulnstrike.expostacker.com.br/

live preview

VulnStrike — nota de segurança do seu site em 30 segundos

Usar agora Arquitetura

Stack tecnológica: Next.js 15 React 19 TypeScript Supabase Cloudflare Workers Tailwind

50+
Verificações: ~30s
Scan grátis: A+–F
Nota clara

Cliente

VulnStrike

Setor

Cybersecurity — SaaS / Segurança defensiva

Linha do tempo

Produto lançado · Set 2026

Produto ao vivo

Usar agora

Resultados

Resultados reportados pelo cliente durante o rollout

50+ Verificações por scan

~30 s Tempo do scan grátis

0 Dependências de servidor

Dados reportados pelo cliente

O desafio

VulnStrike resolve a pergunta que todo dono de site tem e nenhuma ferramenta responde em português claro: "meu site tá exposto?" A resposta vem como uma nota de escola — A+ a F — com cada problema explicado e a correção do lado.

DASTs enterprise (Acunetix, Nessus) custam caro e falam inglês técnico; ferramentas gratuitas exigem conhecimento de segurança para interpretar. O dono de site comum não sabe nem se os headers básicos estão configurados. O desafio: transformar dezenas de verificações técnicas em uma nota compreensível, com instrução de correção em português.

A abordagem

A solução foi dividir o scan em dois níveis com uma fronteira de autorização: o scan público é 100% passivo — só lê o que qualquer visitante já vê (headers, DNS, HTML público, certificados públicos). O scan profundo, que testa arquivos sensíveis como /.env e /.git/HEAD, exige prova de propriedade via arquivo .well-known ou DNS TXT. Somado a isso: blacklist de infra crítica (governo, bancos, saúde), guarda anti-SSRF que resolve o DNS e bloqueia IPs privados antes de qualquer requisição, e rate limit por IP no scan anônimo.

A solução

O produto cobre o ciclo completo de segurança de um site:

Scan grátis anônimo na home — passivo, sem cadastro, resultado em ~30s
Nota A+–F com score estilo Observatory e breakdown por severidade
Scan profundo com verificação de propriedade (arquivo .well-known ou DNS TXT)
26 arquivos sensíveis verificados: .env, .git/HEAD, dumps SQL, chaves SSH, actuator, backups
DNS completo: SPF, DMARC, MX, CAA — com política analisada (não só presença)
Relatório público compartilhável por link — revogável a qualquer momento
PDF imprimível com white-label para agências
Scans agendados (diário/semanal) com alerta de novas vulnerabilidades
Comparação antes/depois entre scans do mesmo domínio
Billing Mercado Pago (Pix/cartão) com webhook e ativação automática
Trial de 14 dias do Pro sem cartão + lifecycle de expiração automático
Blacklist de infra crítica + SSRF guard — escaneie só o que é seu
Motor de verificação em lab: pipeline de 16 fases validado — SQLi provada com evidência, não só alerta
Scan autenticado com sessão capturada — compara automaticamente o que só aparece logado
Extração profunda de SPA: rotas internas, bundles JS, operações GraphQL e APIs cross-host

Linha do tempo

Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.

Metodologia

Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.

Reposicionamento: framework ofensivo → SaaS defensivo (módulos de exploit removidos do público)

Scanner edge: checks passivos (headers/DNS/certificados) + profundo com verificação

Anti-abuso por design: blacklist de infra crítica, SSRF guard, rate limit por IP

Score estilo Observatory: penalidade por severidade + bônus por boas práticas

Billing Mercado Pago com webhook HMAC e trial de 14 dias automático

Identidade cyan/radar gerada com IA (11 assets) + dogfooding dos próprios headers

Validação: jornada completa em prod — cadastro, scan, relatório público, deep scan verificado

Arquitetura

→ Next.js 15 + React 19 com OpenNext rodando em Cloudflare Workers
→ Scanner pipeline: DNS-over-HTTPS + crt.sh (Certificate Transparency) para recon de domínio
→ Supabase dedicado com RLS — cada scan isolado por tenant
→ Relatório técnico com score, priorização de achados e evidências
→ Mercado Pago para cobrança por scan; Resend + Turnstile para e-mail e anti-bot

Diagrama conceitual — não reflete implementação real

Stack tecnológica

Escolhas técnicas e o que ficou para fora.

Decision log

O que escolhi, o que rejeitei e por quê.

Scan público 100% passivo, profundo atrás de verificação

Por que: Testar /.env e /.git em qualquer domínio sem prova de propriedade é reconhecimento ofensivo — invendável e eticamente errado. A fronteira de autorização é o que separa ferramenta defensiva de arma.

Alternativas rejeitadas: Scan profundo livre com disclaimer (rejeitado — disclaimer não impede abuso); só passivo sem profundo (rejeitado — perde o valor real do produto).

Nota A+–F em vez de lista crua de achados

Por que: O público-alvo não é o pentester — é o dono de site. Uma nota de escola comunica urgência instantaneamente e cria a métrica que o cliente quer melhorar ("tirei D, quero A").

Alternativas rejeitadas: Score 0-100 puro (rejeitado — menos intuitivo); só lista de achados (rejeitado — sem narrativa de progresso).

SSRF guard obrigatório antes de qualquer fetch

Por que: Um scanner que aceita qualquer alvo pode ser usado para mapear rede interna — 169.254.169.254, 10.x, localhost. O scan resolve o DNS primeiro e aborta se o IP for privado/metadata.

Alternativas rejeitadas: Bloquear só strings de IP (rejeitado — DNS pode apontar domínio público pra IP interno); confiar no input (rejeitado — SSRF clássico).

Edge (Workers) em vez de servidor para o scanner

Por que: Cada verificação é um HTTP GET independente — perfeito para fetch paralelo no edge. O limite de 50 subrequests do Workers free forçou curadoria: 26 arquivos de maior valor em vez de centenas.

Alternativas rejeitadas: Node server tradicional (rejeitado — custo e deploy); Cloudflare Queue para scan assíncrono (roadmap — para scans ainda mais profundos).

Motor de prova separado do scanner edge

Por que: Concorrentes reportam 'possível vulnerabilidade'. Nós provamos: o motor de lab executa o pipeline completo (16 fases — crawler, fuzzing, SQLi com evidência, extração autenticada) e só reporta o que é confirmável. É o que sustenta o marketing 'achados verificados'.

Alternativas rejeitadas: Só scan passivo no edge (rejeitado — não diferencia do Mozilla Observatory); sqlmap direto no cliente (rejeitado — exige backend worker, não edge).

Segurança e acesso

Defesa por design

Scan público anônimo = somente verificações passivas (headers, DNS, HTML público)
Scan profundo exige prova de propriedade (arquivo .well-known ou DNS TXT)
Blacklist de infra crítica: governo, bancos, saúde, educação, IPs privados
SSRF guard: resolve o DNS e bloqueia IPs privados/metadata antes de qualquer fetch
Rate limit por IP (3 scans/dia) + Turnstile quando configurado
RLS em todas as tabelas; service role só no servidor; cookies HttpOnly+Secure+SameSite
O próprio site responde com HSTS, CSP, X-Frame-Options, nosniff — dogfooding

Lições aprendidas

Nem tudo saiu como planejado.

— A fronteira ética é o feature mais importante: o que diferencia um scanner comercial de uma ferramenta de ataque é exatamente onde ele se recusa a ir. E no edge, o limite de subrequests é a arquitetura — 26 checks curados valem mais que 200 genéricos.

StackPost

StackPost — API Unificada de Redes Sociais

API unificada de redes sociais multi-tenant com 19 integrações, 114 endpoints REST, OAuth centralizado, agendamento, analytics e comentários.

Ver case →

Nexus IA

Nexus IA — Plataforma de IA

Plataforma de IA com 620+ endpoints REST, Nexus Auto com roteamento automático entre 20+ modelos, workspace com agente autônomo, multimodal e 6 planos comerciais.

Ver case →