Five posts, one root cause: conflating data with code. The same mistake is carried into a different interpreter each time — the SQL database, the browser DOM, the template engine, the OS shell, and the XML parser. Django parameterises or escapes most of these by default; every post studies the escape hatch a developer reaches for when the safe default gets in the way.

Five posts on a single failure: the app authenticates who you are but never enforces what you may touch. Django hands you authentication primitives (login_required, is_authenticated) and leaves object-level and field-level authorization to you — every post is a place that gap opens.

Seven posts on the front door: proving who a user is, and keeping that proof safe. Django's auth framework ships strong primitives — password hashing, session-key rotation on login, HMAC reset tokens — but leaves rate limiting, MFA, and token / OAuth wiring to the developer and the ecosystem.

Four posts on protecting data at rest, in transit, and the secret that underpins both. Django ships strong defaults (PBKDF2 hashing, a complete SECURE_* settings surface), so every post is a study of the moment a developer overrides a default, forgets a flag, or commits a secret.

Five posts on getting the defaults and the deployment right. Django ships safe defaults for much of this — X-Frame-Options: DENY, a full SECURE_* surface — so the failures are the flags a developer flips off, the header they never add, and the third-party tool they misconfigure.

One post on trusting a payload the app should have treated as hostile. Django ships the right primitives — a JSON session serializer by default and django.core.signing for integrity — so the vulnerability is the developer who reaches for pickle or hand-rolls a token.

Two posts on the application mishandling its own resources under adversarial load. Both stay in scope precisely because Django ships concrete primitives — select_for_update(), F(), DATA_UPLOAD_MAX_*, throttling — that make the vulnerable-to-secure pair real.

One post on the observability layer, kept strictly to what the developer owns: log injection (untrusted input forging log lines) and sensitive data leaking into logs. Monitoring strategy belongs to the SOC and stays a sidebar.

Three posts on making the server act against itself or its users. Django hands you ALLOWED_HOSTS, url_has_allowed_host_and_scheme() and URLValidator — so every failure here is trusting a user-supplied URL or the request Host without validation.

One capstone post. The OWASP API Security Top 10 is not a new set of attacks — it is the earlier series re-expressed for APIs, where Django REST Framework's convenience defaults amplify every access-control mistake.

One coda post, anchored to a concrete Django-reachable exploit — a Pillow CVE reached through an ImageField upload, a PyJWT algorithm confusion — with software composition analysis (pip-audit, Dependabot, an SBOM) as how you catch them first.