Security Is a Practice, Not a Score

When people take the time to report security concerns, they are helping protect everyone who trusts Simple Money Tracker with personal financial data. We are grateful for that trust—and for every careful report we receive.

This post is not a victory lap. It is a short account of a review cycle we ran seriously: code and access-control fixes (Milestone 81 / v4.22.0), Firestore rules work, and a structured look at our HTTP API surface with industry tooling (including 42Crunch). Numbers and checklists help us measure effort. They do not mean the product is “done” or immune to mistakes.

What we focused on in this cycle

A recurring lesson in web apps is simple but easy to get wrong: the server must not trust a client-supplied user id or storage path. After authentication, ownership has to come from the verified session—not from a field the caller can rewrite.

In this milestone we tightened that pattern across several surfaces that handle sensitive actions or user-owned data, including:

• Admin-only actions such as broadcasting notifications—restricted with strict admin verification, not “any logged-in user.”
• File storage download and delete paths—callers may only act on resources under their own account.
• Passkey registration and deletion—identity derived from a verified token, not a free-form user id parameter.
• Gift activation and selected test endpoints—production test routes disabled; gift flows bound to the authenticated user and server-side time checks.
• Group membership—access modeled around who is actually allowed in the group, not “any authenticated user can read everything.”
• Scheduled notification jobs—moved off direct client writes; schedule/cancel go through authenticated APIs with ownership checks, and client rules deny raw job collection access.
• Subscriber and related privacy rules—narrower read/write paths so billing-related records are not broadly readable.

Why we also audit the API map

Application fixes address how the running server behaves. Separately, we maintain an OpenAPI description of our HTTP API and run static security assessments against that contract (42Crunch API Security Audit).

Those assessments answer a different question: “Is the API description clear and complete enough about authentication, responses, and data shapes?” Improving the map when it honestly matches the code is legitimate engineering work. It is not the same as inventing security that the server does not enforce.

In our recent re-audit of that contract—after aligning global Bearer authentication modeling, documenting the intentionally public passkey login route, and completing standard response definitions for remaining operations—the overall assessment score was about **88 / 100** (security and data sub-scores in the high twenties and high fifties out of their respective maxima). Earlier in the same hardening journey, the same style of assessment on a much weaker description sat far lower. We share the ballpark figure only as a **relative measure of documentation and modeling effort**, not as a warranty.

Checks with more than one account

Where it made sense, we also exercised live authorization behavior with separate test accounts—for example, confirming that one user cannot download another user’s storage path, and that non-admin accounts cannot call admin broadcast notification APIs.

Those checks were scoped (including local testing for some runs). They support confidence on specific issues; they are not a claim that every endpoint in the product has been exhaustively pen-tested in production.

What we are not claiming

Honesty matters more than a perfect headline. In particular:

• We are not claiming 100% security or that no issue will ever appear again.
• We are not claiming a perfect gate score on every automated quality rule—some findings remain by design (for example, webhook authentication patterns that are normal for third-party providers) or as accepted product residuals we track openly.
• We are not claiming that static contract scores equal runtime safety. Both matter; they measure different things.
• Encryption and zero-knowledge design reduce what the server can read; they do not remove the need for careful authorization, rules, and review.

How we intend to keep going

Security and privacy for a personal finance app are ongoing habits: review feedback carefully, fix root causes in code and rules, keep the API description honest, re-run assessments when the surface changes, and sample live authorization on high-risk paths.

If you ever notice something that feels wrong—an unexpected permission, a confusing error, or a place that seems too open—please tell us. Thoughtful reports help us prioritize real work over assumptions.

Thank you for trusting Simple Money Tracker, and thank you to everyone who has taken the time to look carefully at how we protect accounts and data. We will keep reviewing, keep fixing, and keep measuring progress without pretending the work is finished.