The Question I Ask Before Testing Any Target

Mindset beats methodology.

Photo by Laurin Steffens on Unsplash

Read here.

When people talk about bug bounty hunting and security research, the conversation usually revolves around methodology.

Reconnaissance workflows.

Payload lists.

Automation pipelines.

Custom tooling.

Frameworks.

And while those things matter, they’re not where successful engagements begin.

Before I run a scanner.

Before I enumerate subdomains.

Before I open Burp Suite.

Before I send a single request.

I ask myself one question:

“What assumptions are the developers making?”

That question has led to more findings than any tool I’ve ever installed.

Because vulnerabilities rarely appear when software behaves unexpectedly.

They appear when software behaves exactly as its creators assumed it would.

Most Security Testing Starts Too Late

A common mistake among new researchers is jumping directly into testing.

Run reconnaissance.

Collect URLs.

Launch scanners.

Start fuzzing.

The workflow feels productive.

But often, it skips the most important step:

Understanding how the application is supposed to work.

Without that understanding, you’re testing endpoints.

Not investigating systems.

And systems are where vulnerabilities live.

Every Application Is Built on Assumptions

Developers make assumptions constantly.

They have to.

Modern applications are too complex otherwise.

Some assumptions are reasonable

• Users will authenticate normally.
• Requests will follow expected workflows.
• APIs will be called in the intended order.

Others are dangerous:

• Users won’t modify identifiers.
• Clients won’t manipulate requests.
• Internal services always agree.
• Cached data is always accurate.
• Hidden functionality won’t be discovered.

Attackers don’t break software.

They break assumptions.

The Login Page Example

Imagine a login page.

Most researchers immediately think about:

• SQL injection
• Authentication bypass
• Brute force weaknesses
• Credential stuffing

Those are valid concerns.

But my first question is different.

What assumptions exist here?

Maybe developers assume

• Users only log in through the web interface.
• Session tokens are consumed by a single device.
• Password reset flows are always completed honestly.

Suddenly the investigation changes.

You’re no longer looking for known vulnerabilities.

You’re looking for trust relationships.

And trust relationships fail surprisingly often.

The Shift That Changed My Findings

Years ago, my workflow looked like everyone else’s.

Recon.

Enumeration.

Scanning.

Testing.

Repeat.

And while I occasionally found vulnerabilities, many engagements felt random.

Some produced findings.

Others produced nothing.

The turning point came when I stopped asking:

“What vulnerability exists here?”

And started asking:

“What does this system trust?”

That single mindset shift changed everything.

Because trust is measurable.

Trust creates workflows.

Trust creates permissions.

Trust creates boundaries.

And boundaries create attack paths.

A Real-World Example

I once encountered an API endpoint that appeared perfectly secure.

Authentication worked.

Authorization worked.

Input validation worked.

Everything looked correct.

Most testing techniques produced nothing.

Then I asked:

Why does this endpoint trust the client to provide this identifier?

That question led to a deeper investigation.

The identifier wasn’t vulnerable by itself.

But several downstream services relied on it.

Eventually, that trust relationship exposed an object-level authorization flaw.

The vulnerability wasn’t hiding in the endpoint.

It was hiding in the assumption.

Why Tools Can’t Answer This Question

Modern security tools are incredibly powerful.

They can

• Discover assets
• Enumerate endpoints
• Identify patterns
• Detect known weaknesses

But tools struggle with assumptions.

A scanner can tell you an endpoint exists.

It cannot tell you what developers believe about that endpoint.

And those beliefs often matter more than the implementation.

Because applications are built around human decisions.

Not just code.

The Three Assumptions I Look For

Whenever I begin testing a target, I usually focus on three areas.

1. Identity Assumptions

What does the system assume about users?

Examples

• Users only access their own data.
• Users complete workflows sequentially.
• Users never manipulate session state.

These assumptions frequently create authorization issues.

2. Trust Assumptions

What information does the system trust automatically?

Examples:

• Headers
• Tokens
• Object identifiers
• Internal API responses

Whenever trust exists, verification becomes important.

And verification failures become vulnerabilities.

3. Visibility Assumptions

What functionality do developers believe nobody will discover?

Examples

• Hidden endpoints
• Deprecated API
• Legacy workflows
• Internal administration features

Attackers routinely find things developers assume are invisible.

Why Mindset Beats Methodology

Methodologies evolve constantly.

New tools appear.

New techniques emerge.

New attack surfaces become relevant.

But mindset remains surprisingly stable.

Researchers who consistently find vulnerabilities tend to share similar habits:

They question assumptions.

They investigate inconsistencies.

They explore trust boundaries.

They ask uncomfortable questions.

The specific tools change.

The thinking rarely does.

The Most Valuable Skill in Security

People often ask what technical skill matters most.

Programming?

Networking?

Web security?

Cloud architecture?

All valuable.

But if I had to choose one, it would be curiosity.

Because curiosity fuels the question:

Why does the system behave this way?

And that question uncovers assumptions.

Assumptions uncover trust.

Trust uncovers vulnerabilities.

The chain starts there.

The Engagement That Taught Me This Lesson

One of my favorite findings began with a perfectly normal application.

No obvious flaws.

No unusual behavior.

No scanner results.

Nothing.

The only thing that stood out was a workflow that trusted client-side state more than expected.

Most researchers would have ignored it.

The application was functioning exactly as designed.

That’s what made it dangerous.

The design itself contained the weakness.

And that weakness only became visible after asking:

What assumption made this workflow possible?

Final Thought

Every target is different.

Every application has unique technologies, architectures, and workflows.

But before any testing begins, I always ask the same question:

What assumptions are the developers making?

Because vulnerabilities are rarely random.

They’re usually the consequence of trust placed in the wrong place.

The scanner might help you find the endpoint.

The methodology might help you test it.

But mindset is what tells you where to look in the first place.

And in cybersecurity, that often makes all the difference.