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

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

