Separar cache aplicacional e HTTP
Redis, Workers KV e caches HTTP não partilham automaticamente garantias. Workers KV usa consistência eventual: uma escrita não fica imediatamente visível em todo o lado. As diretivas seguintes dizem respeito a HTTP e não configuram sozinhas a cache aplicacional.
| Diretiva de resposta HTTP | Significado principal | Limite |
|---|---|---|
| no-cache | Armazenamento permitido, validação antes do reuso. | Não significa «não armazenar». |
| no-store | Não armazenar esta resposta em caches. | Não elimina automaticamente cópias anteriores. |
| private | Sem armazenamento em cache partilhada. | Não é uma regra de autenticação. |
| max-age | Duração de frescura da resposta. | Não garante consistência de todos os dados. |
Testar a resposta certa para cada pessoa
- Defina variações de chave: recurso, parâmetros, língua e permissões. Teste que uma conta nunca recebe a resposta privada de outra.
- Especifique idade máxima, invalidação e comportamento após alteração ou eliminação. Um TTL curto não garante leituras imediatamente consistentes.
- Teste expiração simultânea, falha da cache e da origem. Agrupe atualizações quando necessário e sirva respostas expiradas apenas quando o negócio permitir.
Medir além da taxa de acertos
Acompanhe latência, erros, carga da origem e respostas incorretas ou antigas. Saldos, stock reservado e permissões podem exigir garantias diferentes de um catálogo público. Uma cache rápida não deve tornar-se fonte de verdade alternativa sem controlo.
Fontes primárias
O cache da API deve preservar as decisões de acesso.
Um cache de resposta pode tornar uma consulta incorreta rápida quando as chaves ignoram as permissões do solicitante. O risco aumenta quando um grafo combina objetos públicos e privados.
- Classifique os campos públicos, privados e dependentes de função antes do cache.
- Teste uma resposta em uma conta e solicite-a em outra.
- Invalide os resultados após alterações de permissão ou dados.
Fonte primária: OWASP — GraphQL Cheat Sheet. Método relacionado: consultar o guia prático.
Medir a atualidade dos dados da cache
Exemplo fictício: estes dados não descrevem clientes nem resultados observados.
Duas leituras são rápidas, mas uma ainda mostra disponibilidade antiga depois de a fonte mudar.
- Comparar valor, versão, local de leitura e tempo desde a alteração. Testar invalidação, expiração e acesso à fonte segundo o contrato do sistema.
- Definir a atualidade aceitável por utilização e vigiar divergências. Menor latência não demonstra coerência dos dados servidos.
Fonte primária: IETF — RFC 9111, HTTP Caching. Método relacionado: consultar o guia prático.
Subdomínios abandonados: retirar um CNAME com controlo
Associar nomes DNS a recursos controlados e encerrar dependências antes de libertar o serviço.
- Registe nome, cadeia CNAME, recurso do fornecedor e responsável. Compare DNS com o inventário da conta autorizada. Erros HTTP, NXDOMAIN ou recursos ausentes exigem análise, mas não provam possibilidade de apropriação; as proteções variam.
- Remova o apontamento ou use um destino controlado antes de libertar o recurso. Considere TTL anteriores e caches; verifique DNS autoritativo e vários resolvedores. Preserve validações de propriedade necessárias em vez de apagar todos os TXT.
- Reveja ligações, redirecionamentos, callbacks OAuth, webhooks e domínios de cookies. Se o recurso já foi libertado, corrija DNS e investigue exposição pelo processo de incidentes. Reconcilie DNS e recursos após cada remoção.
Caso de aceitação reproduzível
Exemplo fictício: estes dados não descrevem clientes nem resultados observados.
Ver dados do caso
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Decisão esperada
Exemplo fictício: portal.example aponta para um recurso eliminado. Remova o CNAME ou use um destino controlado; a ausência não prova apropriação por terceiros.
Uma página de erro prova que o subdomínio é recuperável?
Não. Confirme estado e mecanismos de reserva ou validação do fornecedor. Não reivindique recursos para demonstrar o risco.
Fonte primária: Microsoft — Prevent dangling DNS entries. Método relacionado: consultar o guia prático.
ETag, cache HTTP e alterações concorrentes
As notas detalhadas desta edição estão disponíveis em inglês.
Revalidation does not replace cache isolation
A matching If-None-Match can justify 304 for the selected representation after access checks. It does not by itself select the correct user variant.
- Separate variant selection, authorisation and validator comparison.
- Test weak and strong tags with If-None-Match: the comparison is weak.
- Read no-cache as validation before reuse, rather than no-store.
Explore ETag comparisons and the simulator →
References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
GraphQL: erros, listas e dados parciais
As notas detalhadas desta edição estão disponíveis em inglês.
GraphQL result: follow the error path
Aliases belong to the result; list indices start at zero. These details determine where a client should flag missing data.
- Compare absent data, partial data and data: null.
- Keep the original path even when a parent becomes null.
- Test permissions, quotas and interface states separately.
Explore GraphQL responses and nullability →
GraphQL Specification · September 2025 · Published edition · September 2025