Rutba

Blog · Privacy

A suffix is not an allow-list: the frames behind one sign-in

One sign-in works by small hidden pages that tell an app who is signed in. The first version trusted any address ending in our domains, which included shops running their merchants’ own code. Review caught it before it reached production.

· 3 min read

Share this

The quiet check behind one sign-in for the whole suite is a small hidden page. An app loads it in a frame, the frame asks Rutba’s sign-in who is signed in and as which organisation, and it posts the answer back to the app. It never draws anything; it is the reason a workspace knows, without asking you, that you are still you.

A page that will tell whoever embeds it who is signed in is exactly as safe as its list of who may embed it. That list is the whole security of the thing.

The list we nearly shipped

The first version reused a list that already existed: the addresses a sign-in may send you back to. Several of its production entries were suffixes (“anything ending in” one of our domains) because workspaces live on many hostnames under them, and naming every one had seemed like bookkeeping.

The review of that stage asked what else ends in those suffixes, and the answer was: shops. A merchant’s storefront lives under the same domains, and a storefront runs its merchant’s own code: the tracking snippet, the chat widget, the thing a web agency pasted in. We deliberately do not police that code; it is the merchant’s shop. But frames that trusted every address under the suffix would have answered a storefront page too: who, visiting the shop, was signed in to Rutba, which organisations they belong to, and (through the relay that hands an app its sign-in) the sign-in itself.

An allow-list is a list of things. A suffix is a list of everything that will ever be added under a name, including the things nobody has thought of yet.

Exact addresses, named one by one

So the frames got a list of their own: the suite’s own app addresses, each written out in full, scheme and host, never a suffix, never a storefront. The workspace sign-in’s own address is always on it; a developer’s own machine is allowed only in development. The same list decides which pages may embed the frames at all, and where the answer may be posted.

The list the frames used to share went the same way: the fleet’s build now names its back-office hosts one at a time there too, rather than trusting a domain wholesale. It is the rule we had already written down for the last hop of a sign-in, exact origins, never a pattern, applied to the next place it turned out to matter.

Found in review, fixed before it shipped

The frames were written, reviewed, and corrected within the same afternoon, before one sign-in reached production on 24 September. No production page ever trusted a suffix for this. We are writing about it anyway because the mistake is common, it is easy to make for a good reason, and the version of us that did not have a review stage would have shipped it.

Trust at Rutba

How sign-in works across the suite, and what we publish when something nearly goes wrong.

Read the trust page

Read next

Business Suite

How the Rutba products fit together for a small business

A shop that sells at a counter and online, delivers some orders itself and has a bookkeeper uses five Rutba products. They work as one business because they share one product list, one stock number, one order and one customer.

4 min read

How we build

Every app in the suite now opens at rutba.io

Since 6 October all 46 apps in the Rutba suite run in production, each at its own address under rutba.io, such as pos.rutba.io or books.rutba.io. Your sign-in says whose data you see, so no business needs addresses of its own.

6 min read

Share this

One family

The rest of Rutba

One account across all of it. Sign in once and the products know each other.

PORTAL-BLOG-DETAIL · 52fdb4c