Close what a leak-and-security sweep found

[ivanvyd]

Three read-only audit lenses swept the whole of src/ for memory leaks, injection and data exposure, and authorization and DoS. Every finding below was re-verified at file:line before anything was changed; several the audits raised are deliberately not changed, and why is at the bottom.

Fixed

The dashboard's own page did not encode its title. MapHealthieUI builds that one page as an interpolated string rather than through Razor, which encodes every interpolation for you — it is the single place in the library that hand-builds HTML. HealthieUIOptions.DashboardTitle is a host's setting, not a visitor's, so this only bites when a host builds it from something it did not write itself (a per-tenant label, a value out of a database). Nothing stopped such a value closing the <title> element and opening a <script> one.

A dashboard component left its handler behind when it was disposed. The service is scoped to a circuit, so the code assumed the circuit ending released everything. That holds exactly while the dashboard is mounted once per circuit — and a host that routes to HealthieDashboard inside its own layout builds a new component every time the user navigates back to it, on the same circuit. Each one left a handler that went on being called after its component was torn down, rooting the component and everything it held. IHealthieDashboardService.UnsubscribeFromStateChangesAsync is the missing half; the component calls it first thing in DisposeAsync.

Two callers scheduling one checker at once could leave a timer nothing could stop. Installing a schedule was "cancel the old one, then start the new one" — two steps, so both callers could install one and only the last stored was reachable. The other kept triggering the checker, could not be unscheduled because nothing pointed at it any more, and held a linked CancellationTokenSource that was never disposed (which leaks a registration on the parent token). A lock is the whole fix; scheduling happens at startup and when somebody changes an interval, never on a hot path.

HealthieMcpOptions.MaxHistoryPageSize was documented in the README and read by nobody. get_check_history clamped to a hard-coded 200, so a host that lowered the option to keep responses small got no such thing. Taken as an optional constructor parameter, so reading it does not change how HealthieTools is constructed.

The relational table-name guard admitted a name with a trailing newline. In .NET $ matches immediately before one as well as at end-of-string, so "state\n" passed a check whose own exception message promises "letters, digits and underscores". Verified by running the regex:

atable         current=True   with-\z=True
atable\n       current=True   with-\z=False     <-- got through
atable\n\n     current=False  with-\z=False

Not exploitable — a lone trailing newline is whitespace to all three engines and a second one fails, so no statement can be smuggled through. Fixed anyway, because a guard that admits what it documents as impossible is a bad thing to build on later.

A checker name from a REST route reached the log with its control characters intact. The not-found branch logs that name precisely when it matches no checker, percent-encoded CR/LF arrive here already decoded, and a sink writing plain text writes them as line breaks — an unauthenticated caller forging log entries. Only the 12 logging call sites are sanitised; the lookup and the response body still see the name exactly as it arrived.

Deliberately not changed

Healthie.Api requires no authorization unless the host asks for it, and HealthieUIOptions.AllowMutations defaults to true. Both were confirmed exactly as the audit described — six mutating endpoints reachable with no credentials if a host maps the controller and does nothing else. Both are documented decisions with stated reasons, and flipping either is a behaviour break for every existing consumer. That is the maintainer's call, not a cleanup to slip into a fix PR.

A checker's exception message is still reported verbatim through the REST, MCP and dashboard read surfaces. That message is the product — it is how a human finds out why a check failed. Worth knowing that a custom checker letting a driver exception through publishes whatever that driver's Message contains, but redacting it would break the feature.

Verification

389 tests green on both net8.0 and net10.0.

Mutation-tested — a passing test proves nothing until it has been seen to fail:

mutation	tests failed
the dashboard title is not encoded	1
the table-name guard ends at $ again	1
the history cap is hard-coded again	1
unsubscribing does not remove the handler	1
control characters reach the log unchanged	1

The scheduler race gets a real regression test rather than a mutation: 5/5 runs fail against the unfixed scheduler, 8/8 pass against the fixed one. Its first version was vacuous and I caught it the same way — nothing in the unfixed ScheduleAsync yields, so Task.WhenAll over 32 calls ran them strictly sequentially and no two ever overlapped. It needs a Barrier and real threads to race at all.

Healthie.Api had no test project reference at all, so it had no unit coverage; the reference is added here.

Not covered

The component's DisposeAsync calling unsubscribe is not itself tested — that needs a Blazor component harness the repo does not have (the E2E suite drives a browser, not components). The service-level unsubscribe it calls is tested and mutation-checked.

No release — version stays at 3.1.4.