Actual Budget Server Exposure: Password Access Is Only the First Boundary
Self-hosted budgeting data can reveal account structure, spending patterns, and financial plans even when transaction details are not visible in an unauthenticated response. The application-level login is therefore only one part of the exposure review. Reverse proxy, header authentication, multi-user identity, and end-to-end encryption change the trust model.
Measurement context
On 2026-11-06 08:46:13 +08:00, ZoomEye count-only queries used sub_type=all, page 1, and pagesize 1. app="Actual Budget" returned 0 matches, title="Actual Budget" returned 11, and http.body="Actual Budget" returned 1,429. The body total is a broad text match and should not be presented as an application population. The small title count is a useful candidate set for an owner who wants to compare external visibility with internal deployment records.
Password mode and OpenID solve different problems
Actual Server can use a server password. Its documentation also supports OpenID or OAuth2 when a stronger identity method and multiple users are required. The documentation says the first user to log in through that provider becomes the server owner and receives admin permissions.
That creates two review tasks. First, ensure the identity provider is configured with the intended tenant and client. Second, verify who can become the first user during initialization. An empty deployment behind a working login page can still be claimed by the wrong identity if setup is not supervised.
The project documents end-to-end encryption as optional protection for budget files. It changes what the server can read, but it does not remove the need to protect login sessions, backups, synchronization identifiers, and the server host. Treat encryption and authentication as separate controls with separate failure modes.
Review the reverse proxy and header path
Actual's header-authentication feature can automatically log in a user based on an HTTP header. The same documentation warns that this creates a responsibility: the header must come from a trusted proxy and must not be accepted from arbitrary clients. Review the proxy overwrite rules, network path, fallback password method, and logs.
For each owned instance, record the authentication mode, OpenID issuer and client, owner account, multi-user policy, reverse proxy, TLS termination, file path, backup destination, and encryption status. Test unauthenticated access to the web interface and API paths. Confirm that server responses do not expose budget names or user data before authentication.
Respond with evidence
Preserve the exact ZoomEye query and time, but do not infer that a matching title contains a specific organization or an exposed budget. Verify ownership first. If an unauthorized user reached the server, rotate credentials, revoke sessions through the identity provider and application controls, inspect proxy logs, and review backup access.
The useful external question is not whether a login page exists. It is whether every path to the budget data crosses the intended identity and authorization boundary.
Top comments (1)
Useful distinction between encryption and authentication. For a household budget, I would add a recovery drill to the deployment checklist: restore a backup into an isolated test instance and confirm that the intended user can actually decrypt it. A protected server does not help much if a lost device or failed disk makes the only usable copy inaccessible. Clear documentation of what must be backed up separately from the server would make this much more approachable for nontechnical self-hosters.