Bring the features of django-cors-headers Django core

[dilroop-us]

Code of Conduct

• I agree to follow Django's Code of Conduct

Package Information

django-cors-headers

Problem

Today, a lot of Django projects need CORS (Cross-Origin Resource Sharing), especially when building APIs, SPAs, or mobile backends. Right now, Django doesn't come with any built-in CORS support. We always have to install Django-cors-headers, even for very basic setups.

Since CORS is so common, especially as Django moves toward more async and API-first development, it would be great if it came built-in and officially supported.

Rationale

Django already takes care of important web security (like CSRF, SSL redirects, clickjacking protection). CORS fits into that same category — it’s a core part of modern web security.

Having CORS middleware built into Django would:

• Make it easier and faster to set up secure APIs.
• Avoid needing another extra package for almost every project.
• Provide official documentation and async compatibility going forward.

django-cors-headers is already the trusted package almost everyone uses — it makes sense to bring it home into Django itself.

Additional Details

django-cors-headers is a widely used, stable package with a clean design. Its functionality could fit naturally under django.middleware, with a few simple settings like allowed origins and credentials. Supporting async would also be important as Django continues to move toward async-native development.

Implementation Details

• Move the main functionality of django-cors-headers into Django as a new middleware class.
• Add a few simple settings (example: CORS_ALLOWED_ORIGINS, CORS_ALLOW_CREDENTIALS, etc.).
• Make sure it works in both normal sync views and async views.

[github-actions]

Thank you dilroop-us for sharing your idea! We have a lot of them so please be patient. You can see the current queue here. If you'd like to learn about other ways to get this idea more attention, please see this page.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[SilmarillionUA]

Not everyone uses Django for API only, so it would not benefit everyone. With this argumentation I would like to see an official support for CSP management also.

[apollo13]

CSP is on a its way in django/django#19393

[tykling]

Please have this include CORS support for staticfiles served by runserver to make local development easier. 🙏 💓

[alexandernst]

@SilmarillionUA

Not everyone uses Django for API only, so it would not benefit everyone

If Django was to add only features that benefit "everyone" we'd end up with Flask.
You don't have to use X, Y or Z feature in Django, but that doesn't mean it can't be included in the core.

[danlamanna]

As a fuzzy data point, I had looked at PyPI download stats for all of 2024 recently and django-cors-headers had ~76 million and django had ~225 million. It appears to be the most popular package prefixed with django outside of Django itself and DRF.

[adamchainz]

As its maintainer, I don't think we should merge django-cors-headers as-is. I inherited the project and it has a lot of janky design decisions, like settings that match against URLs.

I would like us to design CORS handling in Django with two goals:

1. Match existing similar features, like CSRF, clickjacking protection, or the new CSP support.
2. Support both decorator and middleware interfaces.

I've put the project up for GSoC for a few years running, but there haven't been any strong proposals.

[jasonchrista]

I really don't like the way django-cors-headers works. It is like nothing else in Django proper with the settings based way it applies to routes. I have always just made my own decorator or class mixin when I need to set CORS headers.

[nanuxbe]

We have also moved this issue forward, so the next step here would be to setup a team around this idea and write a more in-depth proposal

As per @adamchainz 's comment, I have also renamed this ticket to reflect the views of that comment.