Self hosted instance creates insecure cookies on https potentially exposing better-auth.session_token plaintext #4709

Activity

1. samiyuru

   added

   needs-triage🔍

   on Jun 30, 2026
2. dosubot

   added

   bugSomething isn't workingSomething isn't working

   on Jun 30, 2026
3. dosubot commented on Jun 30, 2026

   

   dosubotBot

   on Jun 30, 2026 – with DosuBot

   More actions

   Hi @samiyuru! I'm Dosu and I'm helping the Dokploy team.

   You're correct that the better-auth.session_token cookie is not marked as secure on self-hosted instances, even when served over HTTPS. This is because the cookie attributes are hardcoded in the auth configuration rather than being dynamically set based on the connection protocol.

   In packages/server/src/lib/auth.ts, when IS_CLOUD is false (i.e., all self-hosted deployments), the config explicitly sets:

   advanced: {
     useSecureCookies: false,
     defaultCookieAttributes: {
       sameSite: "lax",
       secure: false,
       httpOnly: true,
       path: "/",
     },
   }

   This means secure: false is applied regardless of whether HTTPS is configured via Traefik. The likely reason this was done is to support self-hosted instances that run over plain HTTP or sit behind reverse proxies handling TLS termination — but as you noted, it means the session token can be sent in plaintext if the browser makes an HTTP request.

   There's currently no environment variable to toggle this behavior. A fix could involve either:

   1. Detecting whether the instance is served over HTTPS (e.g., checking if a certificate resolver is configured in Traefik) and conditionally setting secure: true
   2. Adding an environment variable (e.g., SECURE_COOKIES=true) that users can set to enable the secure flag

   To reply, just mention @dosu.

   ---

   Share context across your team and agents. Try Dosu.

   
4. Siumauricio commented on Aug 4, 2026

   

   Siumauricio

   on Aug 4, 2026

   Contributor

   More actions

   Reproduced and confirmed on v0.29.13 — the session cookie is issued without the Secure attribute even when the request arrives over TLS.

   Test (local instance, login via /api/auth/sign-in/email):

   Plain HTTP request:

   set-cookie: better-auth.session_token=...; Max-Age=259200; Path=/; HttpOnly; SameSite=Lax
   

   Same request with X-Forwarded-Proto: https (what Traefik sends when the instance is served over TLS):

   set-cookie: better-auth.session_token=...; Max-Age=259200; Path=/; HttpOnly; SameSite=Lax
   

   Secure is absent in both cases, so a self-hosted instance behind HTTPS does hand out a cookie the browser will replay over plain HTTP — exactly as you described. HttpOnly and SameSite=Lax are set, which limits it, but this should carry Secure whenever the deployment is HTTPS.

   Keeping this open as a confirmed bug.
5. Siumauricio

   removed

   needs-triage🔍

   on Aug 4, 2026
6. narcisonunez

   added a commit that references this issue on Sep 29, 2026

   fix: mark session cookie as Secure when served over HTTPS

   ...

   This issue will close once commit f5c21db is merged into the 'canary' branch.

   f5c21db
7. narcisonunez

   closed this as completedin #5022on Sep 29, 2026
8. cursor

   added a commit that references this issue on Oct 5, 2026

   fix: mark session cookie as Secure when served over HTTPS

   ...

   This issue will close once commit 1049e62 is merged into the 'canary' branch.

   1049e62
9. rossreicks

   added a commit that references this issue on Oct 11, 2026

   fix: mark session cookie as Secure when served over HTTPS

   ...

   This issue will close once commit 28ebc38 is merged into the 'canary' branch.

   28ebc38
10. github-actions

    added a commit that references this issue on Oct 12, 2026

    chore(release): 0.42.0 [skip ci]

    ...

    63ce614