How to Test Authentication and Authorization to Identify Non-Obvious Scenarios 

Authentication and authorization may seem trivial at first glance. The user logs in, gets access to what they are supposed to see, and everything looks like it works. Unfortunately, experience shows that these are the stages where the biggest mistakes are most often hidden. Simply checking the “ideal scenario” at these stages can easily lead to problems that risk going unnoticed.

I’ve made it a rule now not to treat authorization testing as just another item to be checked off at the end of the testing cycle. It’s a separate, important component of testing that requires the same attention as any other important feature. That’s when I began finding the kinds of issues that aren’t obvious at first glance.

First of all, it is worth clearly distinguishing between two different questions: “Is this really you?” (authentication) and “Do you have the right to do this?” (authorization). There have been cases when the team carefully checked the first question and expected that the second would “somehow solve itself.” But this is not the case. A person can pass authentication flawlessly, but this does not mean that they cannot access data or actions that have nothing to do with them.

I made a list of the top scenarios that I usually go through without fail.

Here are the situations from which I’ve learned the most—usually because that’s where I found the real problem:

– Effect of role change on session. Does the changed or revoked role immediately reflect in the active session, or do the old access rights remain in effect until the next login?

– Token expiration: What happens to an action if the token expires in the middle of a request, rather than just between requests?

– Horizontal expansion of access rights. If both users have the same roles, can user A view user B’s data by simply substituting his ID in a query?

– Vertical elevation of privilege: Can a user with limited privileges gain access to administrative endpoints by bypassing the interface that hides them?

– Logging out and closure of sessions. Does logging out on one device really revoke access on others, including active API tokens?

– Account recovery and password reset: Is it possible to use these methods to bypass standard login protections, such as multi-factor authentication?

– Using error messages. Does a failed login attempt reveal the existence of a valid account, given that there is a ready-made tool for brute-forcing accounts?

It is also worth noting that testing based solely on the user interface is not the best approach.

One habit significantly changed my approach: I started verifying authorization directly at the API level, rather than just clicking through the user interface. The UI sometimes hides options even though the backend accepts them just fine. If a specific role doesn’t have a button that’s a UI design choice, and it says nothing about whether the corresponding endpoint would actually reject the request. That’s why I now verify every restriction twice: once through the UI, and once by sending a request directly.

Also, one of the rules I always use now is to think and try to act like an attacker. All of these scenarios only become apparent when you stop checking “whether everything works as intended” and start thinking like someone who wants to get into a place they’re not supposed to be.

At first, this shift in thinking feels uncomfortable, especially if you’re used to confirming expected behavior. But that’s exactly what authorization testing requires. For every screen and every endpoint, I try to ask myself: What would happen if I weren’t the person this was designed for?

Authentication and authorization issues rarely occur during the demo phase. They surface later, quietly, and are often found by the wrong person and not at a convenient time. Consciously testing these flows, instead of simply assuming they “should work,” has become one of the most useful habits I’ve developed in QA.

Swan Software Solutions provides Quality Assurance and other technology services. To discover more about how our team could help your team, schedule a free assessment.