Lessons from Real Security Assessments #1: How I Approach a New VAPT Assessment

Before we begin, I would like to mention that every security professional has their own approach to conducting a VAPT assessment.

This is simply the methodology that I personally follow and have refined over time while working on different security assessments.

It has worked well for me, helped me stay organized during engagements, and ensured that important areas are not missed during testing.

I hope this approach is useful for those who are starting their journey in Application Security and VAPT.

Now, let's jump into the content.

When I first started working on security assessments, one question I always had was:

"Where do security testers actually begin when a new VAPT project is assigned?"

Most training materials teach vulnerabilities such as SQL Injection, XSS, IDOR, and Authentication Bypass. However, very few explain the actual approach followed during a real assessment.

Over the years, while working on web applications, mobile applications, APIs, and authentication systems, I developed a process that helps me understand the application before diving into vulnerability testing.

In this article, I'll share how I approach a new VAPT Assessment

Step 1 — Understanding the Scope

Before touching any testing tool, I first try to understand the application itself.

Questions I typically ask include:

• What type of application is this?
• Is it a Web Application, Mobile Application, API, or SSO Portal?
• What are the critical business functions?
• What environments are available (QA, UAT, Staging, Production)?
• What user roles exist?
• Are test accounts provided?

Many security issues are missed simply because the tester does not understand how the application is intended to work.

The better I understand the business flow, the more effective my testing becomes.

Step 2: Review the Information Provided

Next, I review everything shared by the development or project team.

This may include:

• Application URLs
• Test credentials
• API collections
• Mobile APK files
• Architecture diagrams
• Feature documentation

Even a quick review of this information often provides valuable insights into the application's design and functionality.

Step 3: Explore the Application

Before opening any testing tools, I spend time using the application as a normal user.

I explore areas such as:

• Login and Logout
• Forgot Password
• Registration
• User Profile
• Dashboard
• Settings
• Reports
• Administrative Functions

At this stage, my goal is not to find vulnerabilities.

My goal is to understand how the application works.

Step 4: Map the Functionality

As I explore the application, I start creating a mental map of its functionality.

I try to identify:

• User workflows
• Available features
• User roles
• Sensitive functions
• Business-critical operations

The better I understand the workflow, the easier it becomes to identify security weaknesses later.

Step 5: Identify Technologies

Next, I try to understand the technologies being used.

Examples:

• ASP.NET
• Java
• Node.js
• React
• Angular
• Mobile APIs
• OAuth
• SAML
• JWT Authentication

Understanding the technology stack helps me identify technology-specific attack surfaces and common weaknesses

Step 6: Capture and Analyze Traffic

Once I understand the application flow, I configure Burp Suite and start observing traffic.

I pay attention to:

• Authentication requests
• Session cookies
• JWT tokens
• API endpoints
• Request and response patterns

This helps me understand how the application communicates behind the scenes.

Step 7: Build My Testing Checklist

Only after understanding the application do, I start planning the assessment.

My checklist usually includes:

• Authentication Testing
• Authorization Testing
• Session Management Testing
• Input Validation Testing
• API Security Testing
• Business Logic Testing
• File Upload Testing

At this stage, I am not deeply testing these areas yet.

Instead, I am preparing my approach and ensuring that no important area is overlooked during the assessment.

What Happens Next?

Once the application is understood and the testing plan is ready, I begin the actual security assessment.

This is where activities such as:

• Authentication Testing
• Authorization Testing
• Session Management Testing
• Business Logic Testing
• API Security Testing

are performed in detail.

I will cover these topics individually in future articles as part of this series.

Final Thoughts

Many people assume that a VAPT assessment starts with vulnerability scanning and exploitation.

In my experience, the first day is usually spent understanding the application, its users, its workflows, and its business objectives.

The better you understand the application, the better your security testing becomes.

For me, Day 1 is not about finding vulnerabilities.

It is about building the foundation for a successful assessment.

Coming Next …...

👉 Authentication Testing: What I Usually Check During a VAPT Assessment

In the next article, I will share my approach to authentication testing, including common areas I review, real-world checks I perform, and why authentication remains one of the most critical components of every security assessment.