Go ahead, change that number in the URL of that service that you use

Last month, I learned that it’s apparently not common behavior in computer users to start fiddling with the URL of a link that they receive, just to see what happens. “It wouldn’t even come to my mind to do that!” was one reaction.
And that’s how I ended up discovering a vulnerability on a service that I personally used.
Unlike most security vulnerabilities that get reported nowadays, it didn’t take me a fleet of token-thirsty LLM-based agents to get the job done. I just noticed that the e-mail with my order had a number in it, it served as a share code, and then I began iterating it a few times to see what happens. Plain old human curiosity. Then a few numbers later I stumbled upon someone else’s account.
I let the company know about the issue politely and with detail and potential mitigations, and after a week of back-and-forth, they actually implemented the fixes that ensure that both old orders and any future ones are now appropriately handled, minimizing the risk of a data leak and potential malicious actions on behalf of other customers.
Before you take the title of this post literally, there are a few basics to follow to get it right:
- be curious but not actively malicious
- once you have validated a hunch, STOP and report the issue, you don’t need to pull the whole customer database to prove a point
- try to prove the vulnerability with two test accounts that you control to avoid exposing someone else’s actual private information, intentionally or accidentally
- if you can’t find any contact details or get ignored, loop in your local regulator who deals with cybersecurity
matters, such as CERT-EE in Estonia
- they do good work and alerted me of a now-shutdown public Kiwix instance that had a security flaw back in 2023!
Depending on your jurisdiction, there may also be other things to pay attention to. This is not legal advice.
You don’t need to hack the world, but if you notice an obvious issue in passing, then it’s worth putting in that little bit of effort to make the security world a better place, especially if it’s a service that you use, since your personal data is also stored on there.
This type of vulnerability is unfortunately super common and almost every software system that I’ve helped build and maintain has exhibited this in one way or another. I suspect with the onslaught of low-quality LLM-written code, it may be even more common because LLM-s can very easily introduce these issues unless you take steps to weed this behavior out or introduce explicit rules that try to mitigate common vulnerabilities in new code.
Happy responsible hacking!
Subscribe to new posts via the RSS feed.
Not sure what RSS is, or how to get started? Check this guide!
You can reach me via e-mail or LinkedIn.
If you liked this post, consider sharing it!
