Web Application Security Testing: What It Covers
Web application security testing is the oldest discipline in offensive security and the one most organizations outsource to a scanner by mistake. This post covers what a real assessment actually checks, in the order a tester works, and what the deliverable should contain.
Reconnaissance and enumeration
Testing starts before there is anything to attack. Subdomain and asset discovery maps the true attack surface, fingerprinting identifies the stack, and content discovery finds endpoints the sitemap never mentions. Two habits produce most of the value: crawl the JavaScript bundles for endpoints and client-side validation, and mine parameters the UI never sends. Our web app pentest walkthrough shows how much this changes an engagement.
Authentication and session management
Login flows get tested for what they do and what they skip: password reset token entropy and expiry, account enumeration, lockout bypasses, session fixation, and cookie flags. The session is the trust boundary of a web application; a weak one lets an attacker become any user.
Authorization
Object-level authorization is where web applications leak other users' data. Every endpoint that takes an object ID needs a check that the caller owns the object (CWE-639), and every role boundary needs a test that a lower-privileged user cannot reach higher-privileged functions. This is the finding class we report most often, and the one with the highest business impact.
Input validation
Injection still happens: SQL injection against database paths, stored and reflected XSS, command injection through parameters that reach system calls, and unsafe file uploads. The test covers every input vector, including the ones inside JSON bodies. Frameworks with parametrized queries have made SQL injection rarer, which is why the remaining instances tend to appear where developers write raw queries.
File uploads deserve their own attention: content-type and extension checks, image re-processing, and where uploads are stored and served (CWE-434, unrestricted upload of dangerous file types).
Business logic
Logic flaws are correct behavior with the wrong inputs: negative quantities, coupon stacking, missing state transitions, replayable transactions. They are invisible to scanners and require understanding what the application is for. The OWASP Top 10 2025 categorizes this as insecure design, and it is the hardest category to automate.
Configuration and hardening
The final pass is configuration: security headers, CSP, TLS settings, error handling, and debug endpoints left in production. These are rarely critical alone, but they are the difference between a hardened target and a soft one, and they are what cheap engagements report instead of real testing.
Public bug bounty and vulnerability disclosure programs, when they exist, are a free map of where the application has already been tested hard, and where it has not.
The tools and the person
Scanners map the obvious: known CVEs, header checks, and injection fingerprints. The tester brings the part that does not automate: chaining a leaked token with a missing authorization check, turning a file upload into code execution, or proving that a bypass is exploitable rather than theoretical. The report is only as good as this layer of verification, which is why deliverable standards matter more than tooling.
Common mistakes organizations make
Three mistakes come up repeatedly. Treating a scan as a test, which our comparison post covers. Testing a staging environment that diverges from production, then being surprised the fixes do not hold. And skipping the retest, leaving the loop open until the next audit asks. Budget for the retest up front; our cost guidance shows why it belongs in the price.
Why manual testing is not optional
Scanners produce false positives, miss authorization flaws, and cannot reason about business logic. A vulnerability assessment and a penetration test are different deliverables, and the difference is manual verification. Our comparison post explains when each is the right call.
How often, and what depth
A grey-box assessment with low-privileged credentials, run annually and after major releases, is the right baseline for most organizations. Monthly scans track drift in between. ISO 27001 certification audits expect exactly this pattern: continuous scanning plus periodic deep testing with a closed evidence loop.
Takeaways
- Test the whole surface: assets, endpoints, auth, authorization, input, logic, configuration.
- Authorization and business logic are where real findings live; scanners miss both.
- Grey-box with credentials gives the best depth per dollar.
- Demand a report with reproduction steps, CVSS 3.1 scores, and CWE references.
- Include a retest so fixes are verified, not assumed.
NIMR's web & API VAPT combines automated scanning with manual testing on top, and our reporting maps every finding to the control it affects. Request an assessment or review penetration testing cost to budget.