Web application testing examines how browsers, APIs, servers, identities, and backend services enforce security when an attacker controls requests instead of following the intended user interface. The current CompTIA PenTest+ PT0-003 objectives include web and application techniques as part of a larger penetration-testing lifecycle. The goal is not to fire every payload at every parameter. It is to understand the application’s trust boundaries, identify where untrusted input crosses those boundaries, and test whether server-side controls continue to hold.
Modern applications are distributed. A single page may call several APIs, rely on a separate identity provider, store objects in cloud services, and execute substantial logic in the browser. That architecture means testing must include authentication state, authorization, session handling, API behavior, data flow, and business rules—not just classic injection strings. The OWASP testing model is useful because it treats application security as a structured set of questions rather than a list of famous vulnerabilities.
A professional test also preserves safety. Automated fuzzing can create thousands of requests, uploads can persist, business workflows can send real emails or payments, and test accounts can affect production data. The application-testing plan should therefore inherit clear scope, rate limits, test identities, cleanup requirements, and escalation paths from the engagement rules. Technical depth is valuable only when it remains within authorized and recoverable boundaries.
Map the application before testing controls
Begin by learning how the application is assembled. Identify hostnames, routes, APIs, authentication endpoints, static assets, administrative functions, upload areas, background jobs, and integrations visible from the client. Proxying browser traffic is often more informative than immediately fuzzing endpoints because it reveals normal request structures, tokens, cookies, headers, and sequence dependencies. Record which components are customer-owned and which belong to third parties.
Then build a state model. What can an unauthenticated user see? What changes after login? Which roles exist? Which objects belong to each user or tenant? Which actions alter server-side state? This model becomes the basis for authorization and workflow tests. It also prevents the tester from confusing a client-side restriction with a server-side security decision. The site’s application security practices provide useful defensive context for the controls the test is trying to validate.
Architecture mapping should include trust boundaries inside the application, not just network components. A browser may talk to an API gateway that forwards to several services, while background jobs process queued requests with different credentials. Draw these boundaries because vulnerabilities often arise when one tier assumes another has already validated input or authorization.
Test authentication separately from authorization
Authentication proves or asserts who the user is; authorization decides what that identity may do. A login flow can be technically strong while the application exposes another customer’s records through predictable identifiers. Test account creation, login, logout, password reset, multi-factor behavior, token lifetime, session invalidation, and error handling, but do not stop there. After each role is authenticated, verify every sensitive action on the server side.
Authorization testing should change object identifiers, role context, HTTP methods, API paths, and sequence assumptions to see whether the server consistently enforces ownership and privilege. Do not assume that hiding a button protects the underlying endpoint. Horizontal access issues involve crossing between peer users or tenants; vertical issues involve gaining functions reserved for a more privileged role. The report should state the exact trust boundary that failed.
Authentication testing should include recovery and enrollment because those workflows can be weaker than normal login. Password reset links, MFA enrollment, device registration, invitation flows, and account activation frequently create alternate paths into an identity. Test whether an attacker can redirect, replay, guess, or misuse those transitions within the authorized scope.
Examine session and token behavior
Sessions connect individual requests into an authenticated context. Test whether session identifiers are protected in transit, invalidated on logout or credential reset where appropriate, rotated after privilege changes, and constrained by reasonable lifetime. For token-based APIs, inspect claims, audience and issuer expectations, expiration, signature validation, and whether the server accepts tokens intended for a different context. The tester should understand what each token represents before attempting manipulation.
Client storage is part of the picture but not the whole security model. A secure cookie flag, local-storage choice, or token format can matter, yet the decisive control is usually server-side validation. If an application trusts client-supplied roles, account identifiers, or pricing data without authoritative verification, the problem is deeper than where the token is stored. Test the trust decision, not just the syntax of the credential.
Session testing should consider concurrent use and revocation. If a user changes a password, removes a device, or loses a role, determine whether existing sessions continue to hold old privilege. Long-lived API tokens can outlast browser sessions and create a different risk window. Report the effective lifetime of access, not merely the configured token expiration field.
Validate input handling at the server boundary
Injection flaws occur when untrusted data is interpreted as part of a command, query, expression, template, or protocol instead of as data. Testing should cover parameters in URLs, forms, JSON bodies, headers, cookies, file metadata, and API fields that reach interpreters or backend services. Use safe proof techniques that demonstrate altered behavior without destroying data. Where possible, compare expected and unexpected input and observe how the server handles types, delimiters, encoding, and error conditions.
Input validation and output encoding solve different problems. Server-side validation can enforce format and business constraints; parameterized queries prevent data from becoming database syntax; context-aware output encoding helps prevent browser interpretation of untrusted content. A tester should identify which boundary failed rather than recommending generic “sanitize input” language. The more precisely the report names the context, the easier it is for developers to fix the right control.
Input testing should include structure as well as content. APIs may accept duplicate keys, unexpected arrays, oversized numbers, null values, alternate encodings, or nested objects that bypass client validation. The objective is not to crash the parser. It is to determine whether server-side assumptions remain valid when a client sends legal protocol messages in an unexpected shape.
Test browser-facing output and client-side trust
Cross-site scripting and related browser issues arise when attacker-controlled content reaches an execution context without correct encoding or policy. Test reflected, stored, and DOM-driven data paths where they exist, but remember that the browser may transform inputs or execute client-side templates in ways not visible from the server response alone. Developer tools and an intercepting proxy help trace where data is introduced and where it is consumed.
Client-side controls should be treated as convenience unless the server enforces the same rule. Disabled form fields, hidden inputs, JavaScript validation, and route guards can all be altered by a user who controls the browser. Manipulate requests directly to determine whether sensitive values, prices, workflow states, or role decisions are trusted from the client. A secure application assumes the client can be hostile and validates critical decisions on the server.
Browser security also depends on origin boundaries, content security policy, CORS behavior, and cookie scope. These controls should be interpreted in context rather than checked as isolated headers. A permissive CORS policy is dangerous when sensitive authenticated responses are readable cross-origin, while the same header on a public static resource may have little consequence.
Evaluate file handling, parsers, and backend fetches
File upload features introduce multiple risks: extension checks that can be bypassed, executable content stored in reachable locations, oversized files, malicious document formats, path traversal in filenames, and parser vulnerabilities. Safe testing should use controlled files designed to prove validation behavior without introducing harmful payloads. Determine where files are stored, how they are renamed, how content type is determined, and whether uploaded content is served under an origin where script execution matters.
Features that fetch remote URLs can create server-side request forgery risks because the server has network access the client does not. Test allowlists, URL parsing, redirects, protocol restrictions, and access to metadata or internal services only within approved boundaries. Similar reasoning applies to XML parsers, template engines, archive extraction, and image processors: the security question is what authority the backend gains when it processes attacker-influenced content.
File-processing tests should include cleanup verification. An uploaded test file may be copied into object storage, cached by a CDN, converted by a worker, or indexed by another service. The tester should understand where artifacts propagate and confirm that the agreed cleanup removes all meaningful copies. This is especially important when filenames or content contain distinctive test markers.
Treat APIs as first-class attack surfaces
APIs often expose the application’s real business operations more directly than the browser. Inventory endpoints, methods, parameters, object identifiers, authentication requirements, pagination, filters, and rate behavior. Compare documented behavior with observed traffic and look for forgotten versions or alternate routes. Test authorization on every operation because an API may correctly protect the web interface while exposing the same data through a less carefully implemented endpoint.
Automation is useful for repetitive API tests, but it should not replace understanding. Generic fuzzing can miss business logic such as approving your own transaction, reusing a one-time operation, changing another tenant’s object through a batch endpoint, or bypassing workflow order. The most valuable API findings often come from modeling how the application is supposed to enforce state and then deliberately violating those assumptions.
API testing should also consider mass assignment and over-posting. A client may submit fields the interface never exposes, such as role, owner, status, discount, or tenant identifier. Servers should accept only fields appropriate to that operation and identity. Observing the API schema and experimenting with extra fields can reveal authorization gaps that ordinary UI testing misses.
Use tools to amplify reasoning, not substitute for it
Intercepting proxies, crawlers, scanners, command-line clients, browser developer tools, and exploit frameworks each answer different questions. The site’s penetration-testing toolset helps orient common choices, while Kali Linux tools provide convenient packaging. A tester should know the request each tool generates and validate important results manually.
Frameworks such as Metasploit can be valuable when a validated application or server condition maps to an appropriate module, but exploit execution should follow scope and safety controls. The test is not a competition to use the most tools. Select the smallest technique that can prove the security consequence and preserve enough evidence for a developer or administrator to reproduce it safely.
Tool output requires validation because scanners often infer vulnerabilities from versions, error messages, or response patterns. Reproduce high-impact results manually and capture the exact request that proves the condition. If a framework exploit succeeds, determine which prerequisite made it possible. That analysis produces a remediation path; the fact that a module returned a shell is only the demonstration.
Finish with business logic, cleanup, and retesting
Business-logic testing asks whether a user can make the application do something the designers did not intend even when every request is syntactically valid. Examples include skipping approval, reusing discounts, creating negative quantities, racing a transaction, changing workflow order, or combining permissions in an unintended way. These flaws are difficult for generic scanners because they depend on understanding the application’s purpose and state transitions.
At closeout, remove test records, temporary files, accounts, tokens, and any server-side artifacts created during the assessment as agreed in the rules of engagement. Report findings with reproducible evidence and remediation tied to the failed control. When fixes are available, retest the original path and nearby variants to confirm the root cause was addressed rather than one payload being blocked. Web application security improves when testing produces engineering feedback that survives beyond the specific exploit used to demonstrate it.
Business-logic retesting should use the original workflow plus reasonable variants. If a fix adds one client-side check, bypass it. If a server validates one transition, attempt the same action through another API route or role. The goal is to verify that the business rule now exists at the authoritative boundary. Secure applications enforce invariants consistently, not only on the path a tester originally used.
