Hidden in plain sight: Hacking permissions through the URL
The "Aha!" moment
When we start testing, we prepare to find bugs, but that’s not all. We write test scripts, evaluate risks with stakeholders and run various review cycles until our test strategy is polished. I’ve been in the quality domain for over a decade. I’ve seen a bug or two, and over time, I’ve got my own way of discovering loopholes in the system under test.
In this post, I’d like to share some best practices that will help you plan your bug hunting better than before.
Every tester has this Aha moment when a bug is discovered in the most unpredictable way. I would like to share my discovery during the test execution of a real estate dashboard app. On that occasion, as an organized and tactical QA Lead, I had my script written, but I decided to do something a little different and divergent from the documentation and see what happened.
In my test, I had to check the user's portfolio. Where properties, names, values, and other details are visible to the user. The test design did not mention different users at the time.
The change I made is as follows. I went to the URL bar, appended the magic word ‘admin’ to the end, and pressed Enter.
I saw there a text saying "restricted” and “you have to return to the home page”. However, I did not stop there! In the same dashboard, there was a login button, and I clicked on it. Whush !! I’d discovered a horrible security loophole!
I was in the admin view and could delete all data from the user's dashboard if I wanted to. The incident made me think about what led me to do it, and I shared some best practices I use when planning and running test scripts.
The hidden flaw: Why the UI lies to you
Some bugs could lie within the requirements and design documents. Other issues you will find only by questioning and performing reviews with stakeholders. I have personally, more than once, wondered about something that is not mentioned in the documents but is strongly related to them. As in the bug story, the design said that there should be a user view that presents the details for each property held. The design writer did not specify exactly how the admin view restriction operates.
This creates a dangerous mismatch: the UI tells you one thing is restricted, but the backend doesn't actually enforce it, leaving the real flaw completely hidden.
When the requirements are not sufficiently detailed, the space for issues widens, and that is where the UI's design cannot save you. Requirement writers tend to create UI clear screens but neglect the user's exact detailed behaviour that is more backend and data integrity related.
Having said that, the User Interface part of our system hides some things we don’t initially think of, as we tend to imagine how the feature would look and rely on visual aids in the design. I was lucky enough to start my career on the non-UI side, so I got used to thinking about the backend before the UI. However, I feel that today’s Quality Assurance engineers rely too much on visual inspection, so they miss hidden flaws in the software's invisible parts.
Moving beyond the "Visual" trap
Once we finish designing the test plan and writing the test cases, we can look at the design documents. We have to remember that the requirements for the visual part include many things that are not mentioned. The hidden stuff the document author hasn't thought through. One example is the new feature's security. Verifying in the backend that the admin view and actions are disabled, not just restricted in the UI.
Another example is state management in the app. Once the user clicks on a button in the UI, the button should be disabled in the frontend view to prevent duplicate submissions. The next example is the error management in the user experience. If the user entered incorrect input, how would the UI handle it? Is the design document detailing the error description, or just plainly mentioning “in case of wrong email entered, display error to the user”.
Another part could be the backend for this new, shiny UI feature. Where does the data go after you click the new button on the screen? It’s not in the design, right?
My tip for you, the reader, is to think about the infrastructure, not just this visual building block. That can also be helpful while planning, and not only during execution phases.
Those are a few examples, but there is much to consider under the hood. We have logs that show the software working, and the DB (database) that completes this flow and stores the data sent from our visual feature. Do not neglect them!
Why curiosity still wins
Reaching the stage where we have a test scope encapsulated with data integrity and the feature's non-functional requirements, such as security, performance, scalability, and logging, is a meaningful milestone. Now we are ready to test the feature called test execution.
At this phase, we have already written test cases split into functional and non-functional tests in our preferred test management tool. Rolling up our sleeves to begin, we ask ourselves, how would it be best to approach it? The answer is simple.
Following only the instructions isn’t sufficient. The attitude must include a little curiosity.
Finding the best bugs and system malfunctions can happen when you are exploring. Sometimes it even occurs unintentionally. As in my example, when I just thought, what if I add a certain word to the URL?
How do you do that? You finish the steps for a test case for one feature, then add another step for a different feature. You might then find an issue that was not exactly related to the first feature, but was also not considered part of the second feature either. So it just falls between the two. Think of it as cross-feature interactions.
Conclusion 1: The "Extra Step" rule
Maybe you read this and told yourself that varying from the script is the most important part of testing? There is a reason we write those scripts and invest so many iterations in doing so. But think of that as a casserole. You can use the same ingredients, but the spices you added are what make it delicious. Adding the extra unplanned step is my spice. Sometimes it’s what connects two parts that are not necessarily related. I choose it intuitively. It won’t be the same in every script, but there are lots of ingredients to try. Feeling adventurous and thinking outside the box will help you decide which step to add while running your test plans. This is why approaching your testing with an exploratory mindset and adding that one extra step can make all the difference.
Conclusion 2: Shifting the focus to review and architecture
It’s true that being an experienced tester and following well-designed, structured test plans and designs would help you release with confidence. However, what I have learned over 14 years of my career and as a parent is that sometimes you have to wear different hats.I love to give the example of a child's behavior. Kids are born curious. They explore the world around them until we spoil it for them. By teaching them to behave and to follow the rules. Having the freedom to explore your system under test would help you find the exquisite bugs hiding in it. Don’t hesitate to deviate from your test plan from time to time, as it might yield interesting results that you did not expect and neither did your developer team colleagues.
While wearing the tester's hat, adding just one small thing can make it something entirely different, which is what makes the difference when finding bugs in the system.