Most security content circles the same handful of headline issues. Weak passwords. SQL injection. Broken access control. They get covered often because they are common and easy to explain in a few sentences. Capture The Bug spent six months running continuous testing across 100 SaaS products in New Zealand and Australia, watching how these applications behaved over time rather than checking them once, and a different layer of weaknesses kept surfacing. None of them are exotic. All of them are underdiscussed, which is exactly why they keep slipping through.
Why these patterns stay hidden
A traditional pentest is a snapshot. A tester logs in, pokes at the obvious entry points, and writes up what was found within a fixed window. That format is excellent at catching the well known issues, the ones with a clear before and after. It is far less effective at catching weaknesses that only reveal themselves over time, across integrations, or under specific timing conditions that a single short engagement rarely stumbles into by chance.
Continuous testing changes that, because it keeps watching as the product changes, as integrations get added, and as features age past the point where anyone remembers they exist. That is how these five patterns kept turning up.
The 5 underdiscussed attack patterns
- Forgotten subdomains pointing at nothing: Marketing launches a campaign page on a subdomain, the campaign ends, and the subdomain quietly stays in DNS pointing at a third-party service that was never properly decommissioned. If that third-party resource gets deleted or reassigned, anyone can sometimes claim it and serve content from a subdomain that still looks like it belongs to the company. This showed up far more often than expected, almost always traced back to a marketing or staging environment nobody on the engineering team remembered existed.
- Webhook endpoints that trust whatever arrives: Many SaaS products receive webhooks from payment processors, integration partners, or internal services, and several of the tested applications accepted those incoming events without properly verifying where they actually came from. A crafted request mimicking a legitimate event, such as a payment confirmation, could trigger the same action a real one would, like unlocking a paid feature, without an actual payment ever happening.
- Multi-tenant data bleeding through shared infrastructure: In a few multi-tenant products, a shared cache or search index was not properly scoped to each customer's account. Under specific conditions, one customer's data surfaced briefly in another customer's results, not because anyone broke in, but because the underlying infrastructure treated all tenants as one shared pool when it should have kept them strictly separated.
- Privilege changes that leave a window open: When a user's role gets downgraded, most products update permissions immediately. A handful of the tested applications had a brief window where an already active session retained higher level access for a short period after the role change, because the permission check happened at login rather than continuously. A user demoted from admin to viewer could, for a short time, still act with the access they no longer should have had.
- Forgotten third-party integration tokens with broad permissions: Early in a product's life, a team connects to a third-party service, like a messaging or storage platform, and grants broad permissions to get a feature working quickly. The feature later gets replaced or quietly dropped, but the original access token often stays active, sitting in the background with far more reach than anything currently using it actually needs. Nobody is using it day to day, which is exactly why nobody notices when it becomes the easiest way in.
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
If any of these five sound like something that has never been specifically looked for in a past test, that is worth taking seriously. Book a demo with Capture The Bug and see how continuous testing surfaces patterns like these instead of only catching what a single snapshot happens to land on.
Why continuous testing catches what a single test misses
Every one of these five patterns shares something in common. None of them are visible from a single login and a quick look around. They require watching a product across time, across integrations, and across the small decisions that pile up as a team ships features and moves on to the next thing. A traditional pentest, scoped for a few weeks once a year, is simply not built to catch a permission window that only opens for a few minutes after a role change, or a token nobody has touched in eight months.
This is the practical argument for penetration testing for startups built around continuous coverage rather than a single annual check. The product keeps changing after the test ends, and these five patterns are proof that the gaps that matter most are not always the ones a checklist was written to catch.
What this means for budget and scope
This also changes how penetration testing cost in Australia and New Zealand should be thought about. A single point-in-time engagement, however well executed, can only see what exists on the day it runs. Continuous testing spreads that same investment across the year instead of concentrating it into one narrow window, which tends to catch far more of these slower-developing issues for a similar overall spend.
It is also why a focused api pentest service matters here specifically. Several of these five patterns, the webhook trust issue and the integration token sprawl especially, live entirely in how a product's APIs talk to outside systems. A penetration testing service that treats those connections as part of the core scope, rather than an afterthought, is far more likely to catch them before they sit unnoticed for months.
What this means for your roadmap
None of these five patterns require an unusually sloppy team to appear. They require time, the ordinary kind that passes as a product grows, features get replaced, and small decisions made early get forgotten later. A penetration testing service built to test continuously, rather than once a year, is built specifically to notice the things that only become visible after enough time has passed for them to quietly become a problem, which is exactly the gap a one-off engagement was never designed to close.
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
Why don't these five attack patterns get talked about more often?
They are subtler than headline vulnerabilities like weak passwords or SQL injection, and they usually only become visible over time rather than in a single test. That makes them harder to demonstrate quickly, so they get far less coverage even though they showed up repeatedly across this six month testing period.
Can a single annual pentest catch issues like forgotten subdomains or old integration tokens?
Sometimes, if the tester happens to look in the right place during that specific window. Continuous testing is more reliable for these because it keeps checking as the product changes, rather than relying on one snapshot to catch something that may not even exist yet on the day that snapshot is taken.
What is the most common of these five patterns?
Forgotten subdomains and webhook endpoints that trust incoming requests without verification came up most often across the 100 applications tested. Both tend to originate from features or campaigns that were active at one point and never properly decommissioned afterward.
How does continuous testing affect penetration testing cost compared to a single engagement?
Continuous testing spreads the same overall investment across the year rather than concentrating it into one short window. For most growing SaaS companies, that tends to catch more of these slower-developing issues without significantly increasing total spend compared to a single large annual engagement.
Does an API-focused test cover patterns like webhook trust issues and old integration tokens?
Yes, when the API scope explicitly includes how the product connects to outside systems. An API pentest service that covers webhook handling and third-party integrations as part of its scope is well positioned to catch both of these specific patterns, which is why naming integrations directly in a penetration testing service scope matters more than it might seem.
