Kartikeya Rao — writing

Scoping every query to the tenant

Wed, 02 Sep 2026 00:00:00 GMT

Multi-tenant apps have one rule that matters more than the rest: a request from one organisation must never see another’s data. This bug broke that rule in the most common way there is. An invoice lookup trusted the ID in the URL and never checked who was asking.

What went wrong

The handler loaded an invoice by primary key. Authentication was in place, so every caller was a real, signed-in user. The query just never asked whether that user belonged to the organisation that owned the invoice.

src/routes/invoices.tsts

export async function getInvoice(req: Request, ctx: Context) {
  const id = ctx.params.id;
  const invoice = await db.invoice.findUnique({ where: { id } });
  if (!invoice) return notFound();
  return Response.json(invoice);
}

It passed review because it looks complete. There’s a not-found branch, the route sits behind the auth middleware, and the ORM call is idiomatic. What’s missing is a single field.

The fix

Scope the lookup to the caller’s organisation, and return the same 404 whether the invoice doesn’t exist or belongs to someone else. Different responses would let an outsider tell which IDs are real.

src/routes/invoices.tsts

export async function getInvoice(req: Request, ctx: Context) {
  const id = ctx.params.id;
  const invoice = await db.invoice.findUnique({ where: { id } });
  const invoice = await db.invoice.findFirst({ 
    where: { id, orgId: ctx.session.orgId }, 
  });
  if (!invoice) return notFound();
  return Response.json(invoice);
}

Try the copy button on that block. You get the code as it reads after the change, without the removed line.

Defence in depth

One scoped query fixes one route. Two more layers keep the next route from making the same mistake.

Row-level security in Postgres

Even if application code forgets the filter, the database refuses to return other tenants’ rows:

migrations/0042_invoice_rls.sqlsql

alter table invoice enable row level security;

create policy tenant_isolation on invoice
  using (org_id = current_setting('app.org_id')::uuid);

The app sets app.org_id at the start of every transaction, from the verified session and never from the request body.

A test that fails loudly

test/invoices.test.tsts

test('an invoice from another org is indistinguishable from a missing one', async () => {
  const a = await seedOrg();
  const b = await seedOrg();
  const invoice = await seedInvoice(b);

  const res = await asUser(a.owner).get(`/api/invoices/${invoice.id}`);
  expect(res.status).toBe(404);
});

Takeaways

Layer	Catches	Cost
Scoped query	This route	One field
Postgres RLS	Every query, including new ones	One policy per table
Tenant tests	Regressions before they ship	A few seeded fixtures

The client patched within six weeks and asked for a retest before disclosure. Thanks to their team for the quick turnaround.¹

Details that could identify the client have been changed. The shape of the bug and the fix are real. ↩

A token-bucket rate limiter in 60 lines of Rust

Fri, 14 Aug 2026 00:00:00 GMT

Sign-in endpoints without a rate limit are one of the most common findings in the reports I write. So here’s the limiter I reach for: small enough to read in one sitting, and correct under concurrency.

Why a token bucket

A fixed window (“100 requests per minute”) has a known weakness. A client can send 100 requests at 12:00:59 and another 100 at 12:01:00, which is 200 requests in two seconds. A token bucket smooths that out. Tokens refill continuously, and each request spends one.

The code

src/limiter.rsrust

use std::time::Instant;

pub struct Bucket {
    capacity: f64,
    tokens: f64,
    refill_per_sec: f64,
    last: Instant,
}

impl Bucket {
    pub fn new(capacity: u32, refill_per_sec: f64) -> Self {
        Self { capacity: capacity as f64, tokens: capacity as f64, refill_per_sec, last: Instant::now() }
    }

    pub fn try_take(&mut self) -> bool {
        let now = Instant::now();
        let elapsed = now.duration_since(self.last).as_secs_f64();
        self.tokens = (self.tokens + elapsed * self.refill_per_sec).min(self.capacity);
        self.last = now;
        if self.tokens >= 1.0 {
            self.tokens -= 1.0;
            true
        } else {
            false
        }
    }
}

The highlighted lines are the whole algorithm. Everything else is bookkeeping.

For many keys (one bucket per IP or per account), wrap it in a sharded map so threads don’t fight over a single lock:

src/keyed.rsrust

use dashmap::DashMap;
use std::net::IpAddr;

pub struct Limiter {
    buckets: DashMap<IpAddr, Bucket>,
    capacity: u32,
    refill: f64,
}

impl Limiter {
    pub fn check(&self, ip: IpAddr) -> bool {
        self.buckets
            .entry(ip)
            .or_insert_with(|| Bucket::new(self.capacity, self.refill))
            .try_take()
    }
}

The Go version, for comparison

limiter.gogo

func (b *Bucket) TryTake() bool {
	b.mu.Lock()
	defer b.mu.Unlock()

	now := time.Now()
	b.tokens = min(b.capacity, b.tokens+now.Sub(b.last).Seconds()*b.refill)
	b.last = now
	if b.tokens < 1 {
		return false
	}
	b.tokens--
	return true
}

Same algorithm, different ergonomics. Go makes the lock explicit. Rust’s &mut self forces you to decide who owns the bucket before it compiles.

Configuration

config/limits.yamlyaml

limits:
  sign_in:
    capacity: 5 # burst
    refill_per_sec: 0.1 # one attempt every 10s after that
  password_reset:
    capacity: 3
    refill_per_sec: 0.0167

Numbers

Measured on a laptop, single process, 8 threads hammering 10,000 distinct keys:

Implementation	Checks / sec	p99 latency
Rust, `DashMap`	41.2 M	180 ns
Rust, one `Mutex`	6.8 M	2.1 µs
Go, `sync.Map`	19.5 M	410 ns

Five minutes with your response headers

Fri, 03 Jul 2026 00:00:00 GMT

Most sites I look at are missing at least two of these. The check takes five minutes, and the fix is usually a few lines of server config.

Check what you send

Run this against your own site. Commands have a $ prompt, and the rest is output.

terminal

$ curl -sI https://example.com
HTTP/2 200
content-type: text/html; charset=utf-8
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
$ curl -sI https://example.com | grep -i content-security-policy

The copy button on that block copies just the two commands, without prompts or output. Paste them straight into your terminal.

Quick quiz: which important header is missing from the output above? Answer: Content-Security-Policy. The second command printed nothing.

The headers that matter

Strict-Transport-Security makes browsers use HTTPS only, even when someone types http://.
Content-Security-Policy restricts where scripts, styles and frames can load from. It’s the strongest defence against XSS you can deploy without code changes.
X-Content-Type-Options: nosniff stops browsers from guessing file types.
Referrer-Policy keeps full URLs, including tokens in query strings, from leaking to other sites.
Permissions-Policy turns off browser features you don’t use, such as camera, microphone and geolocation.

A starting config

/etc/nginx/snippets/security-headers.confnginx

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'none'; frame-ancestors 'none'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Reload and check again:

terminal

$ sudo nginx -t && sudo systemctl reload nginx
nginx: configuration file /etc/nginx/nginx.conf test is successful

Press Ctrl + Shift + I in your browser, open the Network tab, and click the document request to see the same headers without a terminal.¹

On macOS it’s ⌘ + ⌥ + I. ↩

What a year of writing security reports taught me

Wed, 10 Dec 2025 00:00:00 GMT

A finding that nobody fixes is only a note. Over the past year I’ve written a lot of reports, and whether a bug gets fixed depends less on its severity than on how clearly it’s explained.

Write for the person fixing it

The reader is usually a developer who didn’t write the vulnerable code and has a sprint full of other work. They need three things, in this order: what’s wrong, why it matters to this business, and exactly what to change.

One finding, one fix

When a finding says “improve input validation”, it stays open forever. When it names the file, the function and the change, it’s closed by Friday.

Severity is a conversation

CVSS gives you a number. The client knows their business better than you do, so ask before you rate. A medium-severity bug in their payments flow can matter more than a high in an internal tool.

Retest everything

A fix that hasn’t been retested is a guess. Every engagement I run now ends with a retest, and about one in five fixes needs a second attempt.

Kartikeya Rao — writing

Scoping every query to the tenant

What went wrong#

The fix#

Defence in depth#

Row-level security in Postgres#

A test that fails loudly#

Takeaways#

Footnotes#

A token-bucket rate limiter in 60 lines of Rust

Why a token bucket#

The code#

The Go version, for comparison#

Configuration#

Numbers#

Five minutes with your response headers

Check what you send#

The headers that matter#

A starting config#

Footnotes#

What a year of writing security reports taught me

Write for the person fixing it#

One finding, one fix#

Severity is a conversation#

Retest everything#

What went wrong

The fix

Defence in depth

Row-level security in Postgres

A test that fails loudly

Takeaways

Footnotes

Why a token bucket

The code

The Go version, for comparison

Configuration

Numbers

Check what you send

The headers that matter

A starting config

Footnotes

Write for the person fixing it

One finding, one fix

Severity is a conversation

Retest everything