OAuth Token Encryption-at-Rest Automation: A Column Privilege That Was Silently Ignored

A well-written application screen requests exactly the data fields it displays and nothing more — it's good practice, and it genuinely limits what a normal user of that screen ever sees. What it doesn't do is limit what the database itself will hand over to anyone with a valid connection who asks for something different. A database privilege and an application's own restraint are two entirely separate mechanisms, and only one of them holds up against a request that doesn't come from the application's own well-behaved screen — a browser's developer console, a compromised script, or anyone who simply calls the same API the screen uses, but asks for a different column.

Restricting who can read a specific column looks, on its face, like exactly the right level of precision — narrower than restricting the whole table, and specific to the one piece of data that actually matters. The complication is that most database systems check column-level privileges only as a fallback: if a role already holds a privilege on the table as a whole, that broader grant is what actually governs access, and the column-level restriction sitting alongside it is never consulted at all. A team that revokes access to a single sensitive column, confirms the change was applied, and moves on can reasonably believe the fix is complete — when in fact nothing changed, because the table-level grant that was never touched is quietly still the rule in force.

The gap was found by directly probing the production database with a real, ordinary user's own session — not a hypothetical scenario. The result was unambiguous: a plain `SELECT` against the table storing platform connections returned four live, 350-character OAuth access tokens across the organization's real ad-platform integrations (Meta, Google, LinkedIn, Google Business Profile). The application's own service layer had always requested only the safe, non-sensitive columns — but that discipline lived entirely in application code, which any other caller with the same session privileges could simply ignore.

The first fix corrected the actual database privilege, and its own account of the process includes a specific, measured detail worth taking seriously: the team's first attempt was to revoke read access to just the token columns, leaving the broader table-level read grant in place — and measured directly, that column-level revoke had zero effect. The role still read all four tokens, because a table-level grant is checked first, and a column-level restriction is only consulted when no such broader grant exists. The working fix reverses the order: the table-level grant is revoked entirely, and read access is re-granted column by column, explicitly excluding the two token columns. Write access follows the same principle, narrowed to only the specific columns the application's screen genuinely needs to update — inserting and deleting a connection record now happens exclusively through a backend service role, never through a user's own session privileges, and disconnecting an integration (which needs to clear the token columns) was moved into a narrowly scoped database function specifically so a user's own session never needs write privilege over a secret column at all.

The second fix addresses a different threat the first one cannot: anyone who obtains a raw copy of the underlying data — a database backup, a replica, access through the database platform's own management interface — bypasses ordinary access-control privileges entirely, because those privileges only govern connections through the normal query interface. To close that gap, every stored token is now encrypted with AES-256-GCM before it's written, using a 32-byte key kept specifically outside the database itself, accessible only through a tightly scoped internal function restricted to the backend's own service identity — confirmed directly that neither an ordinary authenticated session nor an anonymous one can reach the function that resolves the encryption key. The stored format carries an explicit version marker specifically to support a gradual, reversible migration: a token stored under the old, unmarked format is recognized as legacy plain text and returned as-is, while every newly written or re-encrypted token carries the marker and the tooling needed to decrypt it. And critically, if the encryption key is ever unavailable for any reason, the encryption function fails loudly rather than silently falling back to writing the token in plain text — an absence of configuration is treated as a hard failure, specifically so the protection can never quietly turn itself off.

The fix's own end-to-end verification, performed directly against the production environment, is worth stating plainly: an ordinary user session attempting to select a token column now receives an explicit access-denied response; the application's own screen continues reading its real connections normally; the live backend service can still decrypt a real token and successfully call the ad platform's own API in a read-only capacity to confirm the credential still works; and every one of the organization's existing real tokens was confirmed migrated to the encrypted format, with zero left in plain text.

Someone with a valid, ordinary session opens their browser's developer console and issues a direct request for the token columns on their organization's own ad-platform connection — exactly the kind of request an XSS attempt or a curious extension might make. Before the fix, that request returned the real, usable access token. After the fix, the same request is refused outright by the database itself, regardless of what the requesting application intended to ask for.

A credential that spends real advertising money on a client's behalf is no longer reachable through an ordinary user session under any circumstance, and even someone with a raw copy of the underlying database cannot read it without also possessing a separate, narrowly held encryption key. The protection holds regardless of which specific application code path is used to reach the database — it is enforced by the database itself, not by any particular screen's discipline.

This fix specifically closes the read and raw-storage exposure of ad-platform OAuth tokens — it does not, by itself, rotate or invalidate credentials that may have been exposed before the fix was applied; that remains a separate, platform-side decision for whoever owns the connected ad accounts. It also does not change how the tokens are actually used to call Meta, Google, LinkedIn, or Google Business Profile's own APIs — only how they are stored and who can read them.

A column-level restriction applied without also removing a broader table-level grant looks, from the migration script alone, exactly like a real fix — and can pass a casual review while doing nothing at all. Centriu Maestro's fix was verified the only way that actually settles the question: by measuring the real, resulting access directly against the database, not by trusting that the privilege statement alone was sufficient.