Web application penetration testing methodology
How Strobes tests a web application the way a real attacker would: an exploitability-first methodology across 19 categories and 124+ checks, combining expert manual testing with agentic pentesting.
Vulnerability assessment and penetration testing is a systematic way of impersonating a real-world attacker to discover security issues in a web application. Done well, it does more than list weaknesses: it shows what an attacker can actually reach, weighs the impact on the business, and helps the team fix the findings in the right order.
The objective of a Strobes web application engagement is to impersonate a real-world attacker, discover security issues within the application, evaluate the impact and risk to the business, and help resolve the findings in a timely manner. To do that, Strobes follows an exhaustive methodology that covers the breadth and depth of the application. It aligns with the OWASP Web Security Testing Guide and the OWASP Top 10, extends them with checks proven on complex enterprise applications, and is driven by agentic pentesting alongside manual testing so that findings are confirmed, not just flagged.
The full scope is below, organized into 19 categories. Some techniques appear in more than one category because the context differs, for example SQL injection as an authentication bypass and as an injection class in its own right.
The test is not finished when a payload lands. Every category below is scored by what an attacker can actually exploit and what that exploitation would cost the business, not by raw scanner output.
Six stages, scoping to retest
How a Strobes web application engagement runs, from scoping to retest.
Scope & RoE
Define the surfaces, roles, and integrations in scope, and the rules of engagement.
Information gathering
Recon and fingerprinting of the application, its framework, and everything it leaks.
Testing
Work the full methodology: 19 categories and 124+ checks across the application.
Exploitation
Prove what is actually exploitable rather than reporting what merely looks vulnerable.
Reporting
Rank every finding by exploitability and business risk, with the best mitigation for each.
Retest
Verify remediation and confirm the fix holds against the original attack path.
Information gathering and reviewing
Every engagement starts by mapping the application the way an attacker would: what it runs, what it exposes, and what it leaks before a single payload is sent.
- Exploring the application
- Fingerprinting the application framework
- Identifying known vulnerabilities
- Reviewing client-side resources for sensitive information
- Leakage of sensitive information in Google, GitHub, Travis, etc.
Authentication testing
Authentication is the first control an attacker probes. Strobes tests whether it can be bypassed, brute-forced, or worn down through weak account and second-factor handling.
- Bypass of authentication
- SQL injection
- XPATH injection
- LDAP injection
- Testing for OAuth configuration
- Reviewing state parameter or other CSRF protection mechanism
- Reviewing callback or redirect_url parameter for arbitrary domains, sub-domains or directories
- Reviewing referer leaks
- Testing for rate limiting by brute-forcing
- Testing the robustness of 2FA/OTP functionality
- Rate limiting
- Length
- Predictability
- Bypass of CAPTCHA
- Session fixation
- Test account suspension/resumption process
- User enumeration
- Username / password policy
Password reset functionality
Password reset flows are a common path to account takeover. Strobes checks the full life cycle of a reset link for leakage, predictability, and reuse.
- Leakage of password reset link
- Insecure direct object reference
- Insecure session management
- Weakness in life cycle of password reset link
- Lifetime of reset link
- Re-use of same link
- Predictability of token in the reset link
- Weak encryption of token
- Usage of attacker's token on victim's account
API testing
APIs carry the logic and data that web front ends only hint at. Strobes tests them directly, mapped to the OWASP API Security Top 10, including the authorization flaws scanners routinely miss.
- Authorization header analysis
- Basic
- Bearer
- None
- Custom
- API keys expiration
- Unauthenticated / anonymous access
- Usage of same authorization token for every user
- Analyzing the predictability of token
- Broken object level authorization (BOLA)
- Broken function level authorization (BFLA)
- Mass assignment
- GraphQL introspection and query abuse
- JWT attacks (alg=none, weak secret, key confusion)
- Coverage mapped to the OWASP API Security Top 10
Sensitive data exposure
Applications leak more than teams expect through errors, metadata, and forgotten files. Strobes looks for data that should never reach a response.
- Insecure error handling
- Disclosure of sensitive files (example: phpMyAdmin or web.config)
- Information disclosure via metadata
- Insecure communication channel (force browsing)
- Hidden / sensitive directories & files in robots.txt
- Return of sensitive information in later responses (password, OTP, other users' data)
Cache testing
Caching layers can serve one user's data to another. Strobes tests where sensitive responses are cached and whether that caching can be abused.
- Google caching
- Cacheable HTTPS responses
- Sensitive data in URLs
- Web cache deception
Headers and policies scrutiny
Security headers and origin policies are easy to misconfigure and easy to overlook. Strobes checks the ones that decide whether a browser trusts the wrong source.
- CRLF injection
- Host header injection
- Weak username or unenforced policy
- Weak password policy
- Cross origin resource sharing
- Clickjacking
- URL redirection (when the response header contains a "location:" header)
Session management
A session is only as strong as how it is issued, protected, and ended. Strobes tests session handling and the CSRF defenses that guard it.
- Testing insecure logout implementation
- Cross site request forgery
- Null token
- Tampered token
- Lack of token
- Reuse of attacker's token
- Double CSRF token
- CSRF token predictability
- Application/json bypass using cross-domain.xml
- Analyzing authorization / privileges implementation through cookies
Data validation
Untrusted input is where most application attacks begin. Strobes tests how the application handles uploads, scripts, and unexpected parameters.
- Malicious file upload
- File extension
- Content-type
- File signature manipulation
- File size
- Cross site scripting
- Reflected
- Stored
- DOM
- Blind XSS (backend management system / CMS or admin panel)
- CSV injection
- HTTP Parameter Pollution
- HTTP verb tampering
Injections
Injection remains among the highest-impact classes of web vulnerability. Strobes tests each variant that lets attacker input reach an interpreter.
- Remote code execution
- SQL injection
- Boolean-based blind
- Error-based
- Union query-based
- Stacked queries
- Time-based blind
- Inline queries
- NoSQL injection
- XML injection
- XXE
- CSV injection
- Template injection
- Expression Language (EL) injection
- ORM injection
- LDAP injection
Server-side issues
Some of the most severe findings live on the server, reachable through requests the application makes on a user's behalf.
- Testing for SSRF
- Server side template injection
Business logic issues
Logic flaws pass every scanner because the request is technically valid. Strobes tests the rules behind payments and required steps that an attacker can bend.
- Payment tampering
- Bypass attaching mandatory entities
Cloud misconfigurations
Modern applications lean on cloud storage and identity. Strobes checks the permissions and signatures that decide who can read what.
- AWS S3 bucket permissions
- Successful generation of signature for other bucket assets
Supply chain and dependencies
Most application code is code someone else wrote. Strobes checks the dependencies and packages an attacker could compromise upstream.
- Vulnerable and outdated dependencies
- Dependency confusion
- Compromised or typosquatted packages
- SBOM review
Security misconfigurations
Default settings and stale software give attackers an easy first foothold. Strobes checks what was left exposed or unchanged.
- Outdated framework / CRM / WordPress
- Enabled directory listing
- Uploading files to any directory
- Default accounts with default passwords
DNS misconfigurations
DNS and mail records decide who can impersonate a domain or take over a stale subdomain. Strobes checks the records that matter.
- Looking up CNAMEs and expired services
- Looking up SPF records & configurations
- Looking up if A record is 127.0.0.1 (same-site scripting)
Miscellaneous
A handful of checks do not fit a single category but still matter to real-world exploitation.
- Reflected file download
- Accessing default files (example: phpMyAdmin)
- Verifying window.postMessage value (when set to wildcard *)
What you get at the end
When testing is complete, Strobes delivers a high-quality report that discusses the best mitigation for every finding, ranks them by exploitability and business risk, and gives a clear snapshot of the application's security posture. Findings can flow into a remediation workflow so they are tracked to resolution rather than left in a document.
Frequently asked questions
Put this methodology against your application
Bring your scope: the surfaces, roles, and integrations in your web application. Strobes will run the methodology against your real environment and show you exactly what is exploitable.
Join 150+ security teams already reducing exposure with Strobes