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

Protocol-specific wildcard trusted origins not working #1412

New Issue
Closed
opened 2026-03-13 08:38:50 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-03-13 08:38:50 -05:00
Owner
Copy Link

Originally created by @nascode on GitHub (Jun 24, 2025).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

const auth = new BetterAuth({
  trustedOrigins: ["https://*.example.com"],
  // ... other config
});

// This should fail but currently passes
const client = createAuthClient({
  baseURL: "http://localhost:3000",
  fetchOptions: {
    headers: {
      origin: "http://api.example.com", // HTTP origin
      cookie: "session=123",
    },
  },
});

Current vs. Expected behavior

Current: Wildcard trusted origins with protocol always fail.
Expected: Should work like in the docs https://www.better-auth.com/docs/reference/security#wildcard-domains

What version of Better Auth are you using?

1.2.10

Provide environment information

- OS: MacOS Sequoia 15.5
- NodeJS v24.2.0
- Chrome 137.0.7151.120 (Build Resmi) (arm64)

Which area(s) are affected? (Select all that apply)

Backend

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

Security vulnerability where protocol-specific wildcards don't enforce protocol matching.

Originally created by @nascode on GitHub (Jun 24, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce ```javascript const auth = new BetterAuth({ trustedOrigins: ["https://*.example.com"], // ... other config }); // This should fail but currently passes const client = createAuthClient({ baseURL: "http://localhost:3000", fetchOptions: { headers: { origin: "http://api.example.com", // HTTP origin cookie: "session=123", }, }, }); ``` ### Current vs. Expected behavior Current: Wildcard trusted origins with protocol always fail. Expected: Should work like in the docs https://www.better-auth.com/docs/reference/security#wildcard-domains ### What version of Better Auth are you using? 1.2.10 ### Provide environment information ```bash - OS: MacOS Sequoia 15.5 - NodeJS v24.2.0 - Chrome 137.0.7151.120 (Build Resmi) (arm64) ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context Security vulnerability where protocol-specific wildcards don't enforce protocol matching.
GiteaMirror added the security label 2026-03-13 08:38:50 -05:00
GiteaMirror commented 2026-03-13 08:38:51 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jun 24, 2025):

Hi @nascode! I'm Dosu and I’m helping the better-auth team.

You’ve found a real issue: protocol-specific wildcard trusted origins (like https://*.example.com) are supposed to enforce an exact protocol match, but the current implementation in Better Auth v1.2.10 does not. The code only matches the host part when a wildcard is present, so http://api.example.com is incorrectly accepted even when only https://*.example.com is trusted. This contradicts the documentation and creates a security gap [source].

There are no workarounds or config changes documented to enforce protocol-specific origin checks, and no recent PRs address this bug. As a temporary workaround, you could explicitly list both protocol variants in your trustedOrigins array (e.g., both https://*.example.com and http://*.example.com), but this won’t restrict protocol as intended.

This is a security vulnerability and a clear mismatch between the docs and the actual behavior. If you need strict protocol enforcement, you’ll need to patch the matching logic or add a custom middleware until this is fixed upstream.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jun 24, 2025): <!-- Greeting --> Hi @nascode! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> You’ve found a real issue: protocol-specific wildcard trusted origins (like `https://*.example.com`) are supposed to enforce an exact protocol match, but the current implementation in Better Auth v1.2.10 does not. The code only matches the host part when a wildcard is present, so `http://api.example.com` is incorrectly accepted even when only `https://*.example.com` is trusted. This contradicts the documentation and creates a security gap [[source](https://github.com/better-auth/better-auth/blob/9d4861fc4484a4487efb391a4c4bdc0ef1b24933/packages/better-auth/src/api/middlewares/origin-check.ts)]. There are no workarounds or config changes documented to enforce protocol-specific origin checks, and no recent PRs address this bug. As a temporary workaround, you could explicitly list both protocol variants in your `trustedOrigins` array (e.g., both `https://*.example.com` and `http://*.example.com`), but this won’t restrict protocol as intended. This is a security vulnerability and a clear mismatch between the docs and the actual behavior. If you need strict protocol enforcement, you’ll need to patch the matching logic or add a custom middleware until this is fixed upstream. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c7465b27-1722-4fbe-9d8d-85cea3a9cac7?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c7465b27-1722-4fbe-9d8d-85cea3a9cac7?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c7465b27-1722-4fbe-9d8d-85cea3a9cac7?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c7465b27-1722-4fbe-9d8d-85cea3a9cac7?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c7465b27-1722-4fbe-9d8d-85cea3a9cac7?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c7465b27-1722-4fbe-9d8d-85cea3a9cac7?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c7465b27-1722-4fbe-9d8d-85cea3a9cac7?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3154)
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 security
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#1412
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?