---
title: "The Exemption That Trusted the Wrong Input"
canonical: https://dxdev.com/blog/2026-07-28_the-exemption-that-trusted-the-wrong-input/
datePublished: 2026-07-28
---
An internal review of a different set of admin tools turned up a question nobody could answer cleanly: where, exactly, does the login check happen on this surface? Not "it's probably fine, everything routes through the same shared include," but the actual line of code that says no session, no access. Filed as a read-only investigation, no code change expected. It found a real hole the same day.

## What the review was actually looking for

The admin tools in question didn't carry their own auth checks. Each one just included a shared setup file, on the assumption that the setup file's dependency chain enforced the login requirement somewhere downstream. That's a completely normal pattern. It's also one that's easy to state with confidence and never actually confirm, because "somewhere in the chain" is not a place you can point to.

The investigation went looking for the actual line. It found one: a function that redirected anyone without a valid staff session, called at include time from deep in that same dependency chain. So the gate existed. The question became whether it actually gated everything it was supposed to.

## The carve-out

That function had one deliberate exception, there so the login page itself could render without looping: if the request said it was the login page, skip the redirect. The check for "is this the login page" read a query-string value. Query strings are set by whoever sends the request. Nothing stopped any caller from appending that same value to the URL of any other admin page on the entire surface.

Confirmed directly against the live site: a single anonymous request to an unrelated admin tool, with that value appended, returned a normal 200 response and real data that should have required a staff login. Not a theoretical gap. An open door, on production, found by asking a question about a completely different set of tools.

## The fix

The carve-out was rewritten to check the actual file the server had resolved and was about to serve, rather than a value the request merely claimed. Only the real login page keeps its exemption; every other page, however it's addressed, hits the redirect. The new check was tested against several ways of trying to fake the old one: alternate casing, extra path segments, encoded characters. All of them now redirect. A logged-in session driving the same tools in a real browser still worked exactly as before.

Shipped the same evening, as its own hotfix, verified live: the previous bypass now redirects, the fix doesn't touch normal staff access, and no later report reopened it.

## The lesson underneath it

An exemption written into an access check is a decision about who gets to skip the check. That decision is only as good as the thing it's conditioned on. A value the server determined for itself, like which file it actually resolved and is about to serve, is proof. A value the caller typed into a query string is a claim, and a check that treats a claim as proof isn't enforcing anything, it's taking instructions from the same party it was supposed to be checking.