Cinco posts, uma única causa raiz: confundir dado com código. O mesmo erro é levado a um interpretador diferente a cada vez — o banco SQL, o DOM do navegador, o motor de templates, o shell do sistema e o parser de XML. O Django parametriza ou escapa a maior parte disso por padrão; cada post estuda a válvula de escape que o desenvolvedor usa quando o padrão seguro atrapalha.

Cinco posts sobre uma única falha: a aplicação autentica quem você é, mas nunca impõe o que você pode tocar. O Django entrega primitivas de autenticação (login_required, is_authenticated) e deixa a autorização em nível de objeto e de campo por sua conta — cada post é um lugar onde essa lacuna se abre.

Sete posts sobre a porta de entrada: provar quem é o usuário e manter essa prova a salvo. O framework de auth do Django traz primitivas fortes — hashing de senha, rotação da chave de sessão no login, tokens de redefinição com HMAC —, mas deixa rate limiting, MFA e a integração de tokens / OAuth para o desenvolvedor e o ecossistema.

Quatro posts sobre proteger dados em repouso, em trânsito e o segredo que sustenta os dois. O Django traz padrões fortes (hashing PBKDF2, uma superfície completa de configurações SECURE_*), então cada post estuda o momento em que o desenvolvedor sobrescreve um padrão, esquece uma flag ou comita um segredo.

Cinco posts sobre acertar os padrões e o deploy. O Django já traz padrões seguros para boa parte disso — X-Frame-Options: DENY, uma superfície SECURE_* completa —, então as falhas são as flags que o desenvolvedor desliga, o cabeçalho que nunca adiciona e a ferramenta de terceiros que configura errado.

Um post sobre confiar em um payload que a aplicação deveria tratar como hostil. O Django traz as primitivas certas — serializer de sessão em JSON por padrão e django.core.signing para integridade —, então a vulnerabilidade é o desenvolvedor que recorre ao pickle ou inventa o próprio token.

Dois posts sobre a aplicação lidando mal com os próprios recursos sob carga hostil. Os dois permanecem no escopo justamente porque o Django traz primitivas concretas — select_for_update(), F(), DATA_UPLOAD_MAX_*, throttling — que tornam real o par vulnerável-para-seguro.

Um post sobre a camada de observabilidade, restrito ao que é do desenvolvedor: log injection (entrada não confiável forjando linhas de log) e dados sensíveis vazando para os logs. Estratégia de monitoramento é do SOC e fica como nota lateral.

Três posts sobre fazer o servidor agir contra si mesmo ou contra seus usuários. O Django entrega ALLOWED_HOSTS, url_has_allowed_host_and_scheme() e URLValidator — então toda falha aqui é confiar em uma URL enviada pelo usuário ou no Host da requisição sem validar.

Um post de síntese. O OWASP API Security Top 10 não é um conjunto novo de ataques — é a série anterior reexpressa para APIs, onde os padrões de conveniência do Django REST Framework amplificam cada erro de controle de acesso.

Um post de encerramento, ancorado em um exploit concreto e alcançável pelo Django — uma CVE do Pillow via upload em ImageField, confusão de algoritmo no PyJWT — com análise de composição de software (pip-audit, Dependabot, SBOM) como a forma de detectá-los primeiro.