[GH-ISSUE #7793] Origin check blocks Electron apps using file:// #28230

Open
opened 2026-04-17 19:41:08 -05:00 by GiteaMirror · 6 comments
Owner

Originally created by @aguidis on GitHub (Feb 4, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/7793

Hi 👋
First of all, thanks for better-auth — it’s been great to work with.

I’m opening this issue mainly to share a potential breaking change I ran into regarding the origin check, in case other users face the same behavior (especially with Electron apps).


🧩 Context

My setup consists of:

  • API: Hono + better-auth
  • Web app: Next.js
  • Desktop app: Electron

In production, the Electron app sends requests with the following header: Origin: file://.

This setup has been working fine since October with better-auth v1.3.28.

⚙️ Configuration

  • auth.config.ts
export const auth = betterAuth({
  basePath: `${API_BASE}/auth`,
  trustedOrigins: [
    API_BASE_URL,
    WEB_APP_BASE_URL,
    ELECTRON_BASE_URL, // file://
  ],
  ...,
});

🚨 Issue after upgrading

About one month ago, I upgraded better-auth to v1.4.10.

Shortly after, users reported being unable to log in.
The API was returning the following error:

Missing or null origin

After some investigation, I found that this error comes from the origin-check middleware (src/api/middlewares/origin-check.ts):

  • v1.3.28

https://github.com/better-auth/better-auth/blob/v1.3.28/packages/better-auth/src/api/middlewares/origin-check.ts#L68

  • v1.3.29 (refacto introduced in this version)

https://github.com/better-auth/better-auth/blob/v1.3.29/packages/better-auth/src/api/middlewares/origin-check.ts#L83

It looks like the additional check: originHeader === "null" (or related refactor) causes Electron requests (with file:// origin) to be rejected, even when the origin is explicitly trusted.

I didn’t fully trace the entire refactor, but this check appears to be the main cause in my case.


Workarounds

  • Option 1 — Pin version

For now, I reverted and pinned better-auth to v1.3.28, which restores the previous behavior.

  • Option 2 — Disable origin check

I was able to make it work on newer versions by setting:

advanced: {
  disableOriginCheck: true,
}

However, I’m not fully confident this is the best approach security-wise in this context, and would love feedback or guidance on recommended practices for Electron apps.

💬 Why I’m opening this issue

  • To warn other users who may suddenly hit this issue after upgrading
  • To document a potential breaking change
  • To ask whether: file:// origins should be handled differently

Happy to provide more details or test a fix if needed.
Thanks again for the great work 🙏

Originally created by @aguidis on GitHub (Feb 4, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/7793 Hi 👋 First of all, thanks for **better-auth** — it’s been great to work with. I’m opening this issue mainly to **share a potential breaking change** I ran into regarding the **origin check**, in case other users face the same behavior (especially with Electron apps). --- ## 🧩 Context My setup consists of: - **API**: Hono + better-auth - **Web app**: Next.js - **Desktop app**: Electron In production, the Electron app sends requests with the following header: `Origin: file://`. This setup has been working fine since **October** with better-auth `v1.3.28`. ### ⚙️ Configuration - `auth.config.ts` ```ts export const auth = betterAuth({ basePath: `${API_BASE}/auth`, trustedOrigins: [ API_BASE_URL, WEB_APP_BASE_URL, ELECTRON_BASE_URL, // file:// ], ..., }); ``` --- ## 🚨 Issue after upgrading About one month ago, I upgraded better-auth to v1.4.10. Shortly after, users reported being unable to log in. The API was returning the following error: > Missing or null origin After some investigation, I found that this error comes from the origin-check middleware (src/api/middlewares/origin-check.ts): - v1.3.28 https://github.com/better-auth/better-auth/blob/v1.3.28/packages/better-auth/src/api/middlewares/origin-check.ts#L68 - v1.3.29 (refacto introduced in this version) https://github.com/better-auth/better-auth/blob/v1.3.29/packages/better-auth/src/api/middlewares/origin-check.ts#L83 It looks like the additional check: `originHeader === "null"` (or related refactor) causes Electron requests (with file:// origin) to be rejected, even when the origin is explicitly trusted. I didn’t fully trace the entire refactor, but this check appears to be the main cause in my case. --- ## ✅ Workarounds - Option 1 — Pin version For now, I reverted and pinned better-auth to v1.3.28, which restores the previous behavior. - Option 2 — Disable origin check I was able to make it work on newer versions by setting: ``` advanced: { disableOriginCheck: true, } ``` However, I’m not fully confident this is the best approach security-wise in this context, and would love feedback or guidance on recommended practices for Electron apps. ## 💬 Why I’m opening this issue - To warn other users who may suddenly hit this issue after upgrading - To document a potential breaking change - To ask whether: `file://` origins should be handled differently Happy to provide more details or test a fix if needed. Thanks again for the great work 🙏
GiteaMirror added the platformcorebug labels 2026-04-17 19:41:08 -05:00
Author
Owner

@better-auth-agent[bot] commented on GitHub (Feb 4, 2026):

Hello! Thank you for your detailed report and for using Better Auth. It sounds like you're experiencing issues with the origin check after upgrading to better-auth v1.4.10.

From your description, it appears that the changes introduced in that version are affecting how requests from Electron apps using the file:// origin are handled, likely due to stricter validation introduced in the middleware. It's also clear you've already identified and implemented workarounds, such as pinning to an earlier version or disabling the origin check, which may not be the most secure approach.

As for recommended practices, you might consider:

  1. Reviewing trustedOrigins: Make sure that file:// or appropriate origins are included in your trustedOrigins list, though it seems like this may not resolve the issue based on your findings.
  2. Security Considerations: Disabling origin checks can expose you to security vulnerabilities like CSRF attacks, making it crucial to evaluate the security implications of this approach.

There is an open issue discussing how to handle custom protocols and file:// origins more effectively in Electron apps, which could be of interest to you [4]. Engaging with the Better Auth team directly could provide more tailored guidance for your specific setup.

Feel free to tag @better-auth-agent if you have further questions or need more clarification on this issue. What are your thoughts on exploring alternative configurations or engaging with the team for more insight?

If you need more help, tag @better-auth-agent in a comment so I can respond.

DiagramDiscordGitHub

Diagram Join Star

<!-- gh-comment-id:3847473226 --> @better-auth-agent[bot] commented on GitHub (Feb 4, 2026): Hello! Thank you for your detailed report and for using Better Auth. It sounds like you're experiencing issues with the origin check after upgrading to better-auth `v1.4.10`. From your description, it appears that the changes introduced in that version are affecting how requests from Electron apps using the `file://` origin are handled, likely due to stricter validation introduced in the middleware. It's also clear you've already identified and implemented workarounds, such as pinning to an earlier version or disabling the origin check, which may not be the most secure approach. As for recommended practices, you might consider: 1. **Reviewing trustedOrigins**: Make sure that `file://` or appropriate origins are included in your `trustedOrigins` list, though it seems like this may not resolve the issue based on your findings. 2. **Security Considerations**: Disabling origin checks can expose you to security vulnerabilities like CSRF attacks, making it crucial to evaluate the security implications of this approach. There is an open issue discussing how to handle custom protocols and `file://` origins more effectively in Electron apps, which could be of interest to you [[4]](https://github.com/better-auth/better-auth/issues/7149). Engaging with the Better Auth team directly could provide more tailored guidance for your specific setup. Feel free to tag @better-auth-agent if you have further questions or need more clarification on this issue. What are your thoughts on exploring alternative configurations or engaging with the team for more insight? _If you need more help, tag @better-auth-agent in a comment so I can respond._ <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
Author
Owner

@bytaesu commented on GitHub (Feb 4, 2026):

Hi @aguidis, thanks for letting us know!

This seems duplicate of https://github.com/better-auth/better-auth/issues/7149

@jslno could you check this? 🙏

<!-- gh-comment-id:3847498325 --> @bytaesu commented on GitHub (Feb 4, 2026): Hi @aguidis, thanks for letting us know! This seems duplicate of https://github.com/better-auth/better-auth/issues/7149 @jslno could you check this? 🙏
Author
Owner

@jslno commented on GitHub (Feb 4, 2026):

This is most likely because the origin header is empty. Before empty/missing origins were passed through but know they throw. You need to pass an origin header through your requests. Not entirely sure, but may need a middleware for it, like for example here:

<!-- gh-comment-id:3847639049 --> @jslno commented on GitHub (Feb 4, 2026): This is most likely because the origin header is empty. Before empty/missing origins were passed through but know they throw. You need to pass an origin header through your requests. Not entirely sure, but may need a middleware for it, like for example here: - https://github.com/better-auth/better-auth/pull/7647/changes#diff-f0573d08333eec2f1ed9dcd018c7edeb03dacb5632f01e6b7d2e0bd5e7f72e48R48-R63 - https://github.com/better-auth/better-auth/pull/7647/changes#diff-695380f8ec74350a088d67a91b5154c58dd7448c859858c197fb5e8821c9bc55R85
Author
Owner

@aguidis commented on GitHub (Feb 4, 2026):

Hey @jslno, your PR looks promising. Right now, I'm using the better auth client directly in the react app (renderer process). Do you think I can set “manually” a header origin before calling any method like await authClient.signIn.email() for example ?

<!-- gh-comment-id:3848693690 --> @aguidis commented on GitHub (Feb 4, 2026): Hey @jslno, your PR looks promising. Right now, I'm using the better auth client directly in the react app (renderer process). Do you think I can set “manually” a header `origin` before calling any method like ` await authClient.signIn.email()` for example ?
Author
Owner

@jslno commented on GitHub (Feb 13, 2026):

Hey @aguidis, sorry for the late response!

Yeah, setting the header manually should work. However I would strongly advise against exposing your authClient to the renderer process though, as it can potentially make your app vulnerable to injection attacks.

I'd recommend you to checkout out the new electron integration

<!-- gh-comment-id:3897978076 --> @jslno commented on GitHub (Feb 13, 2026): Hey @aguidis, sorry for the late response! Yeah, setting the header manually should work. However I would strongly advise against exposing your authClient to the renderer process though, as it can potentially make your app vulnerable to injection attacks. I'd recommend you to checkout out the new electron integration
Author
Owner

@aguidis commented on GitHub (Mar 9, 2026):

Hey @jslno thanks the advice I'll check this new integration (and I'll have to start a big refacto 🥹 ). Right now I'm still using an old version of better-auth.

<!-- gh-comment-id:4026215981 --> @aguidis commented on GitHub (Mar 9, 2026): Hey @jslno thanks the advice I'll check this new integration (and I'll have to start a big refacto 🥹 ). Right now I'm still using an old version of better-auth.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#28230