CommunityOS

Authorization lives in Postgres row-level security, and the app's own permission checks exist only to hide buttons. If a page forgot a check tomorrow, the query would still return nothing. Every tenant read is gated on the caller's own membership, so guessing an id gets you an empty result rather than someone else's data.

A helper answering “what is this person's role here?” returned nothing at all for a non-member — and in Postgres, a permission check written as “if not allowed, refuse” treats nothing as false and lets the request through. Eighteen functions were affected. I found it by auditing all 161 functions from three independent angles, confirmed it live — a stranger could promote themselves to owner of a community they had never joined — and closed it by making every check total. The full write-up is in the project's decision log, because the interesting part is not the fix.

The suite had been reporting “32 attacks blocked, 0 breaches” the whole time the hole above was open, because every role it impersonated held a membership somewhere — and the bug only opened for someone holding none. I added that missing role. It now runs 59 attacks and the pass condition is the breach count, never a total, precisely because a hard-coded total is part of how the first one survived.

To stop that pattern ever returning, a custom linter parses every migration, resolves each database function to its final definition and fails the build if a permission check is written in the shape that fails open. It runs in CI on every push. Writing a bespoke linter for a single bug class is unusual; it is proportionate when the bug is silent privilege escalation.

Payment fulfilment is idempotent and keyed on the gateway's order reference, so the webhook and the thank-you page can both fire, and a retried webhook can fire a third time, and the member is still granted access exactly once and the ledger written exactly once. Prices are always recomputed on the server — the browser is never asked what something costs. Refunds reverse the affiliate commission in the same transaction.

Post bodies are a column members can write to, so a hostile client can push raw HTML straight past any server-side cleaning on the way in. The real defence is re-sanitising at every path that reads a body out. Getting this backwards is the most common way a community platform ends up with stored cross-site scripting.

Each feature goes through a review pass whose job is to break it — findings are then independently verified, and the ones that survive get fixed before launch. It has caught a live production bug that had silently stopped paid course buyers being enrolled, a WhatsApp attribution leak that would have credited the wrong community's ad, and a refund path that reversed an affiliate's entire commission over a partial refund.