The findings from real penetration tests are more mundane and more dangerous than the movies suggest. There is no dramatic zero-day exploit, no sophisticated nation-state technique. There is a broken object-level authorisation check that lets any authenticated user read any other user's data. There is an admin panel accessible without MFA because someone marked the route as an exception six months ago. There is a JWT secret that is the company name with an exclamation mark.
I have been involved in commissioning, scoping, and reviewing penetration tests across Series-A through Series-C SaaS companies — mostly in B2B, mostly handling sensitive customer data, mostly in regulated or near-regulated verticals. What I want to share here is not a theoretical framework. It is a composite of what these tests actually find, anonymised across engagements, with the business context that makes the findings meaningful to a board or CEO.
What "Series-B SaaS" Typically Looks Like at Test Time
The companies I'm describing are post-product-market-fit, usually 40–150 employees, with engineering teams of 10–40 people. They have a VP Engineering or CTO who was promoted from senior engineering, or hired recently. They've shipped fast. They have some security tooling — a WAF, dependency scanning in CI, maybe a bug bounty programme in its first year. They think of themselves as security-conscious because they've thought about security.
None of that is the same as having a hardened application.
The thing that makes Series-B SaaS interesting as a security target is the combination of real customer data — often enterprise customers whose own compliance requirements triggered the pen test — and application code that was written at speed, without adversarial thinking, by engineers whose job was to ship features.
Finding Category 1: Broken Access Controls
This is the most common critical or high finding across every engagement I've been involved in, and it consistently surprises engineering leadership.
Broken access control means the application does not properly enforce who can do what to whose data. The canonical form at Series-B SaaS companies is Broken Object Level Authorisation (BOLA, formerly known as IDOR — Insecure Direct Object Reference). A user authenticates successfully, obtains their own resources via the API, and then substitutes another user's identifier in the request. The server checks that the user is logged in. It does not check that the user owns the object they're requesting.
In one engagement I reviewed, an authenticated low-privilege user could retrieve any other organisation's billing history, project data, and user roster by incrementing integer IDs in API calls. The data included enterprise customer contract values and user PII. The API had been live for 18 months. The vulnerability was introduced in the first version.
The reason this happens is not engineering incompetence — it is architectural pattern. When teams build APIs quickly, they write authentication middleware once and call it done. Object-level authorisation — checking not just "is this person logged in" but "does this person own this specific resource" — requires explicit implementation on every endpoint. If it's not part of the code review checklist, it gets missed.
BOLA is the most under-appreciated critical vulnerability class
OWASP has ranked Broken Object Level Authorisation as the number one API security risk for multiple years running. It is consistently found in Series-B SaaS because the fix requires disciplined endpoint-by-endpoint implementation, not a single configuration change. A WAF will not catch it. Dependency scanning will not catch it. Only manual testing or a code review specifically looking for it will find it.
Finding Category 2: Authentication and Session Weaknesses
Authentication weaknesses at this stage are rarely "no authentication." They are subtler failures that accumulate over time.
The most common findings I've seen in this category:
Weak JWT implementation. JSON Web Tokens are widely used for API authentication. The critical security property is the signing secret — if it's weak or predictable, an attacker can forge tokens and impersonate any user. In one engagement, the JWT secret was a company name variant. In another, the none algorithm was accepted, meaning unsigned tokens were valid. Both are textbook errors with textbook fixes.
MFA that doesn't actually protect everything. A company implements MFA on the main login flow and marks the security checkbox. The pen test finds that the password reset flow, the magic-link flow, and the admin impersonation endpoint all bypass MFA. MFA is only as strong as the weakest path to authentication.
Sessions that don't expire. Refresh tokens with no expiry, sessions that persist indefinitely after logout, JWT tokens with 7-day expiry and no revocation mechanism. An attacker who captures a session token has access until it's rotated — and if it never rotates, that's permanent access.
| Finding | Severity | Root Cause | Remediation Effort |
|---|---|---|---|
| JWT signed with weak secret | Critical | Secret set in dev, never rotated | Low — rotate and enforce entropy requirements |
| BOLA on core data endpoints | Critical | No object-level auth pattern | High — requires endpoint-by-endpoint review |
| MFA bypassable via reset flow | High | Reset flow implemented separately from main auth | Medium — route reset through MFA gate |
| Indefinite session tokens | High | No rotation/expiry policy | Low-Medium — token lifecycle policy |
| Admin panel without MFA | High | Route marked as exception | Low — remove exception, enforce policy |
| Verbose error messages leaking stack traces | Medium | Default framework error handling | Low — suppress in production |
| Subdomain takeover on deprecated CNAME | Medium | DNS record pointing to deprovisioned service | Low — remove DNS record |
Finding Category 3: Infrastructure and Configuration Findings
These are the findings that feel embarrassing because they're often basic configuration errors rather than sophisticated logic flaws. They are also often the quickest to exploit.
Exposed management interfaces. An internal admin panel accessible from the public internet without IP allowlisting. A Kubernetes dashboard with default credentials. An Elasticsearch index publicly accessible without authentication. In one case, a staging environment with a complete copy of production data, accessible without any authentication, because "it's just staging."
Excessive cloud permissions. EC2 instances or Azure VMs with instance metadata service (IMDS) accessible, running under service accounts or managed identities with far broader permissions than required. If an attacker achieves RCE on the application server, the IMDS gives them cloud credentials. If those credentials have admin-level permissions on the cloud account, the blast radius is the entire cloud environment.
Dependency vulnerabilities with known exploit chains. Dependency scanning catches vulnerabilities. What pen testers test is whether those vulnerabilities are actually exploitable in the specific context of your application. At Series-B, companies commonly have a backlog of medium and high CVEs that they've deprioritised because "the risk is theoretical." Pen testers regularly find that the risk is not theoretical — the component is reachable, the input is attacker-controlled, and the exploit is documented.
Staging environments are the most overlooked attack surface
Every pen test I've reviewed has included findings on staging or development environments. These environments are almost always less secured than production — they exist to make testing easy, which means making access easy. They frequently contain real or realistic copies of production data. They are often accessible via predictable subdomains. Treat your staging environment as if it contains your most sensitive production data, because it usually does.
Finding Category 4: Business Logic Vulnerabilities
This is the category that's hardest to find without understanding the application deeply, and hardest to prioritise without business context.
Business logic vulnerabilities are flaws in how the application enforces its own rules — pricing, permissions, rate limiting, workflow sequencing. They don't look like typical security vulnerabilities in a scanner.
Examples from real engagements:
- A SaaS billing system where changing the subscription tier downward immediately after triggering a feature that required the higher tier allowed retention of that feature permanently.
- An enterprise permission model where a user invited to a workspace with read-only access could, through a sequence of API calls that were individually valid, escalate to write access.
- A rate-limiting implementation on the API that was keyed to user ID — easily bypassed by creating free accounts in bulk.
- A file upload endpoint that accepted the MIME type from the request header without validating the actual file content, allowing malicious file types through a filter designed to prevent them.
These vulnerabilities are specific to each application and invisible to generic tooling. They require a tester who understands what the application is supposed to do and can probe whether it enforces those rules when the inputs are adversarial.
What Happens After the Report
The pen test report is a findings list with severity ratings and remediation guidance. What companies do with it varies enormously, and the variation matters more than the test itself.
The pattern I advocate for — and that I help implement when I'm engaged post-test — is a structured remediation sprint rather than folding findings into the normal backlog. Critical and high findings go into a dedicated sprint with a two-week deadline. The pen test firm is available for re-testing after remediation. Medium findings get scheduled with a defined owner and a date. Low findings go into the backlog with explicit prioritisation.
The structured flow from report to verified fix looks like this:
The failure mode is treating the pen test report as a compliance artifact — something to produce for a customer's security questionnaire, then file. The findings don't disappear because they were documented. They sit in the application, waiting.
| Severity | Expected Remediation Timeline | Common Failure Mode |
|---|---|---|
| Critical | 1–5 business days | Deprioritised behind sprint commitments |
| High | 2–3 weeks | No owner assigned; sits in backlog |
| Medium | 30–60 days | Never scheduled; report filed |
| Low / Informational | Backlog with explicit date | Indefinite deferral |
What a Good Pen Test Scope Actually Includes
Not all pen tests are created equal. A checkbox pen test — automated scanning plus a two-day engagement by a junior tester — will find the obvious misconfigurations and produce a report that satisfies a procurement questionnaire. It will miss the BOLA findings, the business logic vulnerabilities, and the authentication edge cases.
A quality engagement for a Series-B SaaS includes: authenticated testing with multiple user roles, explicit API testing against documented and undocumented endpoints, business logic testing with product context provided upfront, and time allocated for manual testing beyond automated tooling. Budget €50,000–90,000 for a quality external firm. Expect a two-to-four week engagement. Require re-testing of critical and high findings as part of the scope.
The companies I've seen treat pen testing as a genuine security exercise — not a compliance checkbox — are the ones that come out of the report with a materially more secure application and an engineering team that understands the attack surface of what they built.
That understanding compounds. Engineers who've seen what a pen tester finds start writing code differently.
If your company is approaching a Series-B, handling a customer security questionnaire that requires a recent pen test, or preparing for SOC2 or ISO 27001 certification — the pen test is one piece of a broader security posture you need to build deliberately. Let's talk — book a 30-minute discovery call. I'll help you scope the right engagement, select a quality firm, and — critically — make sure the findings actually get fixed.