Has CORS support in Git endpoints been considered?

[lawrencejob]

Select Topic Area

Product Feedback

Body

I am working on an app which works in the desktop and the browser to allow users to check out a repository, make changes, and check them back in as you expect.

To make it work in the browser I have been using the excellent isomorphic-git library. However I have encountered one area of architectural and security concern.

Because of CSP/CORS configuration in the Git endpoints, similar projects have had to proxy the requests, which involves giving deep access to a third party. I don't think most users realise the risk this poses. Any CORS proxy has complete access to the HTTP request without any of the protections afforded by HTTPS.

• Is there any way I as an API user can request CORS support in the API response specifically as an authenticated caller?
• Does this fall to the core Git project for support?
• Is there anything I can do to proxy requests without putting my users privacy at risk?

I can make this software a desktop app and sidestep this, or I can put my users at risk (and pay for the bandwidth of routing their request to some other service and add another dependency to my architecture), but if there's a first party solution to this problem I would be extremely keen to adopt it.

I completely understand if this has been discussed before (I can't find it if it's public), I would love to know if it's a) rejected b) in the pipeline or c) not been considered before.

Thanks for the great service.

Related:
https://github.com/orgs/community/discussions/49980
https://github.com/gr2m/github-api-wishlist/tree/master/wishlist/cors-for-adjacent-domains

sorry this was originally posted as "Product Feedback" but has to re-post it. is there a way to relabel this?

[Tsknefe]

The lack of CORS support on Git endpoints is generally intentional and tied to security considerations.

Allowing arbitrary browser clients to directly access Git operations could create several issues:

exposure of authentication tokens in browser contexts

increased attack surface for malicious scripts

difficulty enforcing proper permission boundaries

potential abuse scenarios from untrusted origins

Because of this, many applications that need browser-based Git operations typically rely on an intermediate backend service.

A common architecture looks like:

Browser client → application backend → GitHub API / Git endpoints

In this model the backend service:

handles authentication securely

proxies Git operations

enforces rate limits and permissions

protects secrets from being exposed in the browser

While it may feel like additional complexity, this pattern is widely used for security reasons and helps prevent leaking credentials or enabling unwanted automated Git interactions directly from browser contexts.

If the goal is a browser-first Git experience, some alternatives that developers typically explore are:

using a lightweight proxy service

running a small serverless function as a secure intermediary

relying on GitHub REST/GraphQL APIs instead of raw Git endpoints when possible

In short, the proxy requirement is not just a limitation but largely a deliberate security design choice.

[shivrajcodez]

Right now the lack of CORS support on Git endpoints is generally intentional and by design due to security reasons.

Allowing arbitrary browser clients to directly hit Git endpoints with CORS would expose authentication tokens in browser contexts, increase the attack surface for malicious scripts, and make it harder to enforce permission boundaries and rate limits. That’s why most browser-based Git workflows don’t connect directly to Git protocol endpoints, and instead rely on an intermediate backend to securely handle authentication and proxy requests.
What most implementations do instead
A common pattern for browser-based Git operations is:
Browser client → Your backend service → GitHub API / Git endpoints
Benefits of this architecture:
The backend can safely store and use auth tokens
It can proxy Git operations securely
It can enforce permissions, rate limits, and protect secrets
It avoids exposing sensitive credentials directly to the browser process
If your goal is a truly browser-first experience, alternatives devs often explore include:
Running a lightweight proxy or serverless function that handles Git for you
Using GitHub REST or GraphQL APIs instead of raw Git transport where possible
In short: CORS protection on Git endpoints isn’t an accidental limitation — it’s a security boundary.

[lawrencejob]

I think you both used the same AI model.. 🙄