Protecting Django Applications from Automated Abuse

Django's middleware stack processes every request before it reaches a view. Security middleware added early in the MIDDLEWARE list can evaluate a request and return a response without the view ever executing.

This is the correct layer for trust enforcement. A request blocked in middleware consumes no database connections, no ORM queries, and no view rendering — the most efficient possible outcome for an abusive request.

Most Django applications contain both public content routes and sensitive action routes. Applying trust enforcement to every request adds unnecessary latency on safe paths.

Middleware can inspect request.path and apply trust evaluation only to paths matching an enforced list. Alternatively, a decorator-based approach applies trust checks per view for finer-grained control. Both patterns are compatible with Django's class-based and function-based view styles.

Network exceptions and API timeouts should result in the request being passed to the view rather than blocked. A trust API that is temporarily unavailable should not take your login page offline.

CHALLENGE responses redirect to a hosted challenge URL. BLOCK responses return an HttpResponse with status 403. The response body for blocked requests should be minimal and not expose the reason for the block to the requester.