Cashback Eligibility Table Authorization Automation: Nothing Wrote Here, and Everyone Could

Reviewing an application's own source code for a security gap works by construction only for gaps that the code itself actually exercises — a code review can catch a function that writes to the wrong place, or checks the wrong permission, because there is a specific line of code to examine. A table that legitimately has NO application code writing to it at all sits entirely outside that method: there is no function, no call site, no code path for a review to inspect, because none exists. The only way to find a live, exploitable gap in a table like that is to ask the actual, current database directly what it currently permits — not to read the application's own source and reason about what it does.

A database platform's own automatic default privileges are granted the moment a table is CREATED, entirely independent of whether any application code ever goes on to actually use that table for writing. A team's own attention, quite reasonably, tends to follow where the code actually exercises a path — a table with an active write function attached to it gets scrutinized because something is clearly happening there; a table nothing writes to yet can easily be assumed harmless specifically BECAUSE nothing appears to be happening, when in fact the database's own default access has been sitting open the entire time, waiting for anyone who reaches it directly rather than through the application's own interface.

A small Centriu Loop table holds a single meaningful field per customer: whether that customer is currently eligible to use their own cashback balance. An earlier, same-week authorization pass had deliberately left this specific table out of scope, judging it at the time to be a minor opt-out flag rather than a genuine financial control — a call the fix's own account is explicit was a mistake, because the redemption flow silently excludes any customer marked ineligible here from the eligible-customer list it checks, meaning one wrong row directly blocks a real customer from using cashback they genuinely hold.

Before closing the gap, a full, systematic review confirmed something specific and unusual about this exact table: literally zero lines of code anywhere in the application — no interface, no backend function, no database trigger — ever write to it. The only legitimate interaction with the table at all is a separate, trusted internal process reading from it, through its own privileged connection, specifically to decide which customers to include when counting active cashback participation.

Measured directly against a real database using the live production schema, testing systematically across every role the system recognizes rather than assuming any role beyond the obvious cross-tenant case was safe: an authenticated member of the correct organization, holding a role the application's own permission model explicitly marks as having NO write access anywhere in Loop, could still insert a new row and update an existing one in this table directly — because the table had simply never been individually reviewed, and still carried the same broad default insert-and-update privileges every new table receives automatically.

The fix revokes insert, update, and delete privileges from every role that should never have held them, and removes the two database policies — one for insert, one for update — that had granted write access to any ACTIVE member of the correct organization, with no further role distinction. Read access is left fully in place, since the trusted internal counting process, and any legitimate future feature that might read this same value, still need it. A companion mutation-tested check now specifically verifies BOTH that the migration's own safety guard correctly refuses to apply twice, AND that removing that same guard causes the underlying database privilege check itself to fail — confirming the protection comes from the actual database state, not merely from the migration script's own internal bookkeeping.

One genuinely useful negative result came out of the same investigation: a test that specifically omitted revoking DELETE privilege (checking whether that omission would be silently missed) produced NO behavior change at all, because no DELETE policy had ever existed on this table in the first place — row-level security was already correctly blocking deletion before this fix touched anything. The fix's own account draws out the general lesson directly: measuring observed BEHAVIOR is not a substitute for measuring the underlying PRIVILEGE directly, since a privilege that happens to have no matching policy will look identical, from a behavioral test alone, to a privilege that was genuinely revoked.

Before the fix, no legitimate path in the entire application ever led to writing this specific table — the door had no doorway built to it at all. But the door itself, reached directly rather than through any interface, was still unlocked: a role with no declared write access anywhere in Loop could open it and change what was inside. After the fix, the door is locked for that role regardless of whether any doorway to it exists — closing the gap even though nothing in the application's own code ever walks through it.

A role Centriu Loop's own permission model explicitly declares has no write access anywhere in the product can no longer write to a specific table controlling cashback eligibility, closing a gap that existed purely at the database's own default-privilege layer — a gap invisible to any review of application code, since zero lines of code anywhere ever wrote to this table in the first place.

This automation covers specifically the write-authorization of one small Centriu Loop table controlling cashback eligibility. It is a distinct mechanism from this pillar's separate pages on Loop's cashback ledger and campaign-configuration authorization — related in theme (a database-level access gap underneath an application-level rule) but each addressing a genuinely different, specific table.

Reviewing an application's own source code for authorization gaps is efficient and catches a great deal — for exactly the tables and functions the code actually touches. It structurally cannot catch a gap in a table nothing in the codebase writes to at all, because there is no code path for a review to examine. Directly querying the database's own current privileges and policies, table by table, independent of whether any application code currently exercises them, is the only version of the two that can find this specific, otherwise invisible class of gap.