Checking membership inside Postgres policies closes a 15.5-minute revocation gap in a no-backend app

Nothing in the request path checks whether a membership still exists. Neon Auth writes the active team into the token's o claim, and it only does so for a team the user belongs to ^[4]. The Data API verifies the token on every request against Neon Auth's keys and runs the query as the authenticated role ^[12]. Inside Postgres, auth.organization_id() returns the claim, and every policy is org_id = auth.organization_id() ^[3]. A token signed before the removal still names the old team, and its signature still verifies ^[9]. After removal, the old token read, wrote and called the RPC, and it kept reading for its full 900 seconds plus 28 ^[9]. The total is 928 seconds, about 15.5 minutes ^[1]. The write-up does not explain the extra 28 seconds.

The policies as first written could not close that window. The authors' fix did. They added a check against Neon Auth's member table inside the policies, and access ended at once ^[10]. In their latency run, reads and writes stayed within a millisecond and the RPC got about 5 ms slower ^[10]. For a team board I would take that trade. Removal from a team is a security event, and I would not accept a quarter hour of read access after it. These figures come from one task board, though. For them to hold elsewhere, the membership lookup has to stay a cheap indexed read beside the query it guards. The RPC is where the check cost most, and it is the number I would re-measure on my own schema first.

I would copy the attack suite. Authorization lives in RLS policies, column grants and one function ^[2]. Eve, the second team's owner, attacked with a valid account and a script ^[5]. Most attackers start with less. Each of the 27 attempts had to return exactly the expected answer, and the suite compared every column of the victim's rows before and after ^[6]. A refusal that altered any victim data would have counted as a failure ^[6].

Then the authors tested the suite. They broke the security layer four ways, one at a time, and the suite caught each of the three breaks that let attacks through ^[7]. The fourth, a sloppy WITH CHECK (true), let nothing through on its own because the client is never granted the org_id column ^[8]. Adding table-wide grants on top of it opened the hole ^[8].

Those 27 refusals cover the 27 attacks the authors chose, among them forged tokens, alg: none and a token signed with Eve's own key ^[5]. An attack outside that list is untested.

Dropping the server did not add latency in their setup. A Data API request took 41 to 44 ms at p50, against 40 ms for a plain TCP connect to the same address ^[11]. The request adds 1 to 4 ms over the connect ^[2]. Network distance accounts for most of the total, and it will differ on your network.