Assessment técnico
Leitura de recursos públicos, HTML inicial, metadados e cabeçalhos para produzir um diagnóstico reproduzível.
Assessment Platform · read-only
Descubra como agentes de IA enxergam seu site.
O Super Scan identifica, mede, explica e prioriza sinais observáveis na superfície digital. Ele não bloqueia agentes, não executa políticas e não governa o runtime.
O que é
Evidence Engine
Todo achado mostra o que foi observado, por que importa, como priorizar, como corrigir e quais referências consultar.
Sem efeitos no alvo
Não envia formulários, não autentica, não executa JavaScript remoto e não envia credenciais.
Como funciona
1. Informe um domínio público 2. O Super Scan coleta recursos públicos e o HTML inicial 3. Os checks produzem evidência, prioridade e recomendação 4. O relatório separa sinais observados de limitações da coleta
Modelo v3: cobertura observada
O relatório apresenta sete dimensões. Cada uma usa somente checks estáticos efetivamente executados; nenhuma mede analytics, receita, tráfego real ou controles internos.
| Dimensão | Sinais efetivamente observados |
|---|---|
| Visibilidade | /llms.txt, robots.txt para agentes, sitemap, canonical, Open Graph, Markdown e Link headers. |
| Compreensão por IA | HTML inicial, densidade, JSON-LD, estrutura de conteúdo e manifesto WebMCP público. |
| Acessibilidade | Semântica, headings, landmarks, imagens e formulários no HTML estático. |
| Conectividade | Registros DNS A/AAAA via DNS-over-HTTPS, status HTTP, cadeia de redirects e indícios de CDN nos cabeçalhos da resposta inicial. |
| Performance | Tempo total de coleta, compressão declarada, cache declarado e tamanho do HTML recebido. |
| Conversão | CTAs e jornada de formulário visíveis na página inicial; não mede conversão ou receita. |
| Exposição pública | Formulários, CSP/HSTS e outros cabeçalhos, instruções ocultas, autenticação declarada e risco em ferramentas WebMCP. |
Limite de método: a resolução DNS A/AAAA por DNS-over-HTTPS é best-effort para o relatório, mas uma resposta que aponte para endereço privado ou reservado interrompe a coleta antes do fetch. O Worker não faz inspeção de cadeia TLS/certificado nesta rota pública. Esses itens não recebem score.
O total varia por perfil (auto, content, api ou commerce) e pelo HTML observado.
Formato de cada achado
Evidência
O dado efetivamente encontrado na coleta.
Impacto e severidade
O impacto técnico é descrito por lente; a prioridade deriva do peso e da pontuação do check.
Recomendação
Uma ação específica, esforço estimado e referências como W3C, RFC, Schema.org, Google e OWASP.
O Super Scan não emite opinião sobre a operação do cliente e não usa linguagem de certeza quando a coleta estática não a suporta.
Painel de Risco E-commerce
Disponível no perfil commerce. Observa catálogo/preço, diferença de resposta por User-Agent e checkout no HTML inicial. Preço público é requisito comercial, não vulnerabilidade.
Catálogo
JSON-LD, microdata, meta tags, preço visível e links de catálogo.
User-Agent
Duas leituras GET sequenciais e identificadas. Diferença não prova rate limiting.
Checkout
CSRF, Turnstile, reCAPTCHA, honeypot e gateway de terceiros. autocomplete="off" não é defesa anti-bot.
SPAs, widgets e controles injetados na borda podem exigir auditoria em navegador.
Modo navegador
A rota pública de assessment POST /api/super-scan executa somente o modo static. O pacote CLI pode ser executado no ambiente do cliente com abs-scan https://exemplo.com --browser quando Lighthouse e um navegador Chrome/Chromium local estiverem disponíveis.
Para integrações autenticadas, POST /api/v1/browser-observations fornece uma observação renderizada isolada, sem login ou interação, e não altera o score estático. O resultado do CLI pode incluir evidência renderizada de acessibilidade e CLS identificada como mode: "browser". Nenhum dos modos autentica no alvo nem transforma o Super Scan em ferramenta de execução ou monitoramento contínuo.
Inspeção TLS no CLI
O comando abs-scan https://exemplo.com --tls --json acrescenta protocolo, cifra e metadados do certificado ao relatório local. Antes de conectar, o CLI resolve e aceita somente endereços públicos, preservando SNI. A inspeção não altera o score e não está disponível no Worker público.
Integrações autenticadas
POST /api/v1/scans e GET /api/v1/scans exigem Authorization: Bearer <API_KEY>. Essa camada opt-in mantém a coleta read-only, aplica cotas por organização e registra o histórico pertencente à própria organização.
POST /api/v1/paid-media-scans gera o PDF white-label de mídia e landing. POST /api/v1/growth-scans gera o diagnóstico integrado para a conversa comercial da agência: mídia, SEO técnico e descoberta por IA, com prioridades multicanal. Ele não afirma dependência financeira, ranking ou citação real; essas conclusões exigem dados de Ads, Analytics, Search Console e SERP.
POST /api/v1/monitors cria um monitor; GET /api/v1/monitors lista os monitores e DELETE /api/v1/monitors/{id} os desativa. O agendador executa no máximo cinco monitores em sequência e guarda a variação de score, sempre sem enviar formulário ou credencial ao alvo. Chaves são emitidas e revogadas por canal administrativo; a API pública não cria nem revela credenciais.
GET/POST /api/v1/webhooks lista ou cria notificações HTTPS por alteração de score; a criação devolve signingSecret uma única vez. Cada entrega inclui X-ABS-Timestamp e X-ABS-Signature: t=…,v1=…, HMAC-SHA-256 de timestamp.payload. O destino é revalidado contra endereço privado, redirects não são seguidos e falhas de rede/5xx recebem até três tentativas. DELETE /api/v1/webhooks/{id} as desativa. GET /api/v1/webhooks/{id}/deliveries expõe as tentativas, com status HTTP ou erro de rede; use a trilha de monitor para auditoria do scan. GET /api/v1/overview fornece a visão operacional da organização, também disponível em /operations.
Observações avançadas autenticadas
POST /api/v1/browser-observations abre uma página publicamente acessível em navegador isolado, sem login, clique, preenchimento ou envio de formulário. Retorna HTML renderizado, métricas de execução, FCP/LCP/CLS quando observáveis e resumo de recursos. A cota é de 10 observações por hora por chave e o resultado não altera o score estático.
POST /api/v1/seo-crawl percorre sequencialmente de 1 a 10 páginas do mesmo domínio, com GET estático e sem redirects automáticos. Retorna URL, status, título, canonical e páginas com erro observadas. A cota é de 5 crawls por hora por chave. SPAs, links injetados por JavaScript e fluxos autenticados ficam fora do escopo.
Limitações
O Super Scan identifica; ele não controla. Um score não garante segurança, ranking, conversão, bloqueio de automação ou conformidade. Ausência de um sinal público não prova ausência do controle no ambiente interno.
Ele não substitui WAF, identidade, policy engine, aprovação humana, enforcement de tool calls, auditoria runtime ou monitoramento operacional.
Como evoluir para ABS Core
O Super Scan mostra exposição pública e ajuda a priorizar. Quando a necessidade é controlar o que agentes podem executar dentro da operação, o próximo passo é o ABS Core Runtime Governance.
| ABS Core Super Scan | ABS Core Runtime Governance |
|---|---|
| Observa superfície pública | Intercepta ações antes da execução |
| Produz evidências e recomendações | Aplica políticas e decide ALLOW, DENY ou ESCALATE |
| Não altera o alvo | Registra decisões em trilha auditável no ambiente do cliente |
API e relatório
POST https://ass.abscore.app/api/super-scan
{ "url": "https://exemplo.com", "profile": "commerce" }A resposta contém scanId, requestId, globalScore, grade, profile, mode, pillars, dimensions, findings e commerceRisk quando aplicável. Os IDs também retornam nos headers X-Scan-ID e X-Request-ID para correlação de suporte. Cada finding possui id, pillar, title, evidence, impact, businessImpact, audience, severity, priority, recommendation, effort e references.
Limites atuais: 5 scans por minuto por IP, 10 por minuto por domínio e 60 por minuto na plataforma. Timeout de coleta: 12 segundos; HTML inicial até 2 MB e cada recurso auxiliar até 256 KB. A coleta estática pode reutilizar evidência pública por até 10 minutos (X-Scan-Cache: HIT); scans idênticos simultâneos recebem 409 com Retry-After, e um alvo com três falhas próximas entra em cooldown de cinco minutos (503). A API retorna 400 para URL inválida, 429 para limite excedido (com Retry-After: 60) e 502 para alvo inacessível ou timeout. GET /healthz confirma disponibilidade do Worker, sem consultar um alvo.