Ask ten CTOs what the most common security flaw in their product is, and most will name something dramatic. SQL injection. A leaked secret. Some exotic zero-day that ends up in the news. The team at Capture The Bug went looking for the real answer, and it turned out to be far more ordinary than anyone expected.
Over the past year, Capture The Bug reviewed 2,500 confirmed vulnerabilities found across SaaS companies in New Zealand and Australia. These were not theoretical findings or noise. Each one was verified by a real tester, reproduced, and handed to a development team to fix. When the findings were sorted by type, one category sat at the top by a wide margin. It was not the vulnerability most engineering leaders prepare for.
What most CTOs expect to be number one
When founders and engineering leaders were asked to guess the top finding before the data was shared, the answers clustered around the usual suspects. Injection attacks. Cross-site scripting. An outdated library with a known weakness. These are the flaws covered in every security training, so they are the ones people picture first.
They do still appear. But across 2,500 confirmed findings from NZ and AU SaaS products, none of them topped the list. The most common issue was something most teams never test for properly, because on the surface it does not look like a bug at all.
The real number one: broken access control
Broken access control is when an application lets a user reach data or perform actions they should not be allowed to. The classic example is easy to picture. A customer opens their invoice at a web address ending in /invoice/1043. They change the number to /invoice/1042, press enter, and someone else's invoice loads. No password was cracked. No clever payload was sent. The application simply failed to check whether that user was allowed to see that record.
In Capture The Bug's dataset, broken access control was the single most common category of confirmed vulnerability across New Zealand and Australian SaaS products. It accounted for the largest share of findings, ahead of every other category. It showed up in customer dashboards, admin panels, and the quiet internal endpoints that power them. And it was found in funded companies with strong engineering teams, not just early-stage products.
Why broken access control hides so well
Here is what makes it dangerous. The code runs without errors. The page loads. Tests pass, because the tests check that the right user can do the right thing, not that the wrong user is blocked from doing it. The flaw only reveals itself when someone deliberately tries to reach data that belongs to another account.
That is also why so much standard tooling misses it. Off-the-shelf tools look for known bad patterns in code or traffic. Broken access control has no signature to match. Nothing is technically broken. A permission check is just quietly absent. Finding it takes a person who thinks like an attacker, opens two accounts, and tries to make one of them reach the other's data.
This is the gap that point-in-time testing leaves open. A pentest once a year captures a single moment. The next time a team ships a new feature, a new endpoint, or a new user role, fresh access control gaps can appear and sit undiscovered until the following year's test.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
Book a demo
Curious how many of these gaps exist in your own product right now? Book a demo and watch the Capture The Bug team probe your authorization logic the way a real attacker would, with findings you can act on while the context is still fresh.
What the NZ and AU data showed beneath the headline
Broken access control led, but it did not stand alone. A few related issues followed close behind, and together they tell a consistent story about where modern SaaS products break.
- Over-permissioned APIs. Endpoints that returned more data than the screen needed, or accepted actions they should have rejected, gave attackers room to pull records far beyond a single user's view.
- Weak authentication and session handling. Reused credentials, session tokens that stayed valid for too long, and password reset flows that could be abused let attackers step into accounts without ever breaking encryption.
- Security misconfiguration. Default settings left in place, verbose error messages, and exposed admin routes handed attackers a map of where to look next.
Every one of these shares a root with the number one finding. They are not exotic exploits. They are missing checks, loose defaults, and assumptions that nobody tested under pressure.
What this means for your roadmap
The lesson from 2,500 confirmed findings is uncomfortable but useful. The biggest risk to most SaaS products is not the attack nobody has seen before. It is the permission check nobody wrote, on a feature that shipped last sprint.
Closing that gap takes a different rhythm of testing. Authorization logic needs to be checked as features go live, not once a calendar year. Real testers need to open multiple accounts and try to cross the lines between them. New endpoints and new roles need a fresh look every time they appear, because each one is a chance for a gap to open. That continuous approach is the core of Capture The Bug's penetration testing service, where confirmed findings reach your team while the work is still in memory, not weeks later in a static document.
For founders raising a round or selling into regulated buyers, this also changes the conversation. Showing that authorization is tested continuously, with verified findings and tracked fixes, is far more convincing than a year-old certificate. It tells a buyer that security is treated as a living part of the product rather than a box ticked once.
The takeaway
Most CTOs are watching the front door for a dramatic break-in. The data from 2,500 confirmed bugs across New Zealand and Australia points somewhere quieter. The most common way SaaS products leak data is by forgetting to check who is allowed to see what. It is not glamorous. It is everywhere. And it is exactly the kind of flaw that continuous, human-led penetration testing is built to catch before an attacker does.
Security isn't a report. It's a live system. The companies that treat it that way are the ones that find the quiet gap first.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
FAQ
What is broken access control in simple terms?
It is when software lets someone reach data or perform actions they should not be allowed to. A common version is changing an ID in a web address and seeing another user's record load. The system failed to confirm that the person was permitted to view it.
Why is broken access control the most common SaaS vulnerability?
Because it does not look like a fault. The code runs, the page loads, and normal tests pass. The gap only appears when someone deliberately tries to reach another account's data, so it slips past teams that only test the expected path.
Can security tools find broken access control on their own?
Usually not. Most tools look for known bad patterns, and a missing permission check has no pattern to match. Finding it reliably takes a real tester who opens multiple accounts and tries to cross the boundaries between them. That hands-on approach is built into Capture The Bug's penetration testing service.
How often should a SaaS company test for it?
Whenever authorization-related code changes, which for most active products means continuously rather than once a year. Every new feature, endpoint, or user role is a fresh chance for a gap to appear.
Does this affect small startups too?
Yes. The 2,500 findings included funded startups with capable engineering teams. Broken access control is a design oversight, not a sign of a weak team, which is why it shows up in products of every size and stage.
