A web application penetration test is a controlled, ethical simulation of real-world attacks against your web app to identify vulnerabilities before malicious actors do. You'll work with security professionals who methodically probe authentication, authorization, input validation, session management, and business logic—then deliver a detailed report with findings ranked by severity and remediation guidance. The entire process typically takes two to four weeks from kickoff to final report, depending on application complexity.
This week's security news underscores why web app testing matters. Apple patched a CoreGraphics zero-day exploited in targeted attacks, Bitget lost $388 million when attackers exploited a third-party security product flaw, and CISA added seven new actively exploited vulnerabilities to its Known Exploited Vulnerabilities catalog—including CVE-2026-87902 affecting WordPress Core and CVE-2026-65660 in Microsoft SharePoint. Real-world exploits happen fast, and web applications remain a primary attack surface.
What happens before the test starts
Before any testing begins, you'll define scope with your penetration testing provider. Scope determines exactly which URLs, subdomains, API endpoints, and application functions are in-bounds for testing. You'll identify any off-limits areas—third-party payment processors, production databases with live customer data, or shared infrastructure that could impact other tenants.
You'll also establish rules of engagement: testing windows (business hours only or 24/7), communication protocols for critical findings, and emergency contact procedures. Most firms require a signed authorization letter explicitly permitting the testing—this protects both parties and ensures your hosting provider or cloud platform won't mistake legitimate testing for an actual attack.
Expect to provide test accounts at various privilege levels: unauthenticated users, standard authenticated users, administrative users, and any role-based access tiers your application implements. Testers need these to evaluate authorization controls and privilege escalation paths. You'll also share application documentation—architecture diagrams, API specifications, authentication flows—so testers understand intended behavior versus security flaws.
The testing methodology: what testers actually do
Professional web application penetration testing follows structured methodologies like OWASP Testing Guide, PTES (Penetration Testing Execution Standard), or NIST SP 800-115. The process typically includes five phases:
Reconnaissance and mapping: Testers enumerate all application endpoints, parameters, cookies, headers, and technologies in use. They build a complete map of attack surface—every input field, every API call, every state transition.
Automated vulnerability scanning: Tools like Burp Suite, OWASP ZAP, or commercial scanners identify low-hanging fruit: missing security headers, known vulnerable libraries, common misconfigurations. This establishes a baseline but represents only 20-30% of what a thorough test uncovers.
Manual testing of authentication and session management: Testers probe login mechanisms, password reset flows, multi-factor authentication, session tokens, and logout functions. They test for credential stuffing vulnerabilities, weak password policies, predictable session IDs, and session fixation flaws.
Authorization and access control testing: Every privilege boundary gets tested. Can a standard user access admin functions by manipulating parameters? Can users view or modify other users' data? Do API endpoints enforce authorization checks? Insecure Direct Object References (IDOR) and broken access controls remain among the most common and damaging vulnerabilities.
Input validation and injection testing: Testers inject malicious payloads into every input field, URL parameter, header, and cookie. They test for SQL injection, cross-site scripting (XSS), command injection, XML external entity (XXE) injection, and server-side request forgery (SSRF). Modern applications also get tested for NoSQL injection, GraphQL injection, and API-specific vulnerabilities.
Business logic testing: This is where human expertise separates professional testing from automated scanning. Testers examine workflows for logic flaws: Can users manipulate prices during checkout? Can they bypass payment verification? Can they abuse referral systems or promotional codes? Can they trigger race conditions in financial transactions?
What you'll receive: the penetration test report
The deliverable is a comprehensive written report, typically 40-100 pages depending on findings. Executive summary sections explain overall risk posture and high-level recommendations for business stakeholders. Technical sections document each vulnerability with:
- Severity rating (Critical, High, Medium, Low, Informational) based on exploitability and business impact
- Detailed description of the vulnerability and affected components
- Proof-of-concept showing exactly how to reproduce the issue
- Evidence including screenshots, request/response pairs, and command output
- Remediation guidance with specific code examples or configuration changes
- References to OWASP, CWE, or CVE identifiers where applicable
Expect a findings review call where testers walk through major vulnerabilities, answer questions, and clarify remediation priorities. Some firms include limited retesting after you've implemented fixes—verify this during scoping.
Common surprises and misconceptions
Testing will break things (sometimes): Penetration testing involves sending malicious input and pushing applications to failure states. While professional testers take precautions, crashes or temporary service disruptions can occur. Schedule testing during maintenance windows or against staging environments when possible.
You'll find more issues than you expected: First-time clients often underestimate how many findings a thorough test uncovers. Fifteen to thirty findings is typical for a moderately complex application. Not every finding represents an emergency—prioritize based on severity and exploitability.
Automated scans miss most logic flaws: If you've run automated scanners and found nothing, you might assume your application is secure. Manual testing routinely uncovers authorization bypasses, business logic flaws, and complex injection vulnerabilities that scanners cannot detect. The Bitget breach this week exploited a third-party security product—exactly the kind of integration flaw that requires human analysis.
Compliance testing differs from security testing: A penetration test satisfying PCI DSS requirements includes specific testing procedures defined in the standard. SOC 2 penetration testing focuses on trust service criteria. Make sure your provider understands compliance requirements if that's your driver.
Timeline and costs: realistic expectations
A straightforward web application test typically requires:
- Scoping and planning: 3-5 business days
- Active testing: 5-10 business days (calendar time, not continuous testing hours)
- Report preparation: 3-5 business days
- Review and remediation consultation: 1-2 days
Total elapsed time: two to four weeks from kickoff to final report delivery.
Costs vary widely based on application complexity, number of user roles, API endpoint count, and testing depth. Small business web applications typically range from $4,000 to $12,000. Mid-sized applications with complex workflows run $12,000 to $30,000. Enterprise applications with extensive APIs, microservices, and multiple integration points can exceed $50,000.
Factors that increase cost: large numbers of authenticated user roles, complex business logic, thick client applications (mobile apps, single-page applications with heavy client-side logic), extensive API surfaces, and compliance-specific testing requirements.
Preparing your team and environment
Designate a technical point of contact who can answer questions about application behavior, provide additional test accounts if needed, and receive real-time notifications of critical findings. Make sure your incident response team knows testing is occurring—you don't want them blocking tester IP addresses or investigating legitimate test activity as a breach.
Ensure your staging or test environment mirrors production as closely as possible. Configuration differences between environments often mask or create vulnerabilities that don't exist in production.
Schedule internal time for remediation after the report arrives. A penetration test provides maximum value when you actually fix the issues identified—not when the report sits in a drawer.
What happens after: remediation and retesting
Prioritize critical and high-severity findings for immediate remediation. Medium findings should be scheduled into upcoming sprint cycles. Low and informational findings inform long-term security roadmap improvements.
Some findings require code changes; others need configuration updates or infrastructure modifications. Work with your development team to implement fixes properly—quick patches that don't address root causes often introduce new vulnerabilities.
Many firms include limited retesting of critical findings after remediation. Full retests typically occur annually or after major application changes. Continuous security improvement means integrating secure development practices, conducting code reviews, and implementing automated security testing in your CI/CD pipeline.
Vici Tech Solutions conducts web application penetration testing for businesses of all sizes, from startups to enterprises, with detailed reporting and remediation support tailored to your team's needs. Contact us to discuss scope and scheduling for your first test.