Web Application Pentesting

This roadmap prepares you to test web applications professionally: with written permission, a clear scope and a report that helps developers fix what you find. You need basic HTTP, HTML/JavaScript and Linux skills first. Practise only on your own lab or on legal training platforms.

• Confirm you understand HTTP, HTML and basic JavaScript
• Set up a legal practice environment
• Plan a weekly study rhythm

• CyberA4U Academy — courses

Every web test starts with HTTP: methods, status codes, headers, cookies and how browsers enforce security rules such as the same-origin policy. Testers who understand the protocol find issues that tools miss.

• Read raw HTTP requests and responses
• Explain cookie attributes (Secure, HttpOnly, SameSite, Domain, Path)
• Describe the same-origin policy and CORS

Tools & tech: Web

• MDN — An overview of HTTP
• MDN — Using HTTP cookies

Before testing, map the application: its pages, parameters, roles, technologies and entry points. A complete map keeps testing systematic and inside scope.

• Build a site map of in-scope functionality
• Identify user roles and trust boundaries
• Record technologies and third-party components

Tools & tech: Web

• OWASP Web Security Testing Guide

Authentication testing checks how an application proves who a user is: password rules, lockout, multi-factor authentication, password reset and account recovery. Weaknesses here often lead to account takeover.

• Test password policy, lockout and rate limiting
• Review password reset and account recovery flows
• Check how MFA is enforced and whether it can be skipped

Tools & tech: Web

• PortSwigger — Authentication vulnerabilities
• OWASP Authentication Cheat Sheet

After login, the session token is the user's identity. Testing covers how tokens are created, stored, expired and invalidated, and whether they can be predicted, fixed or stolen.

• Check token randomness, expiry and logout behaviour
• Verify cookie flags on session cookies
• Recognise session fixation weaknesses

Tools & tech: Web

• OWASP Session Management Cheat Sheet

Broken access control is the most common serious web weakness: users reaching data or actions that belong to other users or roles. Testing needs at least two accounts per role and careful comparison.

• Test horizontal access (user A reading user B's data)
• Test vertical access (user performing admin actions)
• Explain why checks must happen on the server

Tools & tech: Web

• PortSwigger — Access control vulnerabilities
• OWASP Top 10 — A01 Broken Access Control

SQL injection happens when user input is placed into a database query without proper handling. It can expose or change data. The fix is almost always parameterised queries.

• Explain how SQL injection occurs
• Recognise error-based, UNION-based and blind variants
• Recommend parameterised queries and least-privilege database accounts

Tools & tech: Web

• PortSwigger — SQL injection
• OWASP SQL Injection Prevention Cheat Sheet

Document databases such as MongoDB have their own injection risks, often through operators passed in JSON or query strings. The principles match SQL injection: never let input change query structure.

• Explain how NoSQL operator injection works
• Identify inputs that reach database queries
• Recommend input typing and validation as defences

Tools & tech: Web

• PortSwigger — NoSQL injection

Cross-site scripting lets attacker-controlled script run in another user's browser. Testers need to know reflected, stored and DOM-based variants, and developers need output encoding and a Content Security Policy.

• Distinguish reflected, stored and DOM-based XSS
• Identify the output context (HTML, attribute, JavaScript, URL)
• Recommend context-aware encoding and CSP

Tools & tech: Web

• PortSwigger — Cross-site scripting
• OWASP XSS Prevention Cheat Sheet

Cross-site request forgery tricks a logged-in user's browser into sending an unwanted request. SameSite cookies reduced the risk, but anti-CSRF tokens and correct method use still matter.

• Explain the conditions CSRF needs
• Check anti-CSRF tokens and SameSite settings
• Recommend defences for state-changing requests

Tools & tech: Web

• PortSwigger — CSRF
• OWASP CSRF Prevention Cheat Sheet

Server-side request forgery makes the server send requests to places the attacker chooses, such as internal services or cloud metadata endpoints. It is a major risk in cloud-hosted applications.

• Identify features that fetch URLs on the server
• Explain why internal and metadata endpoints are sensitive
• Recommend allow-lists and network egress controls

Tools & tech: Web

• PortSwigger — SSRF
• OWASP SSRF Prevention Cheat Sheet

File uploads are risky when the server trusts the file name, type or content. Testing checks validation, storage location and how uploaded files are served back.

• Review file type, size and name validation
• Check where and how uploaded files are stored and served
• Recommend safe upload handling

Tools & tech: Web

• PortSwigger — File upload vulnerabilities
• OWASP File Upload Cheat Sheet

Insecure deserialization happens when an application rebuilds objects from untrusted data. Depending on the language, it can lead to logic abuse or code execution. Recognising it is more important at this stage than exploiting it.

• Explain what serialization and deserialization are
• Recognise serialized data formats in requests
• Recommend avoiding native deserialization of untrusted input

Tools & tech: Web

• PortSwigger — Insecure deserialization
• OWASP Deserialization Cheat Sheet

Modern web apps are mostly APIs behind a JavaScript front end. API testing applies the same ideas (authentication, access control, input handling) to JSON endpoints, often with less protection than the UI suggests.

• Discover API endpoints used by the front end
• Test object-level and function-level authorization
• Review API documentation for exposed functionality

Tools & tech: Web

• PortSwigger — API testing
• OWASP API Security Top 10

Logic flaws come from wrong assumptions about how users will behave: skipping steps, changing prices or quantities, or repeating actions. Scanners rarely find them; understanding the business does.

• Model the intended workflow of a feature
• Look for steps that can be skipped, repeated or reordered
• Explain the business impact clearly

Tools & tech: Web

• PortSwigger — Business logic vulnerabilities

Burp Suite is the standard tool for manual web testing. An efficient workflow uses scope settings, the proxy history, Repeater and Intruder deliberately rather than clicking everything.

• Configure target scope and the browser proxy
• Use Proxy, Repeater and Intruder for focused testing
• Keep organised notes and evidence while testing

Tools & tech: Web

• PortSwigger — Burp Suite documentation

The report is the product of a penetration test. Good findings state the risk, show clear evidence, explain the impact in business terms and give developers a concrete fix.

• Structure a finding: title, severity, description, evidence, impact, remediation
• Rate severity consistently (for example with CVSS)
• Write an executive summary for non-technical readers

Tools & tech: Web

• FIRST — CVSS v4.0

Check your progress before the final step. You should be able to test a web application methodically, explain each vulnerability class and write findings developers can act on.

• Explain the top web vulnerability classes and their fixes
• Complete a full test of a training app from mapping to report
• Identify your two weakest areas

• CyberA4U CTF Arena — practice challenges

You have completed the Web Application Pentesting roadmap. Keep practising on legal platforms, work towards a recognised certification if it fits your goals, and only ever test systems you are authorised to test.

• Keep a portfolio of lab write-ups
• Choose your next specialisation (API, mobile, cloud)
• Stay current with new vulnerability research

• CyberA4U CTF Arena — practice challenges