Better Auth · Pipe

trustedOrigins

trustedOrigins defines additional origins that Better Auth accepts during request validation. It supports exact origins, wildcard patterns, and dynamic functions, while the app's baseURL is trusted by default.

How it works

trustedOrigins extends the default base URL with origins Better Auth accepts during origin validation. It can be a static array, wildcard patterns, or an asynchronous function that computes origins from the request; dynamic functions must also handle initialization calls where the request is undefined.

Syntax

trustedOrigins: string[] | ((request?: Request) => string[] | Promise<string[]>)

Parameters

Name	Type	Description
`trustedOrigins`	`string[] \| ((request?: Request) => string[] \| Promise<string[]>)`	A static array of origin strings, wildcard origin patterns, or an asynchronous function returning origins; the function receives a request that may be undefined.

Returns

Not applicable; this is a Better Auth configuration option.

Key points

The application's baseURL is trusted automatically; use this option for additional origins.
The option supports static arrays, dynamic providers, and wildcard matching.
Wildcard patterns let one entry cover matching subdomains.
The setting contributes to CSRF protection and prevents unsafe redirect behavior.
Mobile and server-to-server clients must list any Origin or Referer value they send.

Common mistakes

Remove localhost entries from production configurations.
Dynamic providers must return safe default origins when no request is supplied.
Every browser, mobile, or server origin that sends origin metadata must be explicitly covered.

Example: Configure trusted origins

import { betterAuth } from "better-auth";

export const auth = betterAuth({
  trustedOrigins: [
    "https://app.example.com",
    "https://*.example.com",
    "http://localhost:3000",
  ],
});

Configure exact origins and an HTTPS wildcard for subdomains in the Better Auth instance.

When to use it

Allow additional frontends

A separate frontend, dashboard, or local development server makes authenticated requests to the Better Auth backend.

Trust matching subdomains

Several subdomains share one authentication service.

Resolve origins dynamically

Tenants or deployments require origin decisions based on each incoming request.

Interview questions

QWhat forms can trustedOrigins take?

trustedOrigins is a Better Auth option for adding origins beyond the application's baseURL. It accepts a static list, wildcard patterns, or a function that returns the list.

Follow-up: What must a dynamic provider do during startup? It must handle an undefined request and return default trusted origins.

QWhat security purpose does trustedOrigins serve?

Better Auth validates request origin information against the configured trusted origins. Origins that are not accepted are rejected, helping defend against CSRF and open redirects.

Follow-up: Why should an origin list be narrow? An overly broad list expands the set of sources accepted by the authentication endpoints.

QHow do wildcard trusted origins work?

Wildcard entries match multiple subdomains, and a scheme can constrain the match to HTTP or HTTPS. For example, an HTTPS wildcard can cover HTTPS subdomains of example.com.

Follow-up: What should be checked before using a wildcard? Confirm that the domain and protocol scope do not include unintended applications.

baseURL
isTrustedOrigin
Origin validation
CSRF protection
open redirects

Source: Options | Better Auth. Checked 2026-10-15.