Introduction
The first finding wasn't critical.
It wasn't even particularly interesting.
There was no SQL Injection.
No Remote Code Execution.
No authentication bypass.
Just an API endpoint that shouldn't have been exposed.
On its own, it looked like a low-severity finding.
But penetration testing isn't about collecting vulnerabilities.
It's about understanding what those vulnerabilities can reach.
A forgotten endpoint can expose functionality.
That functionality can reveal an authorization weakness.
That weakness can provide access to another service.
That service can trust information it shouldn't.
And suddenly, several ordinary findings can become a serious attack path.
The endpoint wasn't the vulnerability.
The attack chain was.
The Problem With Looking at Vulnerabilities Individually
Security assessments often produce lists like:
Finding #1 → Low
Finding #2 → Medium
Finding #3 → Medium
Finding #4 → Informational
From a reporting perspective, this makes sense.
But attackers don't necessarily see four findings.
They see a path.
Finding A
↓
Finding B
↓
Finding C
↓
Finding D
↓
Impact
This distinction is one of the most important differences between vulnerability scanning and offensive security.
A scanner asks:
"Is this component vulnerable?"
A penetration tester should also ask:
"What happens if I combine this with something else?"
Step 1: The Forgotten Endpoint
Imagine an application exposes:
/api/v1/profile
/api/v1/orders
/api/v1/payments
/api/v1/internal/status
The last endpoint immediately stands out.
It wasn't documented.
It wasn't visible in the application's primary workflow.
And it appeared to expose information intended for internal systems.
The initial finding might simply be:
Undocumented functionality exposed to an untrusted client.
Not necessarily critical.
But it's an entry point.
And entry points deserve investigation.
Step 2: Understanding What the Endpoint Trusts
The next question isn't:
"Can I break this endpoint?"
It's:
"What does this endpoint trust?"
Applications constantly make assumptions about incoming requests.
For example:
A header is assumed to come from an internal proxy.
A parameter is assumed to be generated by a trusted service.
A user identifier is assumed to belong to the authenticated user.
A role value is assumed to have been validated elsewhere.
An API request is assumed to originate from another trusted component.
These assumptions create trust boundaries.
And trust boundaries are where interesting vulnerabilities often appear.
Trust Is a Security Decision
Consider a simplified architecture:
Internet
│
▼
API Gateway
│
▼
Application
│
├────► User Service
│
├────► Payment Service
│
└────► Internal Service
Every arrow represents a relationship.
The application trusts the gateway.
The application trusts the user service.
The payment service trusts the application.
The internal service trusts requests from another component.
The question becomes:
What happens if one of those trust assumptions is wrong?
An attacker doesn't necessarily need to compromise every component.
They may only need to compromise the relationship between them.
Step 3: The Authorization Weakness
Suppose the endpoint accepts an object identifier.
A legitimate request might look like:
GET /api/orders/1042
The application verifies that the user is authenticated.
But authentication isn't authorization.
Being able to prove:
"I am Daniel."
doesn't prove:
"I am allowed to access order 1042."
This distinction creates one of the most common classes of application-security weaknesses.
Broken access control.
A single authorization failure might expose another user's data.
But the real question is:
What else can this access lead to?
Step 4: Following the Data
This is where penetration testing becomes interesting.
Instead of stopping after identifying an authorization weakness, the tester follows the application's data flow.
User Input
↓
API
↓
Authorization Check
↓
Backend Service
↓
Internal Request
What happens to the value after it leaves the public API?
Does another service receive it?
Is it transformed?
Is it trusted?
Is it used to construct another request?
Does the second service perform its own authorization check?
The further the data travels, the more assumptions may exist.
Step 5: The Internal Service
Eventually, the assessment reveals another service.
It isn't directly exposed to the internet.
That's good.
But the application can communicate with it.
And the internal service assumes:
"Requests coming from the application are trusted."
This is a dangerous assumption.
Internal does not automatically mean trusted.
A compromised or abused application can become a bridge into otherwise protected functionality.
This is one reason modern application architectures need clearly defined trust boundaries.
The Attack Chain
At this point, the findings can be represented as:
Undocumented Endpoint
│
▼
Authorization Weakness
│
▼
Manipulable Application State
│
▼
Trusted Internal Request
│
▼
Internal Functionality
│
▼
Expanded Access
None of these findings necessarily looked catastrophic in isolation.
Together, they form something much more important:
An attack path.
Why Automated Scanners Can Miss This
Automated scanners are extremely useful.
They can identify:
SQL Injection
XSS
Security misconfigurations
Known vulnerable components
Missing security controls
Common API weaknesses
But attack chains require understanding relationships.
A scanner may report:
Authorization weakness → Medium
Another tool may report:
Internal endpoint → Low
Another may report:
Information disclosure → Low
But the scanner may never conclude:
Medium + Low + Low
↓
Critical attack path
Because the significance isn't contained within one request.
It's contained within the sequence.
Attack Chains Are About Relationships
Consider three findings:
Finding A
An attacker can influence a value.
Finding B
Another component trusts that value.
Finding C
That component has access to a privileged operation.
Individually:
A = Medium
B = Low
C = Low
Together:
A → B → C
The combined impact can be substantially higher.
This is why experienced penetration testers don't immediately stop after finding a vulnerability.
They ask:
"Where can I go from here?"
The Difference Between a Finding and an Attack Path
A finding describes a weakness.
An attack path describes what that weakness enables.
For example:
Finding:
Broken Object Level Authorization
versus:
Attack Path:
BOLA
↓
Access another user's resource
↓
Extract sensitive identifier
↓
Invoke privileged workflow
↓
Abuse business logic
↓
Reach sensitive functionality
The second representation tells the defender something far more useful.
It explains how the system can actually be compromised.
Vulnerability Chaining Isn't Always About Exploits
An important point is that attack chains don't always require multiple technical vulnerabilities.
Sometimes the chain consists of:
A weak assumption
A legitimate feature
A missing authorization check
An exposed piece of information
A business workflow
Each component may technically function as designed.
The security problem emerges from their interaction.
This is particularly common in:
APIs
Microservices
Cloud applications
Identity systems
Payment platforms
SaaS applications
The Human Advantage
This is where human-driven penetration testing still matters.
A scanner sees:
Request → Response
A security researcher sees:
Request → State Change → Trust Boundary → New Capability → Attack Path
That difference matters.
Experienced testers continuously build a mental model of:
Users
Roles
Permissions
Resources
Services
Trust boundaries
Data flows
State transitions
They aren't simply looking for vulnerabilities.
They're looking for unexpected capabilities.
A Better Question for Pentesters
Instead of asking:
"Is this vulnerable?"
Start asking:
"What assumption is this component making?"
Then:
"Who controls that assumption?"
Then:
"What happens if the assumption is wrong?"
And finally:
"What can I reach from here?"
Those questions can uncover vulnerabilities that a checklist-driven assessment may never identify.
From Reconnaissance to Impact
A mature penetration test can be thought of as a progression:
Reconnaissance
↓
Attack Surface Mapping
↓
Endpoint Discovery
↓
Authentication Analysis
↓
Authorization Testing
↓
Trust Boundary Analysis
↓
State & Workflow Analysis
↓
Vulnerability Discovery
↓
Vulnerability Chaining
↓
Impact Validation
The objective isn't to produce the longest vulnerability report.
It's to understand the shortest realistic path to meaningful impact.
How Defenders Can Break the Chain
Attack chains can be disrupted at multiple points.
Enforce Authorization Server-Side
Never rely on the client to determine what a user is allowed to access.
Minimize Trust
Internal services should not automatically trust every request from another internal component.
Validate Across Boundaries
Data should be validated whenever it crosses a security boundary.
Apply Least Privilege
Services should have only the permissions they actually require.
Protect Internal APIs
"Internal" should never be treated as a synonym for "secure."
Monitor Unusual Sequences
Individual requests may look legitimate.
A sequence of requests may tell a completely different story.
Threat Model Relationships
Don't model components only in isolation.
Model how they communicate.
The Real Meaning of "Critical"
A vulnerability's severity shouldn't be evaluated only by looking at the vulnerable endpoint.
Consider:
Entry Point
↓
Privilege
↓
Reachability
↓
Trust
↓
Impact
A seemingly minor weakness can become extremely valuable if it provides access to another stage of an attack.
That's why vulnerability severity and attack-path significance aren't always the same thing.
Final Thoughts
The first endpoint wasn't critical.
The authorization flaw wasn't critical.
The internal service wasn't critical.
The trust assumption wasn't critical.
But together, they created something much more dangerous:
A path.
That's the mindset attackers bring to an application.
They don't necessarily ask:
"Which vulnerability here has the highest CVSS score?"
They ask:
"If I start here, where can I go next?"
And that is one of the biggest differences between simply finding vulnerabilities and actually performing offensive security.
Because sometimes the most dangerous vulnerability isn't a vulnerability at all.
It's the relationship between several small ones.
Top comments (0)