RFC: Default allow_readonly to false when security is enabled #2370
Description
Motivation
By all means, I am not a hardliner on authentication — when you're in rough seas mid-ocean, you want to turn on your device and have it work instantly without trying to remember which password was set or pulling out a Starlink to google how to reset it.
That said, significant effort has gone into hardening Signal K Server's security. The audit leading to v2.19.0 resulted in 6 CVEs being addressed — including critical ones like CVE-2025-66398 (unauthenticated RCE, CVSS 9.6) and CVE-2025-68620 (JWT token theft). The full list is on the Security Advisories page.
The problem
Given all that effort, we still leave users in a false sense of security when they enable authentication: by default, Security → Settings → Allow Readonly Access is enabled. This means all Signal K data — navigation, AIS, sensor readings — remains openly accessible to anyone on the network without any credentials. A user who just enabled security reasonably expects that access is now restricted.
Lack of documentation
This default behavior is entirely undocumented. The security documentation guides users through enabling security and creating an admin account, but never mentions that allow_readonly defaults to true. The security architecture document shows "allow_readonly": true in an example JSON snippet but provides no explanation of its implications. The Admin UI toggle itself carries no tooltip or warning. There is no documentation on signalk.org that mentions this setting at all.
The practical result: a user who follows the documented steps to "enable security" has no reason to suspect — and no documented way to learn — that their navigation data, AIS targets, and sensor readings remain openly accessible to anyone on the network.
What this PR changes
This PR closes that gap by changing the default to false. Existing installations are not affected — their security.json already has an explicit value written.
Companion PRs
For users who want to share data from their own NMEA 2000/CAN-equipped hardware with other Signal K servers, #2365 implements token-based authentication for WebSocket provider connections, allowing secure server-to-server access even when Allow Readonly Access is disabled.
#2369 complements this by adding token expiry tracking and visibility in the admin UI, so administrators can easily see remaining token lifetime and identify expired tokens.
Impact on demo.signalk.org
For demo.signalk.org, re-enabling anonymous read access during automated deployment is a one-line configuration change.