[GH-ISSUE #3128] (Tanstack start) Secure cookie not being used by default in a production setting #18114

Closed
opened 2026-04-15 16:29:45 -05:00 by GiteaMirror · 3 comments
Owner

Originally created by @AlexMenor on GitHub (Jun 22, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3128

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  • My project uses the tanstack start plugin reactStartCookies is passed as the last plugin
  • The cookie is only secure if I explicitly pass useSecureCookies as true in the advanced config
  • The docs suggest that this should be done by default in such a setting (HTTPS domain with a production environment NODE_ENV)

Current vs. Expected behavior

Expected cookies to be secure without by default

What version of Better Auth are you using?

1.2.8

Provide environment information

Linux server, tanstack start

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

Backend

Auth config (if applicable)

export const auth = betterAuth({
  database: drizzleAdapter(db, {
    provider: "pg",
  }),
  plugins: [organization(), admin(), reactStartCookies()],
  emailAndPassword: {
    enabled: true,
  }
});

Additional context

No response

Originally created by @AlexMenor on GitHub (Jun 22, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3128 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce - My project uses the tanstack start plugin `reactStartCookies` is passed as the last plugin - The cookie is only secure if I explicitly pass `useSecureCookies` as true in the advanced config - The docs suggest that this should be done by default in such a setting (HTTPS domain with a production environment NODE_ENV) ### Current vs. Expected behavior Expected cookies to be secure without by default ### What version of Better Auth are you using? 1.2.8 ### Provide environment information ```bash Linux server, tanstack start ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript export const auth = betterAuth({ database: drizzleAdapter(db, { provider: "pg", }), plugins: [organization(), admin(), reactStartCookies()], emailAndPassword: { enabled: true, } }); ``` ### Additional context _No response_
GiteaMirror added the locked label 2026-04-15 16:29:45 -05:00
Author
Owner

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

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

According to the docs, cookies should be secure by default when running in production mode—you only need to set useSecureCookies if you want to override this behavior or force it in development. The reactStartCookies plugin uses environment detection (typically NODE_ENV) to decide if cookies should be secure. If you're seeing insecure cookies in production, double-check that your environment is actually being detected as "production" (for example, NODE_ENV is set to "production" at runtime). If NODE_ENV or a similar variable isn't set as expected, the plugin may not enable secure cookies automatically, which matches what you're seeing. You can find more details in the docs and related discussions:

If you want to guarantee secure cookies regardless of environment detection, explicitly set useSecureCookies: true in your config.

To reply, just mention @dosu.


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

<!-- gh-comment-id:2994140789 --> @dosubot[bot] commented on GitHub (Jun 22, 2025): <!-- Greeting --> Hi @AlexMenor! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> According to the docs, cookies should be secure by default when running in production mode—you only need to set useSecureCookies if you want to override this behavior or force it in development. The reactStartCookies plugin uses environment detection (typically NODE_ENV) to decide if cookies should be secure. If you're seeing insecure cookies in production, double-check that your environment is actually being detected as "production" (for example, NODE_ENV is set to "production" at runtime). If NODE_ENV or a similar variable isn't set as expected, the plugin may not enable secure cookies automatically, which matches what you're seeing. You can find more details in the docs and related discussions: - [Docs: "By default, cookies are secure only when the server is running in production mode."](https://better-auth.com/docs/concepts/cookies) - [Discussion of default cookie attributes and environment detection](https://github.com/better-auth/better-auth/discussions/2826) If you want to guarantee secure cookies regardless of environment detection, explicitly set useSecureCookies: true in your config. <!-- 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/1a8a83ee-65d9-4863-a636-b054b07a3db1?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/1a8a83ee-65d9-4863-a636-b054b07a3db1?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/1a8a83ee-65d9-4863-a636-b054b07a3db1?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/1a8a83ee-65d9-4863-a636-b054b07a3db1?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/1a8a83ee-65d9-4863-a636-b054b07a3db1?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/1a8a83ee-65d9-4863-a636-b054b07a3db1?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/1a8a83ee-65d9-4863-a636-b054b07a3db1?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/3128)
Author
Owner

@AlexMenor commented on GitHub (Jun 22, 2025):

Ok I figured it out. I was not setting BETTER_AUTH_URL, and it infers the context from there (I assume it would do so from the request context). So setting the variable or passing baseUrl as a parameter would do.

While the documentation is generally very good, this would be a good improvement point :)

<!-- gh-comment-id:2994148551 --> @AlexMenor commented on GitHub (Jun 22, 2025): Ok I figured it out. I was not setting BETTER_AUTH_URL, and it infers the context from there (I assume it would do so from the request context). So setting the variable or passing baseUrl as a parameter would do. While the documentation is generally very good, this would be a good improvement point :)
Author
Owner

@ping-maxwell commented on GitHub (Jun 22, 2025):

Hey thanks for the feedback, I've passed that onto the team!
For now I'll close this as it's solved.

<!-- gh-comment-id:2994326580 --> @ping-maxwell commented on GitHub (Jun 22, 2025): Hey thanks for the feedback, I've passed that onto the team! For now I'll close this as it's solved.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#18114