The Exemption That Trusted the Wrong Input

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.

dxdev LESSON · paste into your AI coding agent
LESSON: An Exemption Keyed on What the Caller Says Is Not an Exemption, It's an Instruction
SOURCE: dxdev.com/blog/2026-07-28_the-exemption-that-trusted-the-wrong-input
WHAT HAPPENED: An internal admin surface required a logged-in session on every page, with one deliberate carve-out so the login form itself could render without an infinite redirect: if a particular request value said "this is the login page," skip the session check. That value was set from the query string, which any caller can set to anything on any request. Appending that same value to the URL of any other admin page also satisfied the carve-out, since the check never verified it was actually looking at the login page rather than being told it was one. It was found during an unrelated code review of a different set of admin tools, when nobody reviewing them could point to where the auth was actually enforced. Confirmed live on the real site with a single anonymous request that returned normal, authenticated-only data. Fixed within the same day: the carve-out was rewritten to check the file the server had actually resolved and served, not the value the request claimed, and re-verified against several ways of spoofing the original check.
THE RULE: any conditional in an access check that exists to skip the check under some condition needs that condition to be something the server determined, not something the caller supplied. A query parameter, a header, a hidden field: none of these prove what page is being requested or who is asking. Only server-resolved state (the actual file being served, an authenticated session, a value set before the request arrived) is safe to gate on.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any authentication or authorization check with an early-return or skip condition, and what value that condition reads.
  2. For each such skip condition: is it derived from caller-supplied input (query string, request body, header, cookie value the client can set) or from server-resolved state (matched route, session data set server-side, file path actually served)?
  3. Any exemption meant for exactly one page or one caller that is written as a general condition instead of an exact match against server-resolved identity.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.