Nossa própria auditoria
Estes são os achados que nossa ferramenta produz quando audita o nosso próprio site — e o que fizemos sobre cada um.
Toda ferramenta de auditoria tem um conflito de interesse: quem a constrói controla os pesos e pode ajustá-los até o próprio site passar. Por isso, uma nota de aprovação no nosso próprio site não provaria nada.
Esta página faz o contrário. Ela registra, com datas, onde o nosso próprio site reprova nas verificações que vendemos. Uma entrada permanece aqui depois de corrigida, com as duas datas — a do achado e a da resolução. Mantemos as falhas no registro; apagá-las destruiria o sentido da peça.
Rodamos esta auditoria no nosso próprio site enquanto o construímos, e corrigimos achados antes que cheguem a alguém. Quando rodamos nossa auditoria gratuita no nosso próprio site em 1 de agosto de 2026, ele tirou 96 de 100 — e, das 31 verificações, a única que reprovava era a Content-Security-Policy registrada abaixo. Essa também já foi resolvida, então os quatro registros a seguir trazem as duas datas.
Nossas verificações de acessibilidade aprovavam por presença de string, não por elemento
Achado: 31 de julho de 2026
- O quê. Rodadas em páginas reais, nossas cinco verificações de acessibilidade aprovavam sempre que o atributo relevante aparecia em qualquer lugar do HTML. Um único atributo alt, em qualquer imagem, marcava a página inteira como aprovada. Era um falso positivo, não um falso negativo — o site devolvia uma aprovação que não era verdade, justamente nas verificações que o produto vende.
- Por quê. As verificações testavam a presença de uma string no código-fonte da página em vez de inspecionar cada elemento. Medida contra o axe-core em três páginas reais, a sobreposição foi zero: em css-tricks.com nosso motor reportava o texto alternativo das imagens como aprovado com 7 imagens sem alt, e os marcos semânticos como aprovados com 120 nós fora de qualquer landmark.
- Plano. Reescrevemos as cinco verificações para conferir cada elemento em vez de casar uma string, no card DEV-236. Corrigir um falso-passe derruba notas, e derrubou: em css-tricks.com a nota de acessibilidade caiu de 100 para 50 e a nota total de 87 para 79 — o mesmo para as nossas próprias auditorias. Registramos isso porque é a prova mais direta de que não ajustamos notas para agradar: a correção moveu o número para baixo.
Resolução: 31 de julho de 2026. Um limite honesto permanece, em aberto no card DEV-238: o relatório entrega o veredito — aprovado ou reprovado — sem a contagem por trás dele. Ele diz que uma verificação reprovou, mas ainda não quantos itens reprovaram. Publicar a correção sem nomear esse limite venderia mais do que o produto entrega hoje.
Nossa Content-Security-Policy reprovava na nossa própria auditoria
Achado: 1 de agosto de 2026
- O quê. Rodada no nosso próprio site, nossa verificação de Segurança para Content-Security-Policy (CSP) retornava reprovação.
- Por quê. A política que servíamos dependia de 'unsafe-inline' nas diretivas de script e de estilo (e de 'unsafe-eval' para scripts). Essas permissões enfraqueciam a proteção que uma CSP existe para dar, então a verificação não passava. O cabeçalho estava presente; ele era apenas permissivo demais para contar como aprovação.
- Plano. Estamos endurecendo a política no card DEV-193. A remoção do Google Tag Manager (já feita) faz com que a política mais restritiva não precise mais de um nonce por requisição — a parte cara e arriscada da correção. Prazo: dentro de 30 dias desta entrada, até 31 de agosto de 2026.
Resolução: 30 de agosto de 2026. A política que servimos agora só admite script por um nonce cunhado a cada requisição — script-src 'self' 'nonce-…' 'strict-dynamic' — sem 'unsafe-inline', sem 'unsafe-eval' e sem o coringa que deixava carregar script de qualquer origem https. Conferimos como um cliente conferiria: a nossa própria auditoria, rodada contra o site publicado e não contra o arquivo de configuração, aprova esta verificação. Duas correções ficam à vista, em vez de uma edição silenciosa no plano acima. O plano errou sobre o nonce: tirar o Google Tag Manager não tirou os scripts inline, porque o framework em que construímos escreve os próprios em toda página — 33 das 35 tags de script da nossa home são dele, e cada uma agora leva o nonce. E a correção é parcial num ponto que não vamos esconder: a nova política não restringe estilo nenhum. Uma CSP não tem como permitir um atributo style inline a não ser pelo próprio 'unsafe-inline' — a permissão de que esta entrada trata — e os componentes de interface que usamos escrevem esses atributos enquanto a página roda. Então nossos scripts estão trancados e nossos estilos não. Script executa, estilo não — foi por isso que fizemos a troca; mas é uma troca, e o lugar dela é aqui.
Nosso detector de tecnologias reportava tecnologias que não estavam lá
Achado: 27 de julho de 2026
- O quê. Nosso detector de tecnologias nomeava tecnologias que um site não usava. Em um relatório pago listou nove, e apenas duas eram reais — errava sete de nove. Como o Guia de IA lia essa lista, ele chegou a recomendar instalar um gerenciador de tags em um site que não tinha nenhum.
- Por quê. O detector casava texto exibido na página em vez da infraestrutura por trás dela — casava substrings em prosa corrida e, em um caso, leu a lista de tecnologias impressa de outro site como se fossem as deste. Não foi uma assinatura ruim; foi um limite do método. Uma análise que não executa JavaScript não enxerga o que um site de fato carrega em tempo de execução.
- Plano. Como a causa era o método e não uma regra, desligamos a capacidade em vez de remendá-la, no card DEV-223 — a exibição, a alimentação do Guia de IA e a menção comercial no paywall, nos três idiomas. Desligar a entrega significou remover a promessa junto.
Resolução: 31 de julho de 2026.
O relatório de um cliente podia ser indexado por mecanismos de busca
Achado: 27 de julho de 2026
- O quê. A rota do relatório pago era servida sem uma diretiva noindex, então o relatório de um cliente — que nomeia a URL auditada e seus achados de segurança — podia aparecer em resultados de busca.
- Por quê. A rota herdava os metadados padrão do site, que permitem indexação, e nunca os sobrescrevia. O relatório existe para ter um link permanente e compartilhável; nunca foi feito para ser descoberto em busca.
- Plano. Acrescentamos noindex à rota do relatório e removemos a tag canonical que apontava os relatórios do staging para o domínio de produção, no card DEV-222. O link do relatório continua permanente e compartilhável, e agora não é indexável.
Resolução: 28 de julho de 2026.
Se a data de um plano passar antes de a correção entrar no ar, esta entrada será atualizada com o motivo e uma nova data — nunca removida em silêncio.
Veja os achados do seu próprio site
Rode a mesma auditoria no seu site.
Auditar meu site