security on krtffl.dev

multi-tenant isolation is a security boundary, not a query filter

Mon, 06 Apr 2026 00:00:00 +0000

i’m building a small multi-tenant cms for local businesses — a barbershop, a physio, a bakery each get a little site they can edit themselves. one payload backend, one postgres, many tenants. the whole promise is that the bakery’s editor logs in and sees the bakery. not the barbershop. never the barbershop.

so during a pre-launch hardening pass i did the thing i’ve learned to do: i stopped admiring the isolation and started attacking it. i logged in as a low-privilege editor — scoped to exactly one tenant — and sent one request to edit my own user account. not someone else’s. mine. i just added a second tenant to the list of tenants i belong to.

it went through. 200. and on the next request i could read, edit and delete another business’s pages as if they were my own.

nobody broke in. i handed myself the keys through the front door, using an endpoint that exists specifically so users can edit themselves. an isolation boundary you can widen with a PATCH to your own profile isn’t a boundary. it’s a default you forgot to close.

your rate limiter trusts x-forwarded-for. mine did too, until it was measured.

Mon, 22 Dec 2025 00:00:00 +0000

last time i told you about the elo race that ate 79% of every vote — the anchor finding from a pre-launch hardening pass on a little pairwise-voting side project. i promised, at the bottom of that post, that the other critical finding was a vote rate-limiter that a rotated header walked straight through. this is that post.

here’s the setup. the side project is a nougat-ranking toy: you get shown two flavours, you pick one, an elo rating moves, a leaderboard falls out. because the leaderboard is the entire point, the interesting attack is obvious — cast a pile of votes for your favourite and bend the ranking. so i’d put a rate limiter in front of it. two, actually. i felt responsible.

then, during the audit, i sat down and attacked them instead of admiring them. both fell over. one to a header i let the open internet write. one to a cookie i simply didn’t send. neither took more than a few lines of curl.

a limiter you have never fired a spoofed header at is not a limiter. it’s a comment.

owner-scoped rbac: enforcing 'you can only see your own'

Mon, 23 Dec 2024 00:00:00 +0000

two users hit GET /dojos. same route, same handler, same line of sql underneath. the admin gets back every dojo in the database. the dojo owner gets back exactly one — theirs. nobody wrote a second endpoint, nobody passed a flag. the query just quietly narrowed itself on the way down, and the owner never learns the other rows exist.

the first time that worked in mojodojo i felt clever. “you can only see your own” is the whole ballgame in a multi-tenant app, and here it was falling out of the architecture for free. then i went looking for where it happened, and the answer was: two different files, in two different layers, that don’t fully agree with each other. one of them has a hole you could drive a truck through.