Implementation of Native Rate Limiting Middleware(GSOC 2026 Draft)

GSoC 2026 Proposal: Enhancing Django Security via Native Rate Limiting Middleware

  • Candidate: Cai Hesen
  • Affiliation: University of Chinese Academy of Sciences (UCAS)
  • Project Size: 175 Hours (Medium)
  • Primary Focus: Security, Middleware, Async Performance

1. Abstract

While Django provides robust security out of the box, it currently lacks a native, standardized mechanism for Rate Limiting (Throttling). Developers often rely on fragmented third-party libraries or custom logic, leading to inconsistent security postures. This project aims to implement a high-performance, pluggable RateLimitMiddleware directly into Django Core, providing first-class support for both synchronous and asynchronous (ASGI) workflows.

2. Motivation

Modern web applications face constant automated threats: brute-force logins, API scraping, and DoS attacks.

  • The Problem: Current solutions (e.g., django-ratelimit) are excellent but external. This creates a barrier to entry for “secure by default” development.
  • The Opportunity: By integrating rate limiting into the core, we can leverage Django’s existing Cache Framework and its Async capabilities to provide a seamless, performant experience that scales from small blogs to high-traffic APIs.

3. Technical Implementation Plan

3.1 Core Architecture

The implementation will reside in django.middleware.security and follow Django’s pluggable philosophy.

  • Storage Backend: Utilize django.core.cache for distributed state management, ensuring compatibility with Redis, Memcached, and Database backends.
  • Identification Logic: The middleware will identify clients based on a configurable hierarchy:
    • Remote-Addr (IP-based) for anonymous traffic.
    • request.user.pk for authenticated sessions.
    • Custom headers (e.g., X-API-Key) for headless services.

3.2 Algorithm Selection

I propose a dual-algorithm approach:

  1. Fixed Window Counter: The baseline for simplicity and low latency.
  2. Sliding Window Log/Counter: An extensible option to mitigate “boundary bursts” (where a user doubles their limit at the edge of a window).

3.3 Proposed Configuration (settings.py)

RATE_LIMIT_RULES = {
    "default": {"WINDOW": 60, "LIMIT": 100},  # 100 requests per minute
    "django.contrib.auth.views.LoginView": {
        "WINDOW": 300, 
        "LIMIT": 5,
        "METHODS": ["POST"]
    },
}`

3.4 Async & ASGI Compatibility

To ensure zero regression in performance, the middleware will be implemented as “Asynchronous-capable.” By avoiding blocking I/O calls during the cache check (using await cache.aget()), we ensure that async-heavy applications maintain their non-blocking nature.


4. Project Roadmap (12 Weeks)

Phase Timeline Key Milestones & Deliverables
I. Community Bonding Week 1-2 Finalize the DEP (Django Enhancement Proposal) and align on configuration syntax via the Django Forum.
II. Core Development Week 3-6 Implement RateLimitMiddleware, cache key generation, and standard HTTP 429 (Too Many Requests) response handling.
III. Advanced Features Week 7-9 Develop @ratelimit decorators for view-level control; implement IP-whitelisting and “Exempt” logic.
IV. QA & Documentation Week 10-12 Achieve 100% test coverage; write official Sphinx/reST documentation; refine code based on mentor feedback.

5. Expected Outcomes

  1. RateLimitMiddleware: A battle-tested middleware integrated into Django core.
  2. Fine-grained Control: Decorators to allow developers to override global limits on specific views.
  3. Comprehensive Docs: Security best practices and a migration guide for users moving from third-party apps.
  4. Robust Test Suite: Extensive unit and integration tests covering cache downtime and high-concurrency collisions.

6. About Me

I am a Computer Science student at the University of Chinese Academy of Sciences (UCAS) with a background in Software Engineering and Systems Programming. I have a deep interest in making web frameworks more resilient and performant. My experience ranges from implementing C++ graphics engines to building scalable Python backends, giving me a unique perspective on optimizing both low-level performance and high-level developer experience.

1 Like

I have uploaded a functional Proof of Concept (PoC) and the full technical proposal to GitHub: