Member Write-Surface Verified Reduction Automation: Measure Before You Claim the Number

Closing a security gap and then explicitly naming what is left, rather than declaring total victory, is the more honest and more useful way to hand off unfinished work — a residual noted with its actual scope stated plainly is something a future investigation can act on directly. The risk specific to that honesty is what happens next: a large residual count ("827 objects still carry this privilege") can be treated as if the count itself were the measure of danger, when the number that actually matters — how many of those objects are genuinely reachable by someone with no more than public credentials — has not yet been established at all. Closing all 827 objects identically, without first measuring which of them a real caller could actually exploit, would have been simpler to write and slower to verify than measuring first.

An earlier security migration on Centriu Vértice's database had closed direct write access, for the anonymous and authenticated database roles, on 52 objects belonging to one specific data family (member connections, business records, and opportunities) — and left behind an honest, explicit note: 827 OTHER `vertice_*` database objects still carried the exact same underlying privilege, a default the platform itself grants to every new table unless something specifically revokes it, with no measurement yet of how many of those 827 were actually reachable by a real, unauthorized caller.

Rather than close all 827 on the strength of that count alone, the follow-up work measured the real surface first, directly against the live production catalog. 414 of the 827 objects had row-level security enabled with zero policies defined on them at all — meaning any write attempt is refused before any policy logic even runs, because there is nothing to evaluate; the underlying grant is present but functionally dead. A further 208 had a policy that permits only reading, never writing — the same dead-on-arrival outcome for any write. That leaves 203 objects where a policy genuinely permits a write to succeed: 137 of those require an administrative, moderator, or specific staff role no ordinary member holds, and the remaining 66 are governed by some variant of "this specific row belongs to you" — a real, member-reachable write surface, but one that collapses, once the actual policy expressions are compared, into just 11 distinct patterns rather than 66 separate risks to reason about individually.

A second, independent measurement closed the loop: a full inventory of every file anywhere in the module that reads a member's own authenticated session token found 34 such files, of which exactly 3 perform any write at all, and one of those 3 performs no data write whatsoever (only a sign-in call). The other 2 write to precisely the 2 tables an earlier migration had already identified and deliberately preserved as legitimate member self-service writes. In the entire module, across every consumer of a member's own credential, there were exactly 2 real write call sites — a number small enough to reason about individually, arrived at only by combining the database-side policy audit with this separate, code-side inventory; either measurement alone would have missed real information the other one supplied.

Before writing any conclusion down, a mandatory adversarial test phase attempted each specific write a member's own credential might reach, directly against a real database, rather than reasoning about what SHOULD be possible from reading policy text alone. That step caught two specific findings this same investigation would otherwise have wrongly published as newly-discovered-and-fixed vulnerabilities: the most severe-looking one, a member's own status field appearing writable in a way that a suspended, expelled, or delinquent member could rewrite back to active status themselves (a status a separate function reads to authorize dozens of other actions across the product) — attempted directly against the real database, the write was rejected outright, blocked by an existing database trigger nobody had accounted for when reading the access rules alone. Without that mandatory live-attempt step, this fix would have claimed credit for closing a door that a completely different, pre-existing mechanism had already closed.

What survived the adversarial phase were 7 real, independently reproduced exposures: one member rewriting a bilateral fact the other party had recorded, a member pricing their own listed offer at a token amount, a revoked device reinstating its own trusted status, a consent record rewritten after the fact, a revoked session un-revoking itself, a member self-reporting their own onboarding as complete, and a forgeable terms-acceptance record with an arbitrary date and version. All 7 were closed the same way as the earlier 52: revoking the specific write privileges from every `vertice_*` object in the schema except the 2 objects confirmed, by the same investigation, to need them. The fix's own text is explicit about why a blanket revoke, rather than 64 individually hand-written and reviewed policy corrections, was the right shape: writing correct state-transition and column-immutability logic inside declarative policy expressions is fragile to write and harder to verify, and the underlying privilege was never a deliberate product decision in the first place — it came from the platform's own default access-control list, which grants broad privilege to every new table unless something specifically revokes it.

The revoke operation itself needed one more piece of production-specific care: removing a privilege from a database object requires an exclusive lock on that object for the duration of the operation, and the fix touches roughly 878 objects inside a single transaction — meaning every one of those locks is held simultaneously until the whole operation commits. The fix's own account names the exact failure mode a safeguard exists to prevent: if even one ordinary, unrelated query anywhere in the system is holding even a routine read lock on any one of those 878 objects at the moment the migration runs, the migration would wait for it — and every other request touching any of those objects would, in turn, queue up behind the migration itself, turning an intended, contained database change into a site-wide outage with no obvious link back to a single GRANT statement. A short, explicit wait limit specific to this operation means the migration fails fast and visibly instead, if that contention ever occurs, rather than silently waiting indefinitely while unrelated traffic backs up behind it.

The migration closes with its own proof, run automatically as part of applying it: a check confirming nothing in the schema still permits a direct write except the 2 named exceptions; a check confirming ordinary read access is untouched (so the row-level security layer still has something to actually govern); a check confirming the 2 legitimate member writes still function; and a check confirming the internal, elevated service credential the product itself relies on for real writes still has the access it needs. "The SQL executed without an error" was deliberately never treated as sufficient evidence that the fix did what it was meant to.

Before this investigation, a static reading of Centriu Vértice's own access-control policies suggested a suspended, expelled, or delinquent member could rewrite their own profile's status field back to active — a function 35 separate policies elsewhere in the product rely on to decide what that member is currently allowed to do. Attempting that exact write against a real, live-configured database, as the mandatory adversarial test phase requires before any conclusion is accepted, found the write rejected outright by an existing database trigger — a real protection nobody had accounted for when reading the policy rules in isolation. Elsewhere in the same investigation, 7 different writes attempted the identical way DID succeed against the same real database, including a member setting their own listed price to a token amount and a revoked device reinstating its own trusted status — genuine exposures, closed by the same fix. The distinction between the false alarm and the real exposure was never visible from reading rules on paper; only an actual, live attempt against a real database told the two apart.

Centriu Vértice's direct database write surface for unauthenticated and ordinary-authenticated credentials is reduced from 827 objects carrying the platform's own default write grant to exactly 2 confirmed-legitimate exceptions, following a measurement that combined a policy-reachability audit, a whole-module code inventory, and a mandatory live adversarial test phase — the last of which caught and discarded two findings that would otherwise have been wrongly published as newly-fixed vulnerabilities.

This automation governs the internal database privilege-verification methodology behind Centriu Vértice's own access-control hardening — it does not change what a member can do through the product's own actual interface (the 2 preserved write paths cover every legitimate member self-service action this investigation found), and is specific to a platform whose default access-control list grants broad table privilege unless a project explicitly revokes it; a system with a more restrictive default would not accumulate this specific class of residual in the first place.

Closing all 827 objects identically, purely on the strength of an earlier honest disclosure naming that count, would have been the faster-sounding response and would have arrived at the same final database state — but without ever measuring which specific findings among them were real, it would also have risked publishing at least one false claim (the status-reinstatement path a static policy reading suggested was open) as a newly-discovered-and-fixed vulnerability, when a real trigger had already closed it. Measuring the actual reachable surface first, combining a database-side audit with a code-side inventory and a mandatory live adversarial test, takes longer to write up but produces a fix whose every claimed finding was independently, reproducibly verified against a real database before being reported as true.