The Auth Gate Had Exactly One Correct Position, and I Guessed

An unrelated code review turned up a hole that had nothing to do with what I was actually looking at. One query parameter, appended to any page inside an internal admin tool, skipped the staff login check entirely. I confirmed it the ugly way: an anonymous request to a page that should have required a staff session came back with a normal response and live database rows in it.

The mechanism was almost boring once I found it. The staff-auth check ran once, near the top of every admin request, and it had a deliberate early exit for the login page itself, because the login page obviously can’t require you to already be logged in. That exit was keyed off a request parameter rather than the actual page being served. Add the same parameter to any other admin URL and the check waved you through without ever looking at your session.

I fixed it the way you’d expect: stop trusting the parameter, and anchor the exemption to the page the web server actually resolved and served, which a request can’t spoof. Only the real login page kept the exemption. I tested the fix against an unpatched copy side by side. The old bypass URL returned a normal page with data on the unpatched copy and a redirect to login on the patched one. Same request, same account, different code. I shipped it as a hotfix and watched it hold in production.

It held for thirteen hours.

Then staff logins started failing, for everyone, on every environment running the patch. The people who’d never logged out that day didn’t notice, because an existing session still worked fine. Anyone trying to log in fresh got bounced with a generic session-expired error before they ever got a chance to enter a password.

I’d fixed the exemption on the login page, the one that renders the form. I hadn’t noticed that submitting the form is a separate request, a POST to a different internal endpoint, and that endpoint ran through the exact same staff-auth check I’d just tightened. The new guard treated the login submission itself as just another admin request that needed a session it couldn’t have yet, and turned it away before a single credential was checked.

I reproduced it the same way I’d reproduced the original bug: a bare unauthenticated POST straight to the login-processing endpoint, wrong credentials on purpose. Before my fix, that request would have reached the actual authentication check and come back with an invalid-password error. After my fix, it came back with a session-expired redirect instead, meaning the credentials were never even looked at. The guard I’d built to close one door had put a lock on the door people were supposed to walk through.

The fix for the fix was the same principle applied more completely: extend the exemption to the login-processing endpoint too, still anchored to the actual served path rather than to anything a request could set. I verified three things this time instead of one. Wrong credentials against the login endpoint now correctly reached the authentication check and came back invalid, not session-expired. A real login with correct credentials worked end to end. And the original bypass, tested again on the same URL that had leaked data thirteen hours earlier, was still closed. I didn’t want to trade one hole for a different one.

The bypass diagnosis was right. The mechanism was right. Closing it on the resolved path instead of a spoofable parameter was the correct instinct. The mistake was assuming there was one place in the request flow that needed the exemption, when there were two: the page that shows you the door, and the request that actually walks you through it. I tested the first one carefully and never asked whether the second one existed.

I now keep a specific question on hand for any change to an authentication gate: what are every one of the requests a legitimate, logged-out user has to make before they have a session, and does the fix account for all of them, not just the one you were staring at when you wrote it.

dxdev LESSON · paste into your AI coding agent
LESSON: An auth exemption for the door a user is shown is not the same exemption needed for the door they actually walk through
SOURCE: dxdev.com/blog/2026-07-29_auth-gate-guessed-wrong-position
WHAT HAPPENED: An admin tool's staff-login check had a bypass keyed off a request parameter rather than the page actually being served, so appending that parameter to any admin URL skipped authentication entirely. The fix anchored the exemption to the real resolved page instead of the spoofable parameter, verified against an unpatched copy, and shipped as a hotfix. It held for thirteen hours, then every staff login started failing, because the fix had only exempted the login page that renders the form, a GET request, and not the separate login-processing endpoint, a POST request, which ran through the same newly tightened check and rejected the submission before a single credential was examined, returning a generic session-expired error that masked the real cause. The real fix extended the same resolved-path exemption to both endpoints, then verified three things: wrong credentials against the login endpoint now correctly reach the authentication check and fail properly, correct credentials succeed end to end, and the original bypass, retested on the same URL that had leaked data thirteen hours earlier, stayed closed.
THE RULE: Fixing an authentication gate requires enumerating every single request a legitimate, logged-out user must make before they have a session, not just the one in front of you, because each request may independently need the same exemption, and missing any of them either reopens the hole or locks everyone out.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any auth exemption or bypass keyed off a request parameter, header, or other client-controllable value rather than the actual resolved server-side route.
      2. Any fix to a login or auth flow verified against only one request in the pre-authentication sequence, such as the page render, without separately testing every other request a logged-out user must make, like form submission or token refresh.
      3. A generic error message, such as session expired, on an unauthenticated request that could be masking a completely different failure, such as the credential check never running at all.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.