SysTools logoSysTools VAPT
VAPT Service

Web Application VAPT

Security assessment of web applications — authentication, access control, injection, business logic, session management and application configuration, aligned to the OWASP Top 10 and the OWASP Web Security Testing Guide.

Progress 0% 0 of 0 answered 0 mandatory pending

Please note

  • Do not enter live passwords, API keys or production credentials in this form. Credentials are shared separately through an approved secure channel.
  • Only the URLs and functionality listed in the approved scope are tested. Fields marked * are required to begin testing.
  • This is a controlled, defined-scope assessment — not a red-team engagement.

1 Assessment Details

Mandatory

2 Scope Type and Testing Approach

Mandatory

Grey Box shares limited information plus credentials for each role. White Box adds full documentation and application design. Black Box shares nothing, so part of the effort goes into discovery rather than testing.

Please note: assessment frequency is not included in the timeline estimate in section 10. The estimate covers a single assessment cycle only. Frequency, and the schedule for repeat cycles, is agreed while finalising the scope.

A single-time engagement covers one assessment cycle together with its retests.

3 Application Inventory and Counts

Drives effort

Enter approximate counts — leave blank or zero where not applicable. The number of applications feeds the timeline estimate in section 10.

Application

Applications in scope
Screens / pages
Languages or localisations

Interfaces

API endpoints
Admin or back-office panels
File upload features

Integrations

Payment or transaction flows
Third-party integrations
SSO / SAML / OAuth integrations

Only the URLs listed in the approved scope are tested.

4 Access and Credentials

Blocks kickoff if incomplete

Without credentials per role, IDOR, privilege escalation and broken access control cannot be tested — the largest finding category for web applications.

Two accounts in the same role are needed to prove whether one user can reach another user's data.

5 Test Environment and Restrictions

Mandatory

Anything not authorized here will not be tested.

Testing through an enforcing WAF reports the WAF's behaviour rather than the application's real security posture.

Testing techniques

Automated scanning, authenticated testing, credential and brute-force testing within agreed rate limits, controlled exploitation of confirmed vulnerabilities, privilege escalation testing, business logic and payment flow testing, and file upload testing are all included as standard within a Web Application VAPT engagement.

This engagement is a controlled, defined-scope assessment, not a red-team exercise. It does not include social engineering, phishing, physical-security testing, stealth or evasion operations, persistence, unrestricted lateral movement or data-exfiltration exercises.

6 Data Sensitivity and Standards

Drives severity ratings

7 Testing Coverage Areas

All included by default

Deselect any area to be excluded from this engagement.

8 Assessment Methodology

Automated and manual security testing, adapted to the approved scope, application functionality, available user roles, access provided and testing environment.

01

Scope and Access Verification

Approved application URLs, domains, subdomains and APIs, testing environment, user roles, test credentials, testing period, restrictions, technical and escalation contacts, and written authorization.

02

Information Gathering

Application technologies, web server details, frameworks, HTTP security headers, SSL/TLS configuration, publicly accessible files and directories, JavaScript files, login and administrative interfaces, third-party components and API endpoints.

03

Application Mapping

Login and registration, password reset, account management, file upload and download, administrative functionality, search, user and role management, API requests, approval processes, transactions and business-critical workflows.

04

Automated Vulnerability Assessment

Web vulnerability scanning, SSL/TLS testing, security header analysis, directory and parameter discovery, technology and vulnerable component identification, server configuration checks and API endpoint discovery. All findings are manually reviewed.

05

Manual Security Testing

Authentication, authorization and access control, session management, input validation, injection, file handling, API security, sensitive data exposure, security configuration, client-side security, error handling and cryptographic controls.

06

Business Logic Testing

Approval workflow bypass, skipped process steps, price and quantity manipulation, coupon and expired link reuse, account and subscription restriction bypass, repeated transactions, identifier manipulation and race conditions. Performed manually.

07

Vulnerability Validation

Each issue is reproduced with the affected functionality and user role identified, exploitability and impact evaluated, and evidence captured using controlled proof-of-concept techniques. Destructive testing is avoided.

08

Risk Assessment, Reporting and Retest

Severity from exploitability, privileges required, user interaction, data sensitivity, impact on confidentiality, integrity and availability, affected users, and business and regulatory impact. Findings are then retested and their status updated.

This is not a red-team engagement

Testing is limited to the approved URLs and functionality, the defined testing period, agreed techniques and documented restrictions. Only the minimum level of exploitation required to confirm a vulnerability is performed, and unnecessary access to sensitive information is avoided.

9 Vulnerability Risk Classification

SeverityDescription
CriticalMay result in complete application, database, server or administrative compromise. Immediate remediation is recommended.
HighMay result in significant unauthorized access, sensitive-data exposure, account takeover or privilege escalation.
MediumMay affect application security under specific conditions, or may require limited access or user interaction.
LowLimited direct security impact; remediated as part of security-improvement activities.
InformationalSecurity observation, configuration improvement or best-practice recommendation without direct exploitability.

After retesting each finding is marked Closed, Open, Partially Fixed, Risk Accepted or Not Retested.

10 Timeline Estimate

The number of applications is carried over from section 3 automatically.

Timeline inputs

Number of web applications
Parallel testing teams
Number of retests

One retest is included as standard. Increase this only if additional retest cycles are required.

Estimated duration 0 working days
Testing0
Retest0

Subject to final scope review, access availability and resource confirmation. The final timeline is confirmed after the complete scope has been reviewed and understood.

Save and Export Response

Responses are stored in this browser until exported or cleared.