Security Overview

1.How we think about this

This software holds records of what people own, earn, and spend. That makes two failure modes unacceptable: one customer seeing another’s books, and a customer’s books being wrong without anyone noticing.

Most of what follows exists to make those two things structurally difficult rather than merely against policy. Where a guarantee can be enforced by the database instead of by application code, it is — application code changes every week, and a constraint holds even when a new code path forgets the rule.

2.Keeping accounts separate

Your data lives in a workspace, and the workspace is the boundary. Three separate mechanisms keep it that way:

• Every row carries its workspace. Properties, units, ledger accounts, entries, lines, documents — each one stores the workspace it belongs to, and every query filters on it.
• Scoping happens on the server. The browser never decides what you can see. Each page and each action independently proves your identity and resolves your workspace before it reads anything.
• A composite foreign key. A ledger line can only attach to an entry in the same workspace — not as a check in code, but as a database constraint. A bug that tried to cross workspaces would fail the write.

Identifiers are unguessable, so knowing a URL is not a way to reach a record — and a request for a record in someone else’s workspace returns “not found” rather than “forbidden”, which avoids confirming that the record exists.

Row-level security in the database is the next layer, planned so that a missed filter fails closed rather than leaking. See section 10.

3.Authentication

• Passwords are stored as salted hashes using a modern memory-hard algorithm. We cannot recover your password, and a reset works by issuing a new single-use token rather than by revealing the old one.
• Minimum length is 10 characters, with no composition rules that push people toward predictable substitutions.
• Sessions are server-side records referenced by an HttpOnly, Secure, SameSite cookie. JavaScript cannot read the token, and revoking a session takes effect immediately because the record is deleted.
• Rate limiting caps sign-in, sign-up, and password-reset attempts, which blunts credential stuffing per IP.
• Bot protection — Cloudflare Turnstile guards sign-in, sign-up, and reset requests, verified on the server so a client cannot skip it by not rendering the widget.
• Reset tokens expire in 30 minutes, are single use, and are invalidated once used. Changing your password revokes every session, including the one that changed it.
• Enumeration resistance — sign-in and password-reset responses do not reveal whether an address is registered.
• Your own visibility — you can see your active sessions, with the address and device that started each, and end all of them.

4.Authorization and staff access

Inside your workspace

Roles decide what a member can do. A read-only role exists specifically so you can give an accountant or bookkeeper full visibility with no ability to change a record, and it is enforced on the server for every write.

Our staff

Staff access is a separate ladder from customer accounts, and no normal signup can obtain it:

• Support can read accounts and leave notes. It cannot change anyone’s access, plan, or data.
• Admin can suspend and reactivate accounts, move plans, and revoke sessions.
• Superadmin — the only role that can grant staff access or delete data. Deliberately rare.

Every staff action against an account writes an audit record in the same database transaction as the change, so the log cannot disagree with what happened. Each record keeps who acted, what they did, to whom, from what address, and when. The application has no way to edit or delete those records.

Staff roles are re-read from the database on every request, so revoking access takes effect on that person’s next click rather than whenever their session happens to refresh.

5.Integrity of your books

Your books are kept as double-entry underneath a simpler interface, and the integrity rules are enforced by the database:

• Entries must balance. A deferred constraint trigger checks at commit time that every entry’s lines sum to exactly zero. A code path that tried to write an unbalanced entry fails.
• Money is never a floating-point number. Amounts are integer cents, so no rounding drift accumulates in your totals.
• Entries are immutable. Corrections post a reversing entry linked to the original. Nothing overwrites history, which means a figure you reported last quarter still reconciles today.

These invariants are covered by tests that deliberately bypass the application layer and write to the database directly, because the point is that the database refuses — not that our code remembers to ask.

6.Encryption and backups

• In transit — HTTPS everywhere, with certificates renewed automatically. Strict transport security, and a content security policy that restricts where scripts may load from.
• At rest — the database and uploaded documents sit on encrypted volumes on infrastructure we control.
• Documents are stored under keys derived from your workspace, served only through authenticated, workspace-scoped links, and never listed publicly.
• Backups — the database is backed up on a schedule to separate encrypted storage, with the retention in the Privacy Policy.
• Secrets are held in the deployment environment, never in source control, and never rendered into a page.

A backup nobody has restored is a hypothesis, not a backup. Restore rehearsal is tracked as required work before launch — see section 10.

7.What we deliberately do not hold

The most reliable way to protect data is not to hold it. We deliberately do not store:

• Card numbers. Payments go to a PCI-compliant processor; we hold a token, the brand, and the last four digits.
• Online banking credentials. When you connect a bank, you give your credentials to the bank-data provider, never to us, and the connection is read-only — we cannot move money.
• Social Security numbers or other government identifiers.
• Tenant screening reports. Screening stays with the provider that is the consumer reporting agency; we do not receive report contents, which keeps those obligations where they belong.
• Analytics inside the app. The pages showing your portfolio are excluded from analytics entirely, because their URLs identify your records.

8.Monitoring and error reporting

Errors are reported to a self-hosted error tracker on infrastructure we control, so diagnostics do not travel to a third-party service.

Before any report leaves the server it is scrubbed:

• session cookies and authorization headers are removed;
• fields that look like credentials — passwords, tokens, secrets, confirmation values — are replaced;
• the only identity attached is your account id, which is enough for us to find the account without copying your name or email into a second system.

A health endpoint checks the database on every probe, so a process that is running but cannot serve is restarted rather than left in rotation.

9.Third parties

Every third party that can touch customer data is listed, with what it receives, in the Privacy Policy. Two categories that normally involve a vendor — error tracking and analytics — are self-hosted here specifically to reduce the number of parties holding your information.

Before adding a processor we consider what it would receive, whether the feature is worth that exposure, and whether it can be scoped down. We publish the list, and we give notice before a new processor starts handling customer records.

10.Implemented today, and what is not

Stated plainly, because a security page that overstates is worse than no security page.

If a certification or a completed test matters for your decision, ask us before you commit — the answer today is in the table above, and we will not imply otherwise.

11.Reporting a vulnerability

If you find a vulnerability, please tell us at security@realestateincometracker.com. Include enough detail to reproduce it — a URL, the steps, and what you observed.

Our commitments to you

• We acknowledge reports within 3 business days.
• We give an initial assessment within 10 business days, and keep you updated until it is closed.
• We will credit you publicly if you want that, and stay quiet if you do not.
• Safe harbour: if you act in good faith within the rules below, we will not pursue legal action against you, and we will say so to anyone who asks.

Rules

• Only test against accounts you control. Create your own workspace — free accounts exist for this.
• Do not access, modify, or retain another customer’s data. If you encounter it accidentally, stop, tell us, and delete anything you retrieved.
• No denial of service, no load or stress testing, no spamming our email or SMS providers, and no social engineering of our staff or customers.
• Give us reasonable time to fix an issue before publishing it.

We do not currently run a paid bug bounty, so a report earns thanks, credit, and a fix — not money. We would rather say that up front than imply a reward.

Machine-readable contact details are published at /.well-known/security.txt.

12.Your side of it

Most account compromises we could not prevent, so the few things that help most:

• Use a unique password from a password manager. Reused passwords are how accounts are taken over.
• Give each person their own login rather than sharing one — it is also the only way the audit trail means anything.
• Use the read-only role for anyone who only needs to look, such as your accountant.
• Review your active sessions occasionally and revoke anything unfamiliar.
• Export your records periodically. Our backups are for our recovery, not a substitute for a copy you hold.
• Tell us fast at security@realestateincometracker.com if you suspect someone else is in your account. We can end every session immediately.