security

every post here is about a hole i shipped and then found, which is the only kind of security writing i am qualified to do.

what does this blog cover about security?

authorization, almost entirely — the boring kind that leaks data rather than the exciting kind that makes the news.

a rate limiter that trusted X-Forwarded-For, with two measured bypasses: a rotating forwarded header and a missing cookie, plus the trusted-proxy fix. a create endpoint that read OwnerID off the request body, and why a field you validate is still a field you trusted. owner-scoped rbac, and the authorization inconsistency that hides the moment you scatter the check across layers. multi-tenant isolation treated as a security boundary rather than a query filter, with the privilege-escalation hole that was sitting in the plugin defaults. and public endpoints that each allocate eight megabytes with no cap between them, which is a denial-of-service you host yourself.

the recurring lesson: authorization bugs are not usually missing checks. they are checks in the wrong layer, or checks that trusted an input one hop too early.

• multi-tenant isolation is a security boundary, not a query filter — a payload multi-tenant saas, the privilege-escalation hole hiding in the plugin defaults, and proving isolation with real integration tests
• your rate limiter trusts x-forwarded-for. mine did too, until it was measured. — two measured bypasses of an anti-abuse limiter — a rotating forwarded header and a missing cookie — and the trusted-proxy fix
• owner-scoped rbac: enforcing 'you can only see your own' — a two-tier global-vs-owned permission model in go, and the authorization inconsistency that hides when you scatter the check across layers

related

the isolation posts lean on postgres , and the argument for testing this class of bug specifically is under testing .