Skip to content

fix(console): mark the session cookie Secure when the server serves TLS - #773

Merged
hitesh96db merged 1 commit into
mainfrom
fix/687-secure-session-cookie
Nov 5, 2026
Merged

hitesh96db merged 1 commit into
mainfrom
fix/687-secure-session-cookie

Conversation

@LeeroyHannigan

Copy link
Copy Markdown
Collaborator

The console set its session cookie, and the cookie that clears it on logout, as extenddb_session=<token>; Path=/console; HttpOnly; SameSite=Strict; Max-Age=28800 without Secure. A browser attaches such a cookie to a plain http:// request to the same host. The login response also sends HSTS, but a browser does not record HSTS for a host given as an IP address or over a connection with certificate errors, which includes the self-signed certificate extenddb init creates. On such a host, an http:// request the browser is led to send carries the session token in clear text, ahead of the server's redirect to HTTPS.

Change

  • ConsoleState gains secure_cookies, set from AppState.tls_enabled, whose doc comment already said it affects the cookie's Secure flag.
  • Both cookies come from a new session_cookie, which appends Secure when secure_cookies is set.
  • A dev-mode build serves plain HTTP and leaves Secure off. There Secure protects nothing, and an HTTP client that does not treat the loopback origin as secure, such as the Python requests client the console tests use, would not send the cookie back. Browsers exempt localhost from the Secure rule.
  • docs/manuals/10-security-model.md lists the attribute.

The cookie keeps its name. A __Secure- prefix, which the issue mentions as optional, would also change extract_session_token and end every open session at upgrade.

Tests

  • Unit tests in auth_pages.rs check the login and logout cookies with and without Secure. They compare the attributes as a set after the name=value pair.
  • test_login_redirects_to_dashboard and test_logout_clears_session in tests/test_console_integration.py check that Secure is present exactly when the endpoint is HTTPS. Every job that runs that file uses an https:// endpoint.

Testing

  • cargo +1.97.0 fmt --all -- --check and cargo +1.97.0 clippy -p extenddb-server --all-targets -- -D warnings: clean.
  • cargo +1.88.0 test --locked -p extenddb-server: 252 passed.
  • devtools/run-tests --extenddb --pytest --filter "TestConsoleAuth or TestConsoleRoles": 10 passed against a TLS build (--features sqlite, extenddb init, serve on https://127.0.0.1) and 10 passed against a dev-mode build (plain HTTP). On the TLS build, login answered Path=/console; HttpOnly; SameSite=Strict; Max-Age=28800; Secure, and the next request with the cookie got the dashboard.
  • With secure_cookies forced false, the login and logout tests fail on the TLS build. With it forced true, they fail on the dev-mode build, and so does test_dashboard_accessible_after_login, because the client no longer sends the cookie over HTTP.

No browser was driven; the HSTS and localhost statements above follow RFC 6797 and the Set-Cookie documentation.

Overlap with #704

#704 rewrites the same line of docs/manuals/10-security-model.md (the session expiry wording), so the two conflict on that line only.

Fixes #687.

The console set its session cookie, and the cookie that clears it on
logout, with HttpOnly, SameSite=Strict and Path=/console but without
Secure. A browser attaches such a cookie to a plain http:// request to
the same host. The login response also sends HSTS, but a browser does not
record HSTS for a host given as an IP address or over a connection with
certificate errors, which includes the self-signed certificate extenddb
init creates. On such a host, an http:// request the browser is led to
send carries the session token in clear text, ahead of the server's
redirect to HTTPS.

ConsoleState gains secure_cookies, set from AppState.tls_enabled, whose
doc comment already said it affects the cookie's Secure flag. Both
cookies come from session_cookie, which appends Secure when it is set.
A dev-mode build serves plain HTTP, where Secure protects nothing and an
HTTP client that does not treat the loopback origin as secure, such as
the Python requests client the console tests use, would not send the
cookie back, so it leaves Secure off. The security model guide lists the
attribute.

Unit tests check both cookies with and without Secure. The console login
and logout tests check that Secure is present exactly when the endpoint
is HTTPS. Against a TLS SQLite build and a dev-mode build on 127.0.0.1,
the console auth and role tests pass. With secure_cookies forced false,
the login and logout tests fail on the TLS build. With it forced true,
they fail on the dev-mode build, and so does the dashboard test, because
the client no longer sends the cookie over HTTP.

Fixes #687.

@hitesh96db hitesh96db left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@hitesh96db
hitesh96db added this pull request to the merge queue Nov 5, 2026
@hitesh96db hitesh96db added v1 Needed for the 1.0 release security labels Nov 5, 2026
Merged via the queue into main with commit 94b5f68 Nov 5, 2026
39 checks passed
@hitesh96db
hitesh96db deleted the fix/687-secure-session-cookie branch November 5, 2026 03:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

security v1 Needed for the 1.0 release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

console: the session cookie has no Secure attribute

2 participants