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

[GH-ISSUE #7502] Clarification: Is baseURL necessary when trustedOrigins is configured? #10827

New Issue
Closed
opened 2026-04-13 07:11:35 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-13 07:11:35 -05:00
Owner
Copy Link

Originally created by @issam-seghir on GitHub (Jan 20, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/7502

Question

I'm trying to understand the relationship between baseURL and trustedOrigins configuration options, and whether baseURL can be omitted entirely when trustedOrigins is properly configured.

Context

According to the documentation:

  1. baseURL is used for generating callback URLs (OAuth, email verification, password reset)
  2. trustedOrigins is the primary CSRF protection mechanism that validates Origin headers

The docs state:

If baseURL is not explicitly set, the system first checks for the BETTER_AUTH_URL environment variable. If that's also not set, the baseURL is inferred from the incoming request.

However, the docs also say:

However, relying on request inference is not recommended; for security and stability, baseURL should always be explicitly set.

Current Setup

We have a comprehensive trustedOrigins configuration covering:

  • Production domains
  • Staging/preview domains
  • Development ports (3000-3010, 5000-5010, 8000-8010)
  • Dev tunnels
  • Local network IPs

Currently using:

export const auth = betterAuth({
    // No explicit baseURL - letting Better Auth infer from request
    trustedOrigins: getTrustedOrigins(), // Returns 100+ origins
    // ... other config
});

Questions

  1. Is baseURL actually necessary if trustedOrigins is comprehensively configured and handles all CSRF protection?

  2. What are the specific security/stability risks of relying on request inference when trustedOrigins validates every request?

  3. Does omitting baseURL have any implications beyond URL generation that aren't obvious from the documentation?

  4. Is there a recommended pattern for development workflows where developers frequently switch between:

    • Different localhost ports (3000, 5000, 8080, etc.)
    • Dev tunnels (devtunnels.ms, ngrok, etc.)
    • Local network IPs for mobile testing

Why This Matters

Having to set baseURL explicitly creates friction in development:

  • Requires env changes every time switching ports/tunnels
  • Defeats the purpose of having comprehensive trustedOrigins
  • Request inference seems to work perfectly for generating callback URLs

Since trustedOrigins already provides the security layer (CSRF protection, origin validation, Fetch Metadata protection), it's unclear why explicit baseURL is "highly recommended" beyond URL generation, which request inference handles automatically.

Expected Behavior

Ideally, documentation would clarify:

  • Whether baseURL omission is safe with proper trustedOrigins
  • Specific scenarios where explicit baseURL is required (beyond "recommended")
  • Best practices for dynamic development environments

Thank you for your guidance!

Originally created by @issam-seghir on GitHub (Jan 20, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/7502 ## Question I'm trying to understand the relationship between `baseURL` and `trustedOrigins` configuration options, and whether `baseURL` can be omitted entirely when `trustedOrigins` is properly configured. ## Context According to the documentation: 1. **`baseURL`** is used for generating callback URLs (OAuth, email verification, password reset) 2. **`trustedOrigins`** is the primary CSRF protection mechanism that validates Origin headers The docs state: > If `baseURL` is not explicitly set, the system first checks for the `BETTER_AUTH_URL` environment variable. If that's also not set, the `baseURL` is inferred from the incoming request. However, the docs also say: > However, relying on request inference is not recommended; for security and stability, `baseURL` should always be explicitly set. ## Current Setup We have a comprehensive `trustedOrigins` configuration covering: - Production domains - Staging/preview domains - Development ports (3000-3010, 5000-5010, 8000-8010) - Dev tunnels - Local network IPs Currently using: ```typescript export const auth = betterAuth({ // No explicit baseURL - letting Better Auth infer from request trustedOrigins: getTrustedOrigins(), // Returns 100+ origins // ... other config }); ``` ## Questions 1. **Is `baseURL` actually necessary** if `trustedOrigins` is comprehensively configured and handles all CSRF protection? 2. **What are the specific security/stability risks** of relying on request inference when `trustedOrigins` validates every request? 3. **Does omitting `baseURL` have any implications** beyond URL generation that aren't obvious from the documentation? 4. **Is there a recommended pattern** for development workflows where developers frequently switch between: - Different localhost ports (3000, 5000, 8080, etc.) - Dev tunnels (devtunnels.ms, ngrok, etc.) - Local network IPs for mobile testing ## Why This Matters Having to set `baseURL` explicitly creates friction in development: - Requires env changes every time switching ports/tunnels - Defeats the purpose of having comprehensive `trustedOrigins` - Request inference seems to work perfectly for generating callback URLs Since `trustedOrigins` already provides the security layer (CSRF protection, origin validation, Fetch Metadata protection), it's unclear why explicit `baseURL` is "highly recommended" beyond URL generation, which request inference handles automatically. ## Expected Behavior Ideally, documentation would clarify: - Whether `baseURL` omission is safe with proper `trustedOrigins` - Specific scenarios where explicit `baseURL` is required (beyond "recommended") - Best practices for dynamic development environments Thank you for your guidance!
GiteaMirror added the locked label 2026-04-13 07:11:35 -05:00
GiteaMirror commented 2026-04-13 07:11:36 -05:00
Author
Owner
Copy Link

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

Hi there! Thanks for your detailed question about the baseURL and trustedOrigins configuration options in Better Auth.

  1. Is baseURL actually necessary if trustedOrigins is comprehensively configured?
    While trustedOrigins can handle CSRF protection, having baseURL explicitly set is strongly recommended for security and stability reasons. It ensures that callbacks (like OAuth and password resets) are correctly generated and avoids potential issues with inferred values, particularly in production environments [1].

  2. What are the specific security/stability risks of relying on request inference?
    Relying on inferred baseURL can lead to undefined behavior, especially if the incoming request doesn’t match expected patterns. For example, in the absence of an explicitly defined baseURL, session cookies may lack important security flags (like the Secure flag when in production) [3].

  3. Does omitting baseURL have any implications beyond URL generation?
    Yes, not specifying baseURL can impact cookie security and the proper functioning of features that rely on predictable callback URLs. It's possible to encounter unexpected behaviors or errors if the request does not match the inferred origin, which can lead to security vulnerabilities [1][3].

  4. Is there a recommended pattern for dynamic development workflows?
    Using environment variables for baseURL is common, but it can create friction in development settings where ports frequently change. An enhancement proposal suggests allowing baseURL to accept a function that can derive it from requests, similar to how trustedOrigins works. This would offer flexibility in dynamic environments [2].

To summarize, while extensive trustedOrigins configuration is helpful, explicitly defining baseURL is critical for ensuring secure and stable authentication flows.

Do you have any specific scenarios in your development workflow where you're experiencing issues related to these configurations? I'd love to hear more!

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

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3774721545 --> @better-auth-agent[bot] commented on GitHub (Jan 20, 2026): Hi there! Thanks for your detailed question about the `baseURL` and `trustedOrigins` configuration options in Better Auth. 1. **Is `baseURL` actually necessary if `trustedOrigins` is comprehensively configured?** While `trustedOrigins` can handle CSRF protection, having `baseURL` explicitly set is strongly recommended for security and stability reasons. It ensures that callbacks (like OAuth and password resets) are correctly generated and avoids potential issues with inferred values, particularly in production environments [[1]](https://github.com/better-auth/better-auth/pull/6882). 2. **What are the specific security/stability risks of relying on request inference?** Relying on inferred `baseURL` can lead to undefined behavior, especially if the incoming request doesn’t match expected patterns. For example, in the absence of an explicitly defined `baseURL`, session cookies may lack important security flags (like the Secure flag when in production) [[3]](https://github.com/better-auth/better-auth/issues/7156). 3. **Does omitting `baseURL` have any implications beyond URL generation?** Yes, not specifying `baseURL` can impact cookie security and the proper functioning of features that rely on predictable callback URLs. It's possible to encounter unexpected behaviors or errors if the request does not match the inferred origin, which can lead to security vulnerabilities [[1]](https://github.com/better-auth/better-auth/pull/6882)[[3]](https://github.com/better-auth/better-auth/issues/7156). 4. **Is there a recommended pattern for dynamic development workflows?** Using environment variables for `baseURL` is common, but it can create friction in development settings where ports frequently change. An enhancement proposal suggests allowing `baseURL` to accept a function that can derive it from requests, similar to how `trustedOrigins` works. This would offer flexibility in dynamic environments [[2]](https://github.com/better-auth/better-auth/issues/4151). To summarize, while extensive `trustedOrigins` configuration is helpful, explicitly defining `baseURL` is critical for ensuring secure and stable authentication flows. Do you have any specific scenarios in your development workflow where you're experiencing issues related to these configurations? I'd love to hear more! _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)
GiteaMirror commented 2026-04-13 07:11:37 -05:00
Author
Owner
Copy Link

@issam-seghir commented on GitHub (Jan 20, 2026):

@better-auth-agent Thanks for the detailed explanation! I understand the importance of explicit baseURL for security and stability.

The Core Problem

My specific pain point is that baseURL doesn't accept an array, which creates friction in our development workflow. We frequently switch between:

  • Localhost ports: http://localhost:3000, http://localhost:5000, http://localhost:8080, etc.
  • Dev tunnels: https://ghgg1z2v-3000.euw.devtunnels.ms, https://sqf0q86p-3000.uks1.devtunnels.ms
  • Different developer machines: Each developer may use different ports or tunnel URLs

Currently, this requires changing the BETTER_AUTH_URL environment variable every single time we switch between these scenarios, which is very disruptive to the development flow.

Current Setup

We have comprehensive trustedOrigins configured with 100+ origins covering:

trustedOrigins: [
  // All localhost ports 3000-3010, 5000-5010, 8000-8010 (both http/https)
  // All dev tunnel URLs
  // Production domains
  // Staging domains
]

All these origins are already validated and trusted for CSRF protection, but we still need to manually update baseURL to match whichever environment we're currently using.

Ideal Solution

You mentioned an enhancement proposal for baseURL to accept a function (similar to trustedOrigins). This would be perfect for our use case:

export const auth = betterAuth({
  baseURL: async (request) => {
    // Return the origin from the incoming request
    // Still secure because trustedOrigins validates it
    return request?.headers?.get('host') 
      ? `${request.headers.get('x-forwarded-proto') || 'http'}://${request.headers.get('host')}`
      : process.env.FALLBACK_URL;
  },
  trustedOrigins: getTrustedOrigins(), // 100+ validated origins
});

Questions

  1. Is there a recommended workaround for dynamic development environments until the function-based baseURL is implemented?

  2. Would omitting baseURL entirely work if we have comprehensive trustedOrigins? You mentioned it can lead to undefined behavior, but could you elaborate on specific failure scenarios?

  3. Is the function-based baseURL enhancement on the roadmap? If so, is there an estimated timeline or PR we could follow/contribute to?

Our current workaround is to omit baseURL and let it infer from requests, but given your security concerns, I'd like to understand the specific risks we're taking.

Thank you!

<!-- gh-comment-id:3774745136 --> @issam-seghir commented on GitHub (Jan 20, 2026): @better-auth-agent Thanks for the detailed explanation! I understand the importance of explicit `baseURL` for security and stability. ## The Core Problem My specific pain point is that **`baseURL` doesn't accept an array**, which creates friction in our development workflow. We frequently switch between: - **Localhost ports**: `http://localhost:3000`, `http://localhost:5000`, `http://localhost:8080`, etc. - **Dev tunnels**: `https://ghgg1z2v-3000.euw.devtunnels.ms`, `https://sqf0q86p-3000.uks1.devtunnels.ms` - **Different developer machines**: Each developer may use different ports or tunnel URLs Currently, this requires changing the `BETTER_AUTH_URL` environment variable **every single time** we switch between these scenarios, which is very disruptive to the development flow. ## Current Setup We have comprehensive `trustedOrigins` configured with **100+ origins** covering: ```typescript trustedOrigins: [ // All localhost ports 3000-3010, 5000-5010, 8000-8010 (both http/https) // All dev tunnel URLs // Production domains // Staging domains ] ``` All these origins are already validated and trusted for CSRF protection, but we still need to manually update `baseURL` to match whichever environment we're currently using. ## Ideal Solution You mentioned an enhancement proposal for `baseURL` to accept a function (similar to `trustedOrigins`). This would be **perfect** for our use case: ```typescript export const auth = betterAuth({ baseURL: async (request) => { // Return the origin from the incoming request // Still secure because trustedOrigins validates it return request?.headers?.get('host') ? `${request.headers.get('x-forwarded-proto') || 'http'}://${request.headers.get('host')}` : process.env.FALLBACK_URL; }, trustedOrigins: getTrustedOrigins(), // 100+ validated origins }); ``` ## Questions 1. **Is there a recommended workaround** for dynamic development environments until the function-based `baseURL` is implemented? 2. **Would omitting `baseURL` entirely** work if we have comprehensive `trustedOrigins`? You mentioned it can lead to undefined behavior, but could you elaborate on specific failure scenarios? 3. **Is the function-based `baseURL` enhancement** on the roadmap? If so, is there an estimated timeline or PR we could follow/contribute to? Our current workaround is to omit `baseURL` and let it infer from requests, but given your security concerns, I'd like to understand the specific risks we're taking. Thank you!
GiteaMirror commented 2026-04-13 07:11:37 -05:00
Author
Owner
Copy Link

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

Hi there! I'd be happy to help address your questions regarding the configuration of baseURL and trustedOrigins in Better Auth.

  1. Is there a recommended workaround for dynamic development environments until the function-based baseURL is implemented?
    Currently, the best practice is to manually set baseURL as there isn't yet a built-in function to handle this dynamically. However, you might explore using a script that updates the environment variable based on the context you're working in.

  2. Would omitting baseURL entirely work if we have comprehensive trustedOrigins?
    While it is technically possible to omit baseURL, doing so can lead to undefined behavior, particularly in production and multi-domain setups. It's recommended to set an explicit baseURL for better security and to avoid issues like incorrect redirect URIs, especially since relying on inferred values could result in missing security flags in cookies [2], [3].

  3. Is the function-based baseURL enhancement on the roadmap?
    Yes, there is an ongoing proposal for a function-based approach for baseURL, similar to trustedOrigins, but it is still in the enhancement discussion phase. There’s no final timeline yet, but you can follow the related issue on GitHub for updates [2].

It's great to see your engagement with Better Auth! Do you have any other questions regarding integration or best practices?

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3774746060 --> @better-auth-agent[bot] commented on GitHub (Jan 20, 2026): Hi there! I'd be happy to help address your questions regarding the configuration of `baseURL` and `trustedOrigins` in Better Auth. 1. **Is there a recommended workaround for dynamic development environments until the function-based `baseURL` is implemented?** Currently, the best practice is to manually set `baseURL` as there isn't yet a built-in function to handle this dynamically. However, you might explore using a script that updates the environment variable based on the context you're working in. 2. **Would omitting `baseURL` entirely work if we have comprehensive `trustedOrigins`?** While it is technically possible to omit `baseURL`, doing so can lead to undefined behavior, particularly in production and multi-domain setups. It's recommended to set an explicit `baseURL` for better security and to avoid issues like incorrect redirect URIs, especially since relying on inferred values could result in missing security flags in cookies [[2]](https://github.com/better-auth/better-auth/issues/4151), [[3]](https://github.com/better-auth/better-auth/pull/6797). 3. **Is the function-based `baseURL` enhancement on the roadmap?** Yes, there is an ongoing proposal for a function-based approach for `baseURL`, similar to `trustedOrigins`, but it is still in the enhancement discussion phase. There’s no final timeline yet, but you can follow the related issue on GitHub for updates [[2]](https://github.com/better-auth/better-auth/issues/4151). It's great to see your engagement with Better Auth! Do you have any other questions regarding integration or best practices? <!-- 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)
GiteaMirror commented 2026-04-13 07:11:38 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Jan 20, 2026):

Is baseURL necessary when trustedOrigins is configured?

Yes. And baseURL shouldn't be an array. It means for the URL of the auth server.

If you are asking about baseURL per reuqest, see https://github.com/better-auth/better-auth/issues/4151

<!-- gh-comment-id:3774824146 --> @himself65 commented on GitHub (Jan 20, 2026): > Is `baseURL` necessary when trustedOrigins is configured? Yes. And baseURL shouldn't be an array. It means for the URL of the auth server. If you are asking about baseURL per reuqest, see https://github.com/better-auth/better-auth/issues/4151
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 Label locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#10827
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?