Provas

"Não acredites, verifica" — levado ao limite. Tudo nesta página é gerado no build ou lido ao vivo: sem números escritos à mão, sem capturas de ecrã. Confirma cada linha por ti.

🔐 O porquê de cada verificação aqui — o que cada cabeçalho defende, o que cada camada protege — está explicado na Segurança. Ver a Segurança →

Último commit

Este site é servido a partir de main. O código que estás a ler corresponde a este commit:

commitcb439ed1f8915a0cb7f7b09325f7fb62d515579c
mensagemchore(deps): lock file maintenance (#180)
data16/09/2026, 15:16

Cabeçalhos de segurança

O contrato versionado abaixo é o que garante que a produção serve mesmo estes cabeçalhos — o mesmo verificado ao vivo pelos scanners externos ligados no fim desta página.

A lista versionada de cabeçalhos que a produção tem de servir — o workflow Headers falha se algum faltar:

cabeçalhoexige
content-security-policydefault-src 'self'script-srcobject-src 'none'frame-src 'none'worker-src 'none'base-uri 'none'form-action 'none'frame-ancestors 'none'require-trusted-types-for 'script'
strict-transport-securitymax-age=63072000includeSubDomains
x-frame-optionsDENY
x-content-type-optionsnosniff
referrer-policystrict-origin-when-cross-origin
permissions-policygeolocation=()camera=()microphone=()
cross-origin-opener-policysame-origin
cross-origin-resource-policysame-origin
cross-origin-embedder-policyrequire-corp

Vigia de Certificate Transparency

Qualquer certificado TLS emitido para este domínio — incluindo um que um atacante conseguisse emitir após um takeover de DNS ou do registrar — fica registado em logs públicos de Certificate Transparency. O Worker vigia esses logs e compara cada emissão dos últimos 90 dias com a lista de emissores esperados: um certificado que eu não pedi aparece aqui antes de poder ser usado contra mim.

O vigia ao vivo ainda não está ligado — o Worker precisa de estar publicado nas rotas do domínio. A lógica e os testes estão em dynamic/worker/.

Workflows

Estes workflows correm no GitHub Actions — a maioria a cada push para main, alguns em cron (diário/semanal) ou só numa tag de release. Verdes = build limpo, sem vulnerabilidades conhecidas, e segredos + SAST a passar.

As camadas que correm — cada uma falha o CI se encontrar algo:

ferramentao que apanha
RenovateMantém as dependências atualizadas e pina as GitHub Actions por digest SHA (proteção contra tags movidas). Corre numa janela semanal.
Dependency ReviewBloqueia PRs que introduzem uma dependência nova com vulnerabilidade conhecida, no diff do próprio PR — o gate rápido, complementar ao OSV-Scanner abaixo.
OSV-ScannerDependências com vulnerabilidades conhecidas ou marcadas como maliciosas (base OSV.dev + advisories do GitHub), lidas do lockfile.
GitleaksSegredos committados — tokens, chaves privadas — sobre a história completa do PR. Também como hook local antes de cada commit.
CodeQLAnálise semântica de segurança (SAST) do JavaScript/TypeScript — complementar ao Semgrep, outra classe de padrões.
SemgrepSAST: sinks de DOM XSS (innerHTML, document.write) nos scripts do lado do cliente e no terminal do Lab.
zizmorAuditoria dos próprios workflows: pins em falta, permissões excessivas, injeção de template em run:.
Cadeia de fornecimentoVerifica as assinaturas do registo npm e gera um SBOM (CycloneDX) dos dois lockfiles, como artefacto — semanal.
InvariantesVerifica /api/health e as rotas de leitura do Worker em produção; abre uma Issue automática se algo partir — diário.
Fuzzing (ClusterFuzzLite)Um harness cobre as duas funções do Worker que processam bytes não confiáveis — sanitizeText()/escapeHtml() (sanitizadores de output) — semanal.
Releases assinadasAssina a proveniência (Sigstore) dos artefactos de build e gera SBOM, numa GitHub Release — só ao criar uma tag v*.

Além destas, o build falha em advisories high/critical do npm audit e se a CSP do cabeçalho divergir da que viaja em cada <meta>.

Verifica tu mesmo

Não fiques pela minha palavra: