16,000 Databases Were Leaking and Not One Was Hacked — I Re-Ran Our Dubai Backend Interview and Cut 3 Questions

Yesterday afternoon Dubai time, TechCrunch published a story by Zack Whittaker under the headline “Some Supabase customers are publicly exposing reams of people’s data to the web.” The number in it is large enough to be quoted everywhere this week: security firm UpGuard found roughly 16,000 databases hosted on Supabase that were exposing some degree of personal information to anyone who asked for it. What makes it worth an employer’s attention is not the number. It is that nothing was broken into.

What Actually Happened, Precisely

Supabase is a hosted Postgres platform with a client library that talks to the database directly from the browser. That design is deliberate and it is not the flaw. The public client key is meant to ship inside the JavaScript bundle that every visitor downloads, and the thing standing between that key and your tables is row level security: per-table rules that decide which rows a given request may see.

When those rules are absent or written permissively, the arrangement inverts. The public key still works exactly as designed, and every table behind it becomes, in effect, a public read endpoint. UpGuard’s researchers found that outcome at scale, across projects holding names, addresses, phone numbers, passwords and authentication tokens. The examples reported range from private conversations on streaming platforms to licence plates collected by valet services, immigration service contact records and consulate databases.

Supabase, whose CISO Bil Harmer told TechCrunch that projects are “secure by default” and that “security at Supabase is never finished. We care deeply about getting it right,” frames this as a shared responsibility between the platform and the customer. On the technical merits that framing is defensible. The platform gives you the mechanism; somebody has to write the policy. The uncomfortable question for anyone who hires engineers is who that somebody is, and whether your interview has ever checked that they can.

The Two Skills Everyone Calls One Skill

In nearly every backend job description we review for UAE employers, security appears once, as a bullet, and it means authentication: login, sessions, tokens, password hashing, perhaps multi-factor. Authentication answers who are you. It is well-documented, heavily tooled, and largely solved by libraries that a competent developer can wire up correctly on the first attempt.

Authorisation answers a different and much harder question: given that I know who you are, what are you allowed to touch. It is specific to your data model, it cannot be delegated to a library, it has no green checkmark when it is right, and — critically — an application with zero authorisation logic looks completely normal to the user who is logged in. Every screen works. Every request returns data. The failure is invisible from the inside, which is precisely why 16,000 teams shipped it.

This asymmetry is why the skill is systematically under-screened. A candidate who has never written an authorisation rule in their life can describe token flows fluently, because token flows are what the tutorials cover. Ask them who may read row 4 of a shared table and you often get a restatement of the login process. We have been running that question for a while now; it still surprises us how reliably it splits a shortlist.

Why This Lands Harder on Dubai Product Teams

There is a shape of company that is very common here and unusually exposed to this specific failure. A founder or a small agency builds the first version fast, frequently with generated scaffolding, to get in front of a customer or an investor. It works. It gets traction. Six months later the company raises, hires its first two or three engineers, and those engineers inherit a codebase whose access rules were set by whatever made the demo run.

Nobody in that sequence is negligent. Permissive policies are what make a prototype work on the first attempt, and tightening them is a separate, invisible, unrewarded task. The problem is that the inheritance is silent: the new team sees an application that functions, so the audit never gets scheduled. We have walked into exactly this situation more than once while scoping a backend search, and in the cases where we asked, the founders did not know the question existed.

The 3 Questions We Cut, and What Replaced Them

Our Dubai backend loop had three security questions that we have now removed, because after yesterday we could not defend any of them as evidence of anything.

1. “How do you store passwords securely?” — every candidate says bcrypt or argon2. It measures whether they have read the same article as everyone else.
2. “Explain JWT versus session cookies.” — a genuine topic, and entirely authentication. It would have been answered perfectly by engineers on all 16,000 of those projects.
3. “What is the OWASP Top 10?” — a recall question about a list. Broken access control has sat at the top of that list for years, which makes the answer even less predictive: candidates can name it without being able to spot it.

What replaced them is one exercise that takes eight minutes. We hand the candidate two tables — an organisations table and a documents table with a tenant column — and a single access policy that checks the requester is authenticated but never checks which tenant they belong to. Then we ask one question: who can read what?

The spread was wider than we expected. Strong candidates read the policy, find the missing tenant comparison in under a minute, and then do the thing we actually care about: they ask what else in the schema shares that pattern. A second group spots that something is off but cannot articulate the consequence. A third group tells us the policy looks correct because authentication is enforced — and several of those had answered all three of the questions we cut without a flaw. That gap between the two sets of answers is the whole argument for the change.

What This Changes in the Job Description

Screening is half of it. The other half is that an access-policy audit has to be somebody’s named job, with a date on it, or it will not happen. We now write it into the first-month expectations for any backend hire joining a product that began as a prototype: enumerate every table, state for each one who may read and write it, and flag the ones where the answer is “anyone authenticated”. It is a week of unglamorous work and it is the cheapest week that company will ever buy.

The same reasoning is why we no longer treat this as a specialist security requirement. It belongs in the standard backend brief, in the way that writing tests does. Teams that do want a dedicated specialist on top of that should read our note on hiring application security engineers in Singapore, which covers the same distinction from the specialist side, and the Singapore team’s write-up of the auth-bypass CVE in AI application stacks from earlier this year, which is the closest precedent we have written about.

FAQ — What Employers Are Asking Us About This

Source: Zack Whittaker, “Some Supabase customers are publicly exposing reams of people’s data to the web,” TechCrunch, 25 September 2026, reporting research by UpGuard. Quotations from Supabase CISO Bil Harmer as published in that report.