
Why your INSERT INTO audit_log proves nothing
You've seen this pattern. You might have written it yourself. I know I did. CREATE TABLE audit_log ( id SERIAL PRIMARY KEY , user_id TEXT NOT NULL , action TEXT NOT NULL , resource TEXT , metadata JSONB , created_at TIMESTAMPTZ DEFAULT now () ); Every time something important happens — a user signs a contract, an admin changes permissions, a payment goes through — you INSERT INTO audit_log . Job done. You have an audit trail. Except you don't. The problem nobody talks about That audit_log table sits in the same database as everything else. Anyone with write access can do this: -- Oops. Never happened. UPDATE audit_log SET action = 'invoice.viewed' WHERE action = 'invoice.deleted' ; -- Or just make it disappear entirely DELETE FROM audit_log WHERE user_id = 'admin_42' AND action = 'permission.escalated' ; No trace. No alert. No way to know it ever happened. This isn't a theoretical attack. It's the default state of every audit log built on a regular database table. Your DBA can do it. A
Continue reading on Dev.to Webdev
Opens in a new tab

