A hands-on reference for authorized web application and API penetration testing: a 15-stage lifecycle from reconnaissance to retest, aligned to OWASP WSTG, the OWASP Top 10, and the OWASP API Security Top 10, with a validation workflow that treats scanner output as leads rather than findings.
- Author: Jahidul Mir | Penetration Tester
- Focus: Web Application Security, API Security, Vulnerability Validation, Reporting
- Methodology: OWASP WSTG, OWASP Top 10, OWASP API Security Top 10
- Testing model: Black-box, authorized testing only
- Related: Penetration Testing Methodology
Personal project. Not affiliated with or endorsed by any employer or client.
This repository demonstrates a structured approach to assessing web applications and APIs from an external attacker's perspective.
The objective is to identify security weaknesses, manually validate vulnerabilities, assess potential business impact, and provide actionable remediation recommendations.
All activities documented here are intended for authorized testing, controlled laboratories, training environments, and permitted security assessments only.
1. Reconnaissance
2. Attack Surface Discovery
3. Technology Fingerprinting
4. Authentication Testing
5. Session Management Testing
6. Access Control Testing
7. Input Validation Testing
8. Business Logic Testing
9. API Security Testing
10. Security Configuration Review
11. SSRF & Deserialization Testing
12. Vulnerability Validation
13. Evidence Collection
14. Risk Assessment
15. Reporting & Retesting
The first stage focuses on understanding the application's external attack surface.
Activities
- DNS enumeration
- Subdomain discovery
- Certificate Transparency review
- WHOIS and DNS record analysis
- Technology fingerprinting
- HTTP response/header analysis
- robots.txt and sitemap review
- Publicly exposed application resources
- Third-party service identification
Example Tools: Amass, Subfinder, HTTPX, Nmap, Wappalyzer, crt.sh, Shodan, Censys
Identify application components and publicly accessible functionality.
Areas of Interest
- Login and registration pages
- Password reset functionality
- Administrative interfaces
- API endpoints
- File upload functionality
- Search functionality
- Parameters and query strings
- Hidden directories and files
- JavaScript-discovered endpoints
- Documentation and debug endpoints
Tools: Burp Suite, OWASP ZAP, Gobuster, ffuf, Katana, Wayback-based URL discovery
Identify technologies that may influence the testing strategy, such as:
- Web servers
- Frameworks
- CMS platforms
- JavaScript libraries
- CDN/WAF providers
- Cloud hosting
- Third-party integrations
- API technologies
Technology identification is used to guide testing and should not be treated as proof of vulnerability by itself.
Authentication controls are assessed for weaknesses that could allow unauthorized access.
- Username enumeration
- Weak authentication controls
- Password policy weaknesses
- Brute-force protections
- Rate limiting
- Password reset workflow
- MFA implementation
- Authentication bypass
- Account recovery weaknesses
- Session handling after authentication
Session security is assessed after authentication.
- Session token strength
- Session fixation
- Session reuse
- Session invalidation
- Logout behavior
- Session timeout
- Cookie security attributes (HttpOnly, Secure, SameSite)
Determine whether users can access functionality or data outside their authorized privileges.
- Horizontal privilege escalation
- Vertical privilege escalation
- IDOR / BOLA
- Forced browsing
- Unauthorized administrative functionality
- Object-level authorization
- Role enforcement
Example questions
- Can User A access User B's resources?
- Can a normal user access administrative functionality?
- Can object identifiers be modified to access another user's data?
- Are authorization controls enforced server-side?
Test application inputs for unsafe processing.
- SQL Injection
- NoSQL Injection
- Cross-Site Scripting
- Command Injection
- Server-Side Template Injection
- Path Traversal
- Header Injection
- Parameter manipulation
Testing should distinguish between a suspicious response and a validated vulnerability.
Automated scanners often cannot identify application-specific business logic weaknesses. Testing may include:
- Workflow bypass
- Price manipulation
- Quantity manipulation
- Missing authorization checks
- Race conditions
- State-transition abuse
- Duplicate transactions
- Multi-step process bypass
This is an area that requires manual analysis.
Where APIs are present, testing follows the OWASP API Security Top 10 and includes:
- Authentication
- Authorization
- Object-level authorization
- Mass assignment
- Rate limiting
- Parameter manipulation
- Excessive data exposure
- Undocumented endpoints
- Shadow APIs
API testing should focus on whether security controls are consistently enforced at the server/API layer.
Assess common application and server configuration weaknesses.
- Missing security headers
- Verbose error messages
- Debug endpoints
- Exposed administration interfaces
- Directory listing
- Insecure HTTP methods
- Outdated components
- Unnecessary services
- Sensitive file exposure
Where functionality accepts URLs, remote resources, or serialized objects, assess for:
SSRF
- Server-side URL fetching
- Internal resource access
- Cloud metadata exposure
- Network boundary bypass
Deserialization
- Unsafe object processing
- Untrusted serialized input
- Remote-code-execution opportunities
Testing depth should be controlled by the engagement Rules of Engagement.
Automated scanner results are treated as leads rather than conclusions.
Scanner / Observation
|
Manual Verification
|
Reproduction
|
Impact Assessment
|
Evidence Collection
|
Risk Rating
|
Report
Every reported vulnerability should have sufficient evidence to demonstrate that the issue is real and reproducible.
For each validated finding, document:
- Affected asset
- Endpoint
- HTTP method
- Relevant parameter
- Request/response evidence
- Reproduction steps
- Security impact
- Business impact
- CVSS score
- Recommended remediation
Where possible, evidence should demonstrate impact without unnecessary access to sensitive information.
Findings are categorized using CVSS v3.1 as the quantitative baseline.
| Severity | CVSS |
|---|---|
| Critical | 9.0–10.0 |
| High | 7.0–8.9 |
| Medium | 4.0–6.9 |
| Low | 0.1–3.9 |
| Informational | N/A |
Business impact should also be considered when prioritizing remediation.
A professional web application penetration test report should contain:
- Executive Summary: business-focused explanation of the overall security posture
- Scope: applications, domains, endpoints, and testing constraints
- Methodology: testing approach, tools, frameworks, and limitations
- Findings Summary: prioritized findings by severity
- Detailed Findings: Finding ID, Title, Severity, CVSS Score, Affected Asset, Description, Evidence, Impact, Reproduction, Remediation, References
- Remediation Plan: specific, actionable recommendations rather than "patch the issue"
- Retest: verification that each fix works before the finding is closed
Severity: Low
Affected Asset: [REDACTED]
Description
Security response headers provide browser-side defensive controls that can reduce the impact of certain classes of web attacks.
Evidence
HTTP/1.1 200 OK
Strict-Transport-Security: ...
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Missing controls: Content-Security-Policy, Referrer-Policy, Permissions-Policy
Impact
The absence of recommended security headers may reduce browser-side defense in depth against future application vulnerabilities and information leakage.
Recommendation
Implement security headers appropriate to the application's architecture and integrations, then validate behavior across all relevant application paths.
Reconnaissance: Amass, Subfinder, HTTPX, Shodan, Censys, crt.sh
Enumeration: Nmap, Gobuster, ffuf, Katana
Web and API Testing: Burp Suite, OWASP ZAP, Postman, Nikto, SQLMap, Nuclei
Supporting Analysis: curl, dig, nslookup, Wireshark
Tool selection should be based on the authorized scope, target environment, and testing constraints.
Sanitized, hands-on work is added here as it is completed. Nothing in this repository comes from client or employer engagements.
Planned:
- Lab write-ups against deliberately vulnerable applications (OWASP Juice Shop, DVWA) with reproducible steps
- Sample penetration test report for a fictional target
- WSTG-mapped testing checklist
- Burp Suite workflow notes
All security testing represented in this repository is intended for:
- Authorized penetration testing
- Controlled security laboratories
- Training environments
- Capture-the-flag platforms
- Systems for which explicit permission has been granted
Unauthorized testing of third-party systems is not permitted.
The underlying methodology requires written authorization and clearly defined Rules of Engagement before active testing begins.
Jahidul Mir | Penetration Tester | Web App, API, Cloud & Active Directory
Areas of focus: Web and API Security, Penetration Testing, Vulnerability Assessment, Active Directory, Cloud Security, Security Reporting
This repository is maintained for cybersecurity education, professional development, and authorized security testing.
Any real-world assessment material published here should be appropriately sanitized and must not contain confidential client information, credentials, secrets, private tokens, or other sensitive data.