How to Test for Auth Precedence Flaws in Your API

Most auth bypasses aren't in the main login flow. They hide in fallback paths nobody remembers — endpoints that read a token from the header but will also accept it as a cookie or a query parameter. This share is the two-request test that finds that gap, plus the fix that closes it.

Every order of precedence is its own attack surface. One endpoint checks the header, another checks the cookie, and the same user ends up with two identities. That gap is the bug.

Tutorial

1. Send a single request carrying two different tokens. Put one in the Authorization header and one in a cookie.
2. Swap the two tokens and send the same request again. Keep everything else about the request identical.
3. Watch whether the app accepts either token. If it accepts either one, you found a precedence flaw.
4. Pick one auth source and reject everything else. The fix is boring, and that is the point.
5. Log the rejected fallbacks. Those rejections are the ones worth watching.
6. Delete the legacy paths that still authenticate, or version lock them out. Legacy paths are where attackers live.

Wrapping Up

You now have a test that costs two requests and a fix that costs one decision: one auth source, everything else rejected. Run it against the endpoints you have forgotten about, because the same user with two identities is the one that slips through. Then log what you reject and remove what you no longer need.