Django vulnerability classes

Django's ORM binds every value for you, so SQL injection in a Django project comes from the handful of APIs that accept SQL text, and from request keys that are allowed to choose column names.

Django never runs a shell for you, so command injection in a Django project is always application code calling subprocess or os.system(), usually in a place that was written for an operator and later became reachable from a request.

Django is built on dotted-path strings and attribute names, so code injection in a Django project is less often a literal eval() and more often a request value used where the framework expects a name.

Django templates loaded by name from disk are developer code; template injection starts when a view compiles a string that a user wrote, most often an email or notification template stored in the database.

A typical Django view never calls pickle.loads(), yet pickle is running under most Django sites, in the cache framework and sometimes in the task queue, so the question is who can write to those stores.

Django's storage API handles upload names for you, so path traversal in a Django project usually comes from a download or export view that builds a filesystem path by hand and returns it with FileResponse.

In Django the URL that causes an SSRF has usually passed form validation, because Django's URL validation answers "is this a URL" and was never meant to answer "is this a safe place for my server to connect to".

Django runs developer-written regular expressions against attacker-chosen strings on every request, in URL routing and in validation, so one pattern with nested repetition can let a single request hold a worker for seconds.