| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| djangorestframework | < 3.17.2 | 3.17.2 |
While investigating Django REST Framework's request parsing behavior, I identified that DRF's high-level request.data parsing appears to bypass Django's configured DATA_UPLOAD_MAX_MEMORY_SIZE protection for application/json and application/x-www-form-urlencoded request bodies.
In the tested configurations, Django correctly raises RequestDataTooBig when applications access request.body or Django's native request.POST, but DRF successfully parses the same oversized payloads through request.data.
This behavior appears to occur because DRF passes the underlying HttpRequest object directly to parsers, which consume the request stream through Django's lower-level streaming interface rather than the guarded request.body path.
I am reporting this privately because I am unsure whether this behavior is considered part of DRF's intended security boundary, but it appears to bypass a documented Django request-size protection for common DRF request parsing paths and may have availability implications.
I verified the behavior locally using the following combinations:
For both versions, the observed behavior was:
Django request.body
→ RequestDataTooBig
Django request.POST (application/x-www-form-urlencoded)
→ RequestDataTooBig
Django request.read()
→ Reads the entire oversized request body
DRF request.data
→ Successfully parses oversized JSON and urlencoded request bodies
I also confirmed that:
multipart/form-data remains protected because DRF delegates multipart parsing to Django's multipart parser.The relevant execution flow is:
APIView
↓
rest_framework.request.Request
↓
request.data
↓
Request._load_data_and_files()
↓
Request._parse()
↓
Request._load_stream()
↓
self._stream = self._request
↓
JSONParser.parse(...)
or
FormParser.parse(...)
↓
stream.read() / json.load(...)
The important implementation detail is that DRF assigns the original Django HttpRequest object as the parser stream.
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phíUnlike request.body and Django's native form parsing, consuming the stream through HttpRequest.read() does not trigger Django's RequestDataTooBig protection.
As a result, DRF's built-in parsers successfully consume oversized request bodies that Django itself would reject through its higher-level request interfaces.
Python 3.13
Django 6.0.7
Django REST Framework 3.17.1 (also reproduced on current upstream main)
Configure:
DATA_UPLOAD_MAX_MEMORY_SIZE = 10
Create a simple DRF API view:
from rest_framework.views import APIView
from rest_framework.response import Response
class DemoView(APIView):
def post(self, request):
return Response(request.data)
Start the application.
Send an oversized JSON request:
POST /demo
Content-Type: application/json
Content-Length: >10 bytes
Example:
{
"value": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA..."
}
Observed:
HTTP 200
JSON successfully parsed
Now compare against:
request.body
Observed:
RequestDataTooBig
Likewise, compare against:
request.POST
using
application/x-www-form-urlencoded
Observed:
RequestDataTooBig
This demonstrates different enforcement depending on which request API is used.
Django documents HttpRequest.read() as a streaming interface.
DRF exposes request.data as the primary high-level request parsing API.
Currently, DRF forwards the raw Django request stream directly to parsers before any request-size validation equivalent to Django's request.body path occurs.
Consequently:
fully consume oversized request bodies despite Django's configured request-size limit.
This does not appear to introduce:
However, it may reduce the effectiveness of deployments relying on Django's DATA_UPLOAD_MAX_MEMORY_SIZE to limit request-body resource consumption.
Potential consequences include:
request.dataThe practical impact depends on deployment configuration, including:
During local testing I observed successful parsing of oversized request bodies despite the configured limit.
Representative measurements showed significantly increased memory allocation while parsing large JSON and urlencoded payloads.
I intentionally did not perform destructive concurrency testing or attempt to exhaust system resources.
Confirmed affected:
Confirmed not affected:
One possible approach would be for DRF to enforce Django's configured DATA_UPLOAD_MAX_MEMORY_SIZE before handing the raw request stream to parsers that fully materialize request bodies in memory.
This would preserve Django's configured request-size protection for the common request.data API without requiring broader changes to Django's documented streaming interface.
Affected:
I did not perform a complete historical version bisect.
I have not publicly disclosed this behavior.
I am submitting it privately in accordance with the project's security policy because I am unsure whether maintainers consider this part of DRF's intended security boundary.
Thank you for taking the time to review this report.
If you determine that this behavior should be addressed, I would be happy to help investigate further, develop a fix, add regression tests, and submit a patch if you'd find that helpful.
I have experience as a Python/Django software engineer, security researcher, and open-source contributor, and I'd be glad to contribute if you think that would be useful.