Django’s development team is strongly committed to responsible\nreporting and disclosure of security-related issues. As such, we’ve\nadopted and follow a set of policies which conform to that ideal and\nare geared toward allowing us to deliver timely security updates to\nthe official distribution of Django, as well as to third-party\ndistributions.
\nShort version: please report security issues by emailing\nsecurity@djangoproject.com.
\nMost normal bugs in Django are reported to our public Trac instance, but\ndue to the sensitive nature of security issues, we ask that they not be\npublicly reported in this fashion.
\nInstead, if you believe you’ve found something in Django which has security\nimplications, please send a description of the issue via email to\nsecurity@djangoproject.com. Mail sent to that address reaches the security\nteam.
Once you’ve submitted an issue via email, you should receive an acknowledgment\nfrom a member of the security team within 3 working days. After that, the\nsecurity team will begin their analysis. Depending on the action to be taken,\nyou may receive followup emails. It can take several weeks before the security\nteam comes to a conclusion. There is no need to chase the security team unless\nyou discover new, relevant information. All reports aim to be resolved within\nthe industry-standard 90 days. Confirmed vulnerabilities with a\nhigh severity level will be addressed promptly.
\n\nPlease privately share a minimal Django project or code snippet that\ndemonstrates the potential vulnerability. Include clear instructions on how to\nset up, run, and reproduce the issue.
\nPlease do not attach screenshots of code.
\nReports based on a failure to sanitize user input are not valid security\nvulnerabilities. It is the developer’s responsibility to properly handle user\ninput. This principle is explained in our security documentation.
\nFor example, the following is not considered valid because email has\nnot been sanitized:
from django.core.mail import send_mail\nfrom django.http import JsonResponse\n\n\ndef my_proof_of_concept(request):\n email = request.GET.get("email", "")\n send_mail("Email subject", "Email body", email, ["admin@example.com"])\n return JsonResponse(status=200)\nDevelopers must always validate and sanitize input before using it. The\ncorrect approach would be to use a Django form to ensure email is properly\nvalidated:
from django import forms\nfrom django.core.mail import send_mail\nfrom django.http import JsonResponse\n\n\nclass EmailForm(forms.Form):\n email = forms.EmailField()\n\n\ndef my_proof_of_concept(request):\n form = EmailForm(request.GET)\n if form.is_valid():\n send_mail(\n "Email subject",\n "Email body",\n form.cleaned_data["email"],\n ["admin@example.com"],\n )\n return JsonResponse(status=200)\n return JsonResponse(form.errors, status=400)\nSimilarly, as Django’s raw SQL constructs (such as extra() and\nRawSQL expression) provide developers with full control over the\nquery, they are insecure if user input is not properly handled. As explained in\nour security documentation, it is the\ndeveloper’s responsibility to safely process user input for these functions.
For instance, the following is not considered valid because query has\nnot been sanitized:
from django.shortcuts import HttpResponse\nfrom .models import MyModel\n\n\ndef my_proof_of_concept(request):\n query = request.GET.get("query", "")\n q = MyModel.objects.extra(select={"id": query})\n return HttpResponse(q.values())\nTo prevent denial-of-service (DoS) attacks, production-grade servers impose\nlimits on request header and URL sizes. For example, by default Gunicorn allows\nup to roughly:
\n\nOther web servers, such as Nginx and Apache, have similar restrictions to\nprevent excessive resource consumption.
\nConsequently, the Django security team will not consider reports that rely on\nrequest headers or URLs exceeding 8K bytes, as such inputs are already\nmitigated at the server level in production environments.
\n\nThe DATA_UPLOAD_MAX_MEMORY_SIZE setting limits the default maximum\nrequest body size to 2.5 MB.
As this is enforced on all production-grade Django projects by default, a proof\nof concept must not exceed 2.5 MB in the request body to be considered valid.
\nIssues resulting from large, but potentially reasonable setting values, should\nbe reported using the public ticket tracker for hardening.
\nThe proof of concept must plausibly occur in a production-grade Django\napplication, reflecting real-world scenarios and following standard development\npractices.
\nDjango contains many private and undocumented functions that are not part of\nits public API. If a vulnerability depends on directly calling these internal\nfunctions in an unsafe way, it will not be considered a valid security issue.
\nThe Django Template Language (DTL) is designed for building the content needed\nto display web pages. In particular its text filters are meant for that kind of\nusage.
\nFor reference, the complete works of Shakespeare have about 3.5 million bytes\nin plain-text ASCII encoding. Displaying such in a single request is beyond the\nscope of almost all websites, and so outside the scope of the DTL too.
\nText processing is expensive. Django makes no guarantee that DTL text filters\nare never subject to degraded performance if passed deliberately crafted,\nsufficiently large inputs. Under default configurations, Django makes it\ndifficult for sites to accidentally accept such payloads from untrusted\nsources, but, if it is necessary to display large amounts of user-provided\ncontent, it’s important that basic security measures are taken.
\nUser-provided content should always be constrained to known maximum length. It\nshould be filtered to remove malicious content, and validated to match expected\nformats. It should then be processed offline, if necessary, before being\ndisplayed.
\nProof of concepts which use over 100 KB of data to be processed by the DTL will\nbe considered invalid.
\nThese are criteria used by the security team when evaluating whether a report\nrequires a security release:
\nThe vulnerability is within a supported version of\nDjango.
The vulnerability does not depend on manual actions that rely on code\nexternal to Django. This includes actions performed by a project’s developer\nor maintainer using developer tools or the Django CLI. For example, attacks\nthat require running management commands with uncommon or insecure options\ndo not qualify.
The vulnerability applies to a production-grade Django application. This\nmeans the following scenarios do not require a security release:
\nExploits that only affect local development, for example when using\nrunserver.
Exploits which fail to follow security best practices, such as failure to\nsanitize user input. For other examples, see our security\ndocumentation.
Exploits in AI generated code that do not adhere to security best practices.
The security team may conclude that the source of the vulnerability is within\nthe Python standard library, in which case the reporter will be asked to report\nthe vulnerability to the Python core team. For further details see the Python\nsecurity guidelines.
\nOn occasion, a security release may be issued to help resolve a security\nvulnerability within a popular third-party package. These reports should come\nfrom the package maintainers.
\nIf you are unsure whether your finding meets these criteria, please still report\nit privately by emailing security@djangoproject.com. The security team will review your report and\nrecommend the correct course of action.
\nAt any given time, the Django team provides official security support\nfor several versions of Django:
\nThe main development branch, hosted on GitHub, which will become the\nnext major release of Django, receives security support. Security issues that\nonly affect the main development branch and not any stable released versions\nare fixed in public without going through the disclosure process.
The two most recent Django release series receive security\nsupport. For example, during the development cycle leading to the\nrelease of Django 1.5, support will be provided for Django 1.4 and\nDjango 1.3. Upon the release of Django 1.5, Django 1.3’s security\nsupport will end.
Long-term support releases will receive security updates for a\nspecified period.
When new releases are issued for security reasons, the accompanying\nnotice will include a list of affected versions. This list is\ncomprised solely of supported versions of Django: older versions may\nalso be affected, but we do not investigate to determine that, and\nwill not issue patches or new releases for those versions.
\nThe severity level of a security vulnerability is determined by the attack\ntype.
\nSeverity levels are:
\nHigh
\nRemote code execution
SQL injection
Moderate
\nCross site scripting (XSS)
Cross site request forgery (CSRF)
Denial-of-service attacks
Broken authentication
Low
\nSensitive data exposure
Broken session management
Unvalidated redirects/forwards
Issues requiring an uncommon configuration option
Our process for taking a security issue from private discussion to\npublic disclosure involves multiple steps.
\nApproximately one week before public disclosure, we send two notifications:
\nFirst, we notify django-announce of the date and approximate time of the\nupcoming security release, as well as the severity of the issues. This is to\naid organizations that need to ensure they have staff available to handle\ntriaging our announcement and upgrade Django as needed.
\nSecond, we notify a list of people and organizations, primarily composed of operating-system vendors and\nother distributors of Django. This email is signed with the PGP key of someone\nfrom Django’s release team and consists of:
\nA full description of the issue and the affected versions of Django.
The steps we will be taking to remedy the issue.
The patch(es), if any, that will be applied to Django.
The date on which the Django team will apply these patches, issue\nnew releases and publicly disclose the issue.
On the day of disclosure, we will take the following steps:
\nApply the relevant patch(es) to Django’s codebase.
Issue the relevant release(s), by placing new packages on the Python\nPackage Index and on the djangoproject.com website, and tagging the new release(s)\nin Django’s git repository.
Post a public entry on the official Django development blog,\ndescribing the issue and its resolution in detail, pointing to the\nrelevant patches and new releases, and crediting the reporter of\nthe issue (if the reporter wishes to be publicly identified).
Post a notice to the django-announce and oss-security@lists.openwall.com\nmailing lists that links to the blog post.
If a reported issue is believed to be particularly time-sensitive –\ndue to a known exploit in the wild, for example – the time between\nadvance notification and public disclosure may be shortened\nconsiderably.
\nAdditionally, if we have reason to believe that an issue reported to\nus affects other frameworks or tools in the Python/web ecosystem, we\nmay privately contact and discuss those issues with the appropriate\nmaintainers, and coordinate our own disclosure and resolution with\ntheirs.
\nThe Django team also maintains an archive of security issues\ndisclosed in Django.
\nThe full list of people and organizations who receive advance\nnotification of security issues is not and will not be made public.
\nWe also aim to keep this list as small as effectively possible, in\norder to better manage the flow of confidential information prior to\ndisclosure. As such, our notification list is not simply a list of\nusers of Django, and being a user of Django is not sufficient reason\nto be placed on the notification list.
\nIn broad terms, recipients of security notifications fall into three\ngroups:
\nOperating-system vendors and other distributors of Django who\nprovide a suitably-generic (i.e., not an individual’s personal\nemail address) contact address for reporting issues with their\nDjango package, or for general security reporting. In either case,\nsuch addresses must not forward to public mailing lists or bug\ntrackers. Addresses which forward to the private email of an\nindividual maintainer or security-response contact are acceptable,\nalthough private security trackers or security-response groups are\nstrongly preferred.
On a case-by-case basis, individual package maintainers who have\ndemonstrated a commitment to responding to and responsibly acting\non these notifications.
On a case-by-case basis, other entities who, in the judgment of the\nDjango development team, need to be made aware of a pending\nsecurity issue. Typically, membership in this group will consist of\nsome of the largest and/or most likely to be severely impacted\nknown users or distributors of Django, and will require a\ndemonstrated ability to responsibly receive, keep confidential and\nact on these notifications.
If you believe that you, or an organization you are authorized to\nrepresent, fall into one of the groups listed above, you can ask to be\nadded to Django’s notification list by emailing\nsecurity@djangoproject.com. Please use the subject line «Security\nnotification request».
Your request must include the following information:
\nYour full, real name and the name of the organization you represent,\nif applicable, as well as your role within that organization.
A detailed explanation of how you or your organization fit at least\none set of criteria listed above.
A detailed explanation of why you are requesting security notifications.\nAgain, please keep in mind that this is not simply a list for users of\nDjango, and the overwhelming majority of users should subscribe to\ndjango-announce to receive advanced notice of when a security release will\nhappen, without the details of the issues, rather than request detailed\nnotifications.
The email address you would like to have added to our notification\nlist.
An explanation of who will be receiving/reviewing mail sent to that\naddress, as well as information regarding any automated actions that\nwill be taken (i.e., filing of a confidential issue in a bug\ntracker).
For individuals, the ID of a public key associated with your address\nwhich can be used to verify email received from you and encrypt\nemail sent to you, as needed.
Once submitted, your request will be considered by the Django\ndevelopment team; you will receive a reply notifying you of the result\nof your request within 30 days.
\nPlease also bear in mind that for any individual or organization,\nreceiving security notifications is a privilege granted at the sole\ndiscretion of the Django development team, and that this privilege can\nbe revoked at any time, with or without explanation.
\n\n