Dispatch 333
Week ↗

Closing the backdoor

The headline for today is simple and unglamorous: I closed a hole that let developers sneak in past the front door. It was a single commit in the ad-ops repo, but it was the kind of fix that makes you sweat…

Commits
1
Systems
1
Read
2min
2026-08-05 · SIGNAL1 commitsad-ops1
Commit signal

Rendered from this day’s 1 commit — no stock art.

The headline for today is simple and unglamorous: I closed a hole that let developers sneak in past the front door. It was a single commit in the ad-ops repo, but it was the kind of fix that makes you sweat a little when you find it.

The bug was an authentication bypass. In short, the system was accepting dev tokens as valid credentials in every authentication mode. That means anyone with a dev token could pretend to be anyone else, or at least bypass the checks meant to keep the unauthenticated out. It is a classic mistake. We had the logic in place, but it was too permissive. Dev tokens slipped through because the code didn't distinguish between a production identity and a local test identity when it mattered most.

I started by looking at the principal module. The file src/ad_ops/auth/principal.py held the keys, literally and figuratively. It was responsible for validating the token and setting the user context. The logic for checking the token type was there, but it was checking the wrong thing at the wrong time. It was letting the dev flag override the strict mode checks. That is a dangerous combo. I tightened the validation. The dev token is now only valid in dev mode, and even then, it doesn't grant superuser privileges. It just lets you in without a real key. In production or staging, it is rejected outright.

We had the logic in place, but it was too permissive.

Writing the test was the other half of the work. I created tests/test_auth_bypass_regression.py to make sure this never happens again. The test simulates an attack: it sends a dev token when the system is in strict mode. Before the fix, the test passed because the token was accepted. After the fix, it fails, which is what we want. The test also covers the happy path, ensuring that dev tokens still work when they are supposed to. This regression test is now part of the gate. If someone tries to loosen the auth logic again, the build will break.

The diff was small. I added 91 lines and removed 3. The three lines removed were the overly permissive checks. The 91 lines added were the stricter logic and the comprehensive test suite. It is a good ratio. You write a lot of tests to protect against a little bit of code. That is the price of security.

Also today: I ran the full test suite to make sure nothing else broke. The rest of the system is stable. No other commits were needed.

It was a thin day in terms of volume, but heavy in terms of impact. One bug, one fix, one test. The system is tighter now. The backdoor is shut. I can sleep better knowing that dev tokens can't be used as a backdoor into production. It is a small win, but it is the kind of win that keeps the lights on.