CockroachDB 23.2.3 stops console JavaScript reading session cookies

Marking a session cookie HttpOnly can require changing an interface that legitimately reads it. CockroachDB 23.2.3, released on March 20, makes that change in the DB Console. The console's tenant selector had extracted information from the session cookie. The security repair moves that information retrieval behind a server endpoint so JavaScript no longer needs access to the cookie itself.

The release also marks cookies Secure when the cluster runs in secure mode. A separate addition allows JWT authentication to fetch signing keys from configured issuers. These are different authentication changes. One reduces browser script access to a session credential, while the other changes how the database obtains keys used to validate an incoming token.

I accept CockroachDB's distributed coordination costs because its consistency model is explicit. The administration interface needs equally clear boundaries around credentials. A session cookie should not have to become application data merely because a selector needs to display the identities available in the session.

Tenant selection had depended on reading the credential

The implementation discussion in pull request 119259 explains the previous dependency. The TenantDropdown component read the session cookie to extract the list of logged-in tenants. Making that cookie inaccessible to JavaScript removed the component's existing source of information, so the interface needed another way to obtain the list.

Returning the list only when login succeeds was insufficient. A user logged in to multiple tenants can switch between them without another login. The switch sets the tenant cookie and refreshes the browser. When the selector renders again, it has lost its earlier client-side initialization state. It needs a way to recover the available tenant list after that refresh.

The new server-side endpoint supplies that information whenever the component renders. This separates the data the interface needs from the credential used to authenticate the request. The browser can retain its session without giving script code direct access to the session cookie's contents. The selector's requirements no longer determine whether the credential is script-readable.

That is the substantive engineering work behind the cookie flag. Simply making the existing cookie inaccessible would have removed the selector's data source. Preserving the interaction required tracing how state is reconstructed after tenant switching, including the full refresh that occurs without a fresh login response.

Cookie flags protect different boundaries

The release notes describe HttpOnly as preventing JavaScript from reading the DB Console session cookie. Separately, the Secure setting applies to browser cookies when the cluster is in secure mode. The implementation connects that setting to the server's HTTP TLS configuration. The two flags therefore describe distinct restrictions on how the browser handles cookies.

Neither entry is presented as a replacement for the database's SQL authorization model. They concern the browser session used by the console. A role's SQL privileges remain a separate question from whether browser code can inspect its session cookie. Keeping those scopes distinct avoids claiming that a cookie flag changes what SQL an authenticated role may execute.

The conditional secure-mode behavior is also part of the feature. The notes do not say that every cluster configuration receives identical cookie attributes. They state when the Secure flag applies, while marking the session cookie HttpOnly removes the JavaScript read dependency addressed by the selector change.

I find the implementation explanation useful because it shows why authentication changes can reach apparently unrelated interface code. The tenant selector had coupled display data to a session credential. Moving the data retrieval to an endpoint permits the stronger cookie restriction while preserving the selector after a refresh.

JWT key discovery adds a different network dependency

The release adds optional signing-key discovery for clusters using JWT-based single sign-on. Setting server.jwt_authentication.jwks_auto_fetch.enabled to true enables fetching from the configured issuer, using metadata published in its OpenID configuration. When this mode is enabled, static keys in server.jwt_authentication.jwks are ignored.

That last detail makes this a choice between key sources. Adding automatic retrieval does not combine the static configuration with fetched keys according to the release description. A deployment selecting the new mode changes which source of signing keys the authentication path uses. The configured issuer becomes relevant to obtaining those keys as well as to identifying the token issuer.

The notes warn of a possible increase in network latency for each JWT authentication request, proportional to latency between the cluster and issuer endpoint. That is a specific operating cost attached to the new configuration. The key-discovery backport implements that separate path; it is not a consequence of making the console cookie inaccessible to JavaScript.

March's release therefore improves two different credential boundaries. The browser interface obtains tenant display information without reading the session cookie. JWT authentication can obtain signing keys from issuer metadata, with static configuration ignored in that mode and the issuer connection contributing to authentication latency.