Security hardening — rate limits and stricter tenant fences

A round of quiet-but-important security work landed this week. Nothing visible during normal use, but a few ways Whal could be pushed around are now closed off.

Rate limiting on login

We now throttle login attempts both per email and per IP address. Five bad tries against the same account in fifteen minutes pauses the account briefly; the same window per IP catches automated credential-stuffing bots. The demo account is exempted so marketing demos always succeed.

The limiter is Postgres-backed and fails open — if the limiter itself has a problem, logins continue to work rather than locking everyone out.

Tighter tenant isolation across the admin surface

Every action that reads or writes tenant data now goes through a single, shared helper that checks the caller's tenant before the database is touched. A few admin-level functions had been taking a client ID from the request and trusting it without a follow-up ownership check — those have been closed. A scoped admin (for example, the demo account) can no longer list another client's products, pallets, invoices, or dispatch orders, and can no longer push another tenant's invoices to Xero or MYOB.

Billing rollup is platform-admin only

The monthly billing rollup runs across every tenant in the period. The permission check has been tightened so only platform admins — not tenant-scoped admins — can trigger preview or commit.

What this means for you

Nothing to do. Existing sessions keep working; the changes are behind the scenes. If you're an ops user, you may notice that logging in with a bad password a handful of times now pauses you for fifteen minutes — the message is the same as a wrong-password error so attackers can't tell the difference.