Remediação de segurança — agosto de 2026
Esta página registra a implementação verificada dos cinco achados da auditoria de segurança de agosto de 2026. O código e os resultados do CI são a fonte de verdade; nenhum achado é marcado como corrigido apenas porque o código mudou.
| Achado | Issue | Pull request | Status | Release |
|---|---|---|---|---|
| SEC-001 — isolamento por biblioteca | araru-server#13, follow-up #22 | #16, #23 | Corrigido | Server v0.2.3 |
| SEC-002 — bypass de autorização em testes | araru-server#14 | #18 | Corrigido | Server v0.2.3 |
| SEC-003 — defaults do Compose de desenvolvimento | araru-server#15 | #20 | Corrigido | Server v0.2.3 |
| SEC-004/005 — sanitização do reader | araru-web#17 | #18 | Corrigido | Web v0.2.1 |
A automação de regressão de segurança foi integrada separadamente no PR #21 do Server e no PR #20 do Web. Todos os checks aplicáveis do Actions passaram.
Controles implementados
Seção intitulada “Controles implementados”- A autorização do Server agora deriva as bibliotecas acessíveis de forma centralizada e aplica o escopo ao catálogo, recentes, home, busca, autores, séries, detalhes de obra e recursos de leitura/conteúdo. Administradores continuam com escopo global;
libraryIdenviado pelo cliente é apenas filtro, nunca autorização. - Conteúdo EPUB e MOBI passa por sanitização HTML centralizada com DOMPurify e validação de esquema de URL antes dos dois sinks HTML do reader. Elementos ativos, handlers inline, SVG inline e esquemas perigosos são removidos; links externos recebem
noopener noreferrer. - A autorização administrativa não faz mais bypass para nenhum
NODE_ENV. O harness de testes usa fixtures autenticadas explícitas, e o acesso administrativo anônimo possui teste de regressão. - O Compose de desenvolvimento exige
POSTGRES_PASSWORDeREDIS_PASSWORD, habilita autenticação do Redis, mantém portas de serviço internas por padrão e oferece override explícito limitado a localhost para debug. - O CI executa testes dedicados de segurança do Server, testes de segurança do reader Web e um guard de sinks HTML que exige
sanitizeReaderHtml.
Evidências de validação
Seção intitulada “Evidências de validação”A validação do Server passou: npm test (40 testes), npm run security:test, npm run lint, npm run build e docker compose config com credenciais fortes de teste. A validação do Web passou: npm test (23 testes), npm run security:test, npm run security:check, npm run typecheck, npm run lint e npm run build.
Não foi necessária migration de banco. O araru-design não foi alterado porque nenhum padrão de interface reutilizável foi introduzido. O workflow de release do Server publicou v0.2.3; a correção do reader está incluída em v0.2.1 do Web, enquanto a automação de CI, somente de testes, não altera a release de runtime.
Verificações operacionais restantes
Seção intitulada “Verificações operacionais restantes”O build e o deploy da documentação devem continuar verdes depois do merge desta página. Operadores devem fornecer secrets fortes pelo mecanismo de secrets do ambiente e não devem usar o Compose de desenvolvimento como deployment público.