github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-08-31 12:32:52 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #764] Add the possibility to disable trustedOrigins and accept requests from anything (like cors with *) #8417

New Issue
Closed
opened 2026-04-13 03:29:04 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-13 03:29:04 -05:00
Owner
Copy Link
Copy Source

Originally created by @dichioniccolo on GitHub (Dec 4, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/764

I’m working on a specific use case where my application is hosted on a server that frequently changes its domain name. This dynamic nature makes it challenging to maintain an up-to-date list of trusted origins for the trustedOrigins configuration.

Would it be possible to introduce an option to disable the trustedOrigins validation entirely? For example, allowing a configuration like trustedOrigins: false to bypass this check, instead of requiring a comprehensive list of all possible origins.

This flexibility would greatly simplify setups in environments like mine, where the domain isn’t static, and maintaining such a list becomes impractical.

Originally created by @dichioniccolo on GitHub (Dec 4, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/764 I’m working on a specific use case where my application is hosted on a server that frequently changes its domain name. This dynamic nature makes it challenging to maintain an up-to-date list of trusted origins for the trustedOrigins configuration. Would it be possible to introduce an option to disable the trustedOrigins validation entirely? For example, allowing a configuration like ```trustedOrigins: false``` to bypass this check, instead of requiring a comprehensive list of all possible origins. This flexibility would greatly simplify setups in environments like mine, where the domain isn’t static, and maintaining such a list becomes impractical.
GiteaMirror added the locked label 2026-04-13 03:29:05 -05:00
GiteaMirror commented 2026-04-13 03:29:06 -05:00
Author
Owner
Copy Link
Copy Source

@Bekacru commented on GitHub (Dec 4, 2024):

Hey, the trustOrigins option accepts a wildcard value. But allowing any domain to make requests to your auth server expose you to CSRF attacks and bypass open redirect protection.

<!-- gh-comment-id:2518162657 --> @Bekacru commented on GitHub (Dec 4, 2024): Hey, the `trustOrigins` option accepts a wildcard value. But allowing any domain to make requests to your auth server expose you to CSRF attacks and bypass open redirect protection.
GiteaMirror commented 2026-04-13 03:29:06 -05:00
Author
Owner
Copy Link
Copy Source

@dichioniccolo commented on GitHub (Dec 4, 2024):

In my case, the application is not public and is used exclusively within my client's network, so CSRF attacks or open redirect issues are not a concern in this specific environment.

That said, I understand the potential risks this could pose in a broader context.

Considering that wildcards are supported, would it be possible to use *, similar to how CORS handles it, to allow any domain or that would not work?

<!-- gh-comment-id:2518185649 --> @dichioniccolo commented on GitHub (Dec 4, 2024): In my case, the application is not public and is used exclusively within my client's network, so CSRF attacks or open redirect issues are not a concern in this specific environment. That said, I understand the potential risks this could pose in a broader context. Considering that wildcards are supported, would it be possible to use *, similar to how CORS handles it, to allow any domain or that would not work?
GiteaMirror commented 2026-04-13 03:29:07 -05:00
Author
Owner
Copy Link
Copy Source

@Bekacru commented on GitHub (Jan 13, 2025):

passing "*" should work

<!-- gh-comment-id:2586958665 --> @Bekacru commented on GitHub (Jan 13, 2025): passing "*" should work
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No labels locked
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#8417