Common Pentest Methodology

## PTES-aligned dynamic assessment plan for a web frontend

### Scope and safety

Confirm written authorization, the target domains and environments, test accounts, permitted test window, rate limits, data-handling rules, and exclusions. Direct all dynamic probes to local or staging systems; do not test production or third-party dependencies without explicit authorization. Define whether the assessment is black-box, grey-box, or white-box, and record browser versions, authenticated roles, feature flags, and build identifiers.

### Attack-surface mapping

Create an asset inventory covering public and authenticated routes, subdomains, API origins, WebSockets, service workers, static bundles, source maps, upload/download handlers, redirects, OAuth/SSO callbacks, WebViews, admin and debug paths, and third-party integrations. Enumerate routes from the application, crawl results, browser network traces, JavaScript bundles, robots/security files, deployment configuration, and available route/API specifications. For each surface record method, parameters, authentication state, role, tenant/object scope, state-changing behavior, sensitive data, client-side sinks, and owning component. Mark unknown or untested areas rather than assuming the crawl is complete.

### Threat model and test matrix

Prioritize login, session refresh/logout, password reset and MFA; authorization boundaries; user-controlled rendering; file and URL processing; payment or workflow transitions; administrative functions; cross-origin integrations; and endpoints exposed by frontend code but absent from navigation. Test anonymous, normal-user, privileged, and revoked/expired sessions. Include error states, malformed inputs, race-prone actions, alternate HTTP methods, duplicate parameters, and direct navigation to hidden routes; happy-path crawling alone is insufficient.

### Dynamic testing

Use an intercepting proxy and browser automation to capture baseline requests and replay them with controlled changes. Test for reflected, stored, and DOM XSS by tracing untrusted data into dangerous sinks such as `innerHTML`, script URLs, event attributes, template evaluation, and unsafe framework escape bypasses. Validate impact with a harmless marker in the authorized environment. Check CSRF on state-changing requests, CORS and origin handling, clickjacking protections, cookie flags, session fixation and invalidation, cache behavior, open redirects, path traversal, upload handling, SSRF paths reachable through frontend forms, and client-only validation or role gates. Exercise every frontend-to-API call for BOLA/BFLA and mass-assignment consequences; client hiding is not authorization.

Inspect security headers and browser policy behavior, including CSP, HSTS, frame restrictions, referrer policy, MIME sniffing, and mixed content. Review source maps, bundles, local/session storage, IndexedDB, URLs, console output, and error pages for secrets, tokens, PII, debug data, or internal endpoints. Run dependency and bundle analysis, but treat scanner results as leads: correlate them with reachable code and a manual or dynamic proof. Test service-worker cache scope and logout behavior where applicable.

### Evidence and reporting standard

For each suspected issue preserve the target URL, role, preconditions, exact request or browser steps, payload, response/DOM effect, timestamps, build, and sanitized screenshots or traces. Reproduce with a baseline and a negative control. Per the no-exploit-no-report rule, discard theoretical findings that cannot be demonstrated with a repeatable PoC. Do not inflate severity from banners or scanner confidence; score confirmed impact with CVSS and explain confidentiality, integrity, availability, privileges, and user interaction.

Deliver an attack-surface map, coverage and exclusions, prioritized findings, remediation, and retest criteria. Include mappings to relevant OWASP web controls and applicable SOC 2, ISO 27001, or PCI DSS requirements. Retest each finding after remediation using the original PoC plus nearby variants and verify that the fix is enforced server-side where relevant. Close the assessment only after evidence, coverage gaps, and residual risk are documented.