Skip to content
Talk to a Security Expert
WEB APPLICATION PENTESTOFFENSIVE SECURITYSAMPLE REPORT

Web Application Penetration Testing Report — Sample

Web Application Penetration Testing Report — Illustrative Sample. A fictional authenticated web application penetration test of the NorthStar Commerce Portal, a fictional e-commerce/SaaS platform for NorthStar Digital Commerce, Inc., showing how TMG Security structures scope, methodology, attack-surface mapping, findings, risk analysis, and remediation guidance for a web application penetration test.

Illustrative Sample Fictional Organization Not an Actual Client Assessment

NorthStar Digital Commerce, Inc. and the NorthStar Commerce Portal are fictional. No real production system was built, deployed, accessed, scanned, or tested, and no real client environment or customer data was involved in the creation of this document.

01 · OVERVIEW

Overview

A web application penetration test is an authorized, hands-on security assessment in which testers actively attempt to identify and validate exploitable weaknesses in a web application's authentication, authorization, business logic, API, and infrastructure-adjacent surfaces — going beyond automated vulnerability scanning to manually confirm which weaknesses are real, how they can be chained together, and what they mean for the business. The result is a report that gives engineering and security leadership a prioritized, evidence-based roadmap for remediation.

This sample report shows how TMG Security structures that deliverable. It is built around the NorthStar Commerce Portal, a fictional web application operated by NorthStar Digital Commerce, Inc., a fictional e-commerce, SaaS, and digital-payments organization headquartered in Austin, Texas, and covers a simulated one-month assessment window of 01–31 August 2026.

Assessment TypeWeb Application Penetration Test (Illustrative)
Assessment Period01 August – 31 August 2026 (Fictional)
Report Date10 September 2026 (Fictional)
ClassificationConfidential — Sample / Demonstration
OrganizationNorthStar Digital Commerce, Inc. (Fictional Entity)
ApplicationNorthStar Commerce Portal (Fictional)
Industry / HQE-Commerce / SaaS / Digital Payments · Austin, TX, USA
Overall Illustrative PostureRequires Remediation
02 · WHAT THIS SAMPLE DEMONSTRATES

What this sample demonstrates

NorthStar Digital Commerce, Inc. and the NorthStar Commerce Portal do not exist. Every finding, test case, endpoint, and figure in this sample is fictional and constructed to show TMG's methodology and reporting standard for a web application penetration test — not to describe any real organization's security posture.

  • How TMG defines scope, rules of engagement, and testing objectives before testing begins
  • How the application's attack surface is mapped across authentication, authorization, API, and workflow layers
  • How authentication, session management, authorization, and business-logic testing are performed and documented
  • How API security, file handling, webhook validation, and server-side controls are assessed
  • How findings are rated for severity, evidenced, and root-caused with clear remediation guidance
  • How a composite attack-chain scenario and business-impact analysis connect individual findings to real-world risk
  • How a remediation roadmap, management action plan, and retest recommendations are structured for engineering follow-through
  • The full appendix structure — test case register, endpoint register, finding register, and test account register — that supports a real engagement
03 · APPLICATION PROFILE

Application profile

The fictional NorthStar Commerce Portal is a multi-tenant e-commerce and subscription-billing platform serving approximately 1.8 million fictional registered users across roughly 650 fictional employees' worth of operations. It supports account registration and login with MFA, password reset and account recovery, user and organization profile management, role management, invoicing and subscription management, file uploads for support and billing attachments, support ticketing, in-app notifications, API integrations, and outbound webhooks — accessed through six fictional user roles: Unauthenticated Visitor, Standard User, Billing User, Organization Manager, Support Agent, and Administrator.

The fictional technology stack pairs a React/TypeScript front end with a Node.js/Express API, a PostgreSQL database, and a JWT access-token plus rotating refresh-token authentication architecture, deployed on an AWS-style fictional cloud environment behind a fictional cloud-based CDN/WAF, with fictional object storage and a Git-based CI/CD pipeline.

Registered Users~1.8 million (Fictional)
Employees~650 (Fictional)
Frontend / BackendReact/TypeScript · Node.js/Express
DatabasePostgreSQL (Fictional)
AuthenticationJWT access token + rotating refresh token
InfrastructureAWS-style cloud + CDN/WAF (Fictional)
04 · TESTING SCOPE & RULES OF ENGAGEMENT

Testing scope & rules of engagement

In scope

  • Web application front end and supporting API (all /api/v1/* endpoints)
  • Authentication, MFA, session issuance, and account recovery
  • Authorization — role enforcement, object- and function-level access control
  • Organization management, member management, and role assignment
  • Billing and subscription workflows, including plan changes and discount redemption
  • File upload and download workflows for support and invoice attachments
  • Support tickets, in-app notifications, and outbound webhooks

Out of scope

  • Denial-of-service testing and destructive testing — not performed under any circumstances
  • Social engineering and physical security
  • Production infrastructure and third-party or cloud-provider internals — testing restricted to the fictional staging environment

Testing was strictly non-destructive and used only dedicated fictional test accounts (Appendix D of the full report) — no real user accounts or customer data were used at any point. No persistence mechanisms or backdoors were established, automated testing respected reasonable rate limits, and no real customer data was accessed, used, or referenced during the engagement.

05 · METHODOLOGY

Methodology

TMG Security's testing approach is conceptually informed by industry-recognized frameworks, including the OWASP Web Security Testing Guide, the OWASP Top 10, and the OWASP API Security Top 10. TMG Security is not affiliated with or certified by OWASP, and no copyrighted material from these references is reproduced in this report — they are cited only as conceptual grounding for TMG's own methodology.

Testing followed a 20-stage illustrative lifecycle: reconnaissance and attack-surface mapping, application enumeration, authentication and authorization testing, session-management review, input validation and injection testing, business-logic analysis, file-handling review, API testing, configuration and client/server-side testing, abuse-case testing, manual vulnerability validation, illustrative risk scoring, structured reporting, remediation guidance, and retest recommendations. Every candidate finding was manually validated by a TMG Security fictional tester before inclusion — no automated-scanner output was included without manual confirmation.

06 · ATTACK SURFACE MAPPING

Attack surface mapping

TMG Security mapped the fictional application's attack surface across six functional groups — authentication & recovery, organization & members, billing & subscriptions, files & support, API & webhooks, and admin & docs — before beginning role-based testing. The full register documents all 34 fictional endpoints identified, each tested for authentication requirement, role, and result.

Representative fictional endpoints — full 34-endpoint register in the sample PDF, Appendix B.
EndpointMethodRoleResult
/api/v1/organizations/{orgId}/profileGET/PATCHOrg ManagerFinding
/api/v1/billing/subscriptions/{subId}/planPOSTBilling UserFinding
/api/v1/organizations/{orgId}/members/{userId}/rolePATCHOrg ManagerFinding
/api/v1/files/{fileId}/downloadGETStandard UserFinding
/api/v1/webhooks/validatePOSTOrg ManagerFinding
/api/v1/organizations/{orgId}/membersGETStandard UserFinding
/profileGET/PATCHStandard UserClean
/adminGETAdministratorClean
07 · AUTHENTICATION, SESSION & ACCOUNT SECURITY TESTING

Authentication, session & account security testing

TMG Security tested login, MFA, session issuance and revocation, password reset, and account-recovery workflows. Core authentication behavior was found sound: login rejects invalid credentials generically, account lockout and throttling were adequate, password complexity is enforced server-side, and MFA — including recovery-code handling and remembered-device duration — was adequate for privileged roles. Two areas required attention: refresh-token rotation and cookie attributes were implemented soundly, but access tokens remained valid for their full lifetime after logout rather than being actively revoked, and the account-recovery workflow's email-change confirmation step was not bound to its originating request, allowing an authenticated low-privilege session to complete an email change intended for a different pending request.

TMG-WAPT-004 · HIGH · CWE-640 Weak Password Recovery Mechanism

Account Recovery Workflow Allows Unauthorized Email Change

The email-change confirmation endpoint accepted a confirmation code generated for one pending change request when submitted against a second, unrelated pending request on the same fictional test account — because validation checked only that the code was currently valid, not that it matched the specific change request it was issued for. Recommendation: bind each confirmation code to its originating change-request ID and invalidate superseded pending requests when a new one is created.

CVSS-style: 7.9 (High) · Owner: Identity & Access Lead · Target: 24 Oct 2026 · Status: Open

08 · AUTHORIZATION & ACCESS CONTROL TESTING

Authorization & access control testing

Authorization testing was the most significant category in this fictional assessment, covering horizontal and vertical privilege escalation and server-side enforcement of role boundaries across all six fictional roles. Testing produced the assessment's most significant result: a Critical cross-tenant object-level authorization gap in the organization-profile endpoint, and a High-severity self-role-elevation path from Standard User to Organization Manager. A related file-download authorization bypass and an excessive API data-exposure finding follow the same underlying pattern — authorization enforced at the "is authenticated" level rather than the "is this specific action authorized for this specific requester" level.

TMG-WAPT-001 · CRITICAL · CVSS-style 9.1 · CWE-639 Authorization Bypass Through User-Controlled Key

Broken Object-Level Authorization Leading to Cross-Tenant Customer Data Access

The organization-profile API endpoint (GET /api/v1/organizations/{orgId}/profile) accepted an org identifier supplied directly in the request path and returned that organization's fictional profile, member count, and billing contact without verifying the requesting user's session was associated with that organization. A fictional Standard User from one test tenant was able to retrieve another, unrelated tenant's profile data by substituting the organization identifier. Recommendation: enforce server-side tenant-scoping on every organization-scoped endpoint, derived from the authenticated session rather than the client-supplied path parameter, with automated authorization regression tests for all object-level endpoints.

Owner: VP Engineering (Fictional Role) · Target: 10 Oct 2026 · Status: Remediation In Progress

TMG-WAPT-006 · HIGH · CVSS-style 7.6 · CWE-269 Improper Privilege Management

Privilege Escalation from Standard User to Organization Manager

The member-role-update endpoint checked that the requesting user belonged to the organization but did not verify the requester was authorized to grant the requested target role — a fictional Standard User account successfully updated its own role to Organization Manager. Recommendation: add explicit requester-role authorization to the role-update handler and disallow self-targeted role changes entirely.

Owner: Identity & Access Lead (Fictional Role) · Target: 24 Oct 2026 · Status: Remediation In Progress

09 · INPUT VALIDATION, INJECTION & BUSINESS LOGIC TESTING

Input validation, injection & business logic testing

TMG Security submitted safe, illustrative payloads representative of SQL/NoSQL injection, command injection, template injection, path traversal, and cross-site scripting across the fictional application. Parameterized data access was consistently applied — no injection-class weakness was identified beyond one High-severity stored XSS finding in the support-ticket comment workflow, where output encoding was applied inconsistently between the customer-facing and internal Support Agent rendering paths.

Business-logic testing examined multi-step workflows — subscription changes, discount redemption, invoice state transitions, and account-ownership changes — for state-manipulation weaknesses. This category produced the assessment's second Critical finding: a subscription plan-tier escalation that bypasses the expected server-side payment-authorization step, because the plan-change handler trusted a client-supplied "payment authorized" flag instead of deriving that state from the payments subsystem. A related Medium-severity replay condition was also confirmed in the discount-redemption workflow, where a narrow validation window allowed a single-use code to be redeemed twice.

TMG-WAPT-002 · CRITICAL · CVSS-style 9.0 · CWE-840 Business Logic Errors

Business Logic Authorization Bypass Allowing Unauthorized Subscription Privilege Escalation

The subscription plan-change endpoint (POST /api/v1/billing/subscriptions/{subId}/plan) accepted a client-supplied target plan tier and a client-supplied payment_authorized boolean, and applied the upgrade without independently verifying payment authorization server-side. A fictional Billing User account escalated a test organization's subscription from Standard to Enterprise without a corresponding payment-authorization event. Recommendation: remove client-controllable authorization fields from the request and require the plan-change handler to call the internal billing/payment verification service before gating any entitlement change.

Owner: Director, Billing Platform (Fictional Role) · Target: 10 Oct 2026 · Status: Remediation In Progress

10 · API, WEBHOOK & SERVER-SIDE SECURITY TESTING

API, webhook & server-side security testing

Because the fictional NorthStar Commerce Portal is API-driven, TMG Security applied dedicated API-security testing conceptually informed by the OWASP API Security Top 10 — object- and function-level authorization, excessive data exposure, mass assignment, and rate limiting — without reproducing copyrighted category text. Testing confirmed excessive data exposure on the organization-members endpoint and mass assignment in the organization-profile update endpoint, alongside object- and function-level authorization gaps already detailed above.

The webhook-validation feature — the application's only server-side URL-fetching functionality — was assessed for server-side request forgery (SSRF) exposure using only safe, attacker-controlled test endpoints; no internal network range or cloud metadata endpoint was targeted. A High-severity SSRF-class weakness was confirmed: the fictional server issued an outbound request to an attacker-controlled test endpoint with no observed destination restriction. Webhook signature validation was present but did not incorporate a timestamp or nonce, allowing a captured payload to pass validation again on replay. Defense-in-depth gaps were also identified in CORS configuration (an overly broad origin allow-list), missing Content-Security-Policy and inconsistent frame protection, and several lower-severity configuration and header-hardening items detailed in the full finding register.

TMG-WAPT-005 · HIGH · CVSS-style 8.1 · CWE-918 Server-Side Request Forgery (SSRF)

Server-Side Request Forgery in Webhook Validation Feature

The webhook "validate" endpoint (POST /api/v1/webhooks/validate) performs a server-side test request to a customer-supplied callback URL without restricting the destination beyond basic URL-format validation. The fictional server was observed issuing an outbound request to an attacker-controlled observer endpoint, confirming the server performs the fetch itself rather than only validating URL syntax, with no destination allow-listing, DNS-resolution restriction, or private-IP-range blocking observed. Recommendation: implement an egress allow-list and explicit blocklist for private/link-local/metadata IP ranges on all server-initiated outbound fetches.

Owner: Platform Security Lead (Fictional Role) · Target: 24 Oct 2026 · Status: Remediation Planned

11 · FILE HANDLING, CLIENT-SIDE SECURITY & DATA EXPOSURE

File handling, client-side security & data exposure

File-upload testing found that server-side content-type validation was insufficient — a fictional test file with a mismatched extension and declared MIME type was accepted — while filename sanitization and storage-location controls were adequate. Download authorization, covered under Access Control above, showed the same missing-ownership-check pattern found in the Critical cross-tenant finding: a file belonging to one fictional tenant was downloadable using a session authenticated to another. Client-side review of the front-end bundle found no DOM-based XSS or exposed production source maps, though residual debug logging was present on a subset of pages. Error-handling review found several endpoints returned verbose exception detail, including internal file paths, on malformed input, rather than a generic client-facing error envelope.

TMG-WAPT-008 · HIGH · CVSS-style 7.1 · CWE-862 Missing Authorization

File Download Authorization Bypass

The file-download endpoint (GET /api/v1/files/{fileId}/download) issues a signed object-storage URL based solely on file-ID existence, without confirming the requesting user's organization owns the referenced file. A fictional file belonging to one test tenant was downloadable using a session authenticated to a different tenant. Recommendation: add a mandatory file-to-organization ownership check before signed-URL issuance across all file-serving endpoints.

Owner: Platform Security Lead (Fictional Role) · Target: 23 Nov 2026 · Status: Open

12 · FINDINGS SUMMARY

Findings summary

This fictional assessment identified 32 illustrative findings across the NorthStar Commerce Portal, drawn from 87 fictional test cases executed against 34 fictional endpoints (Appendices A–C of the full report). Every finding, severity rating, and evidence reference below is fictional and specific to this web application penetration test — none are drawn from any other TMG sample report.

2
Critical
6
High
9
Medium
7
Low
8
Informational
Full illustrative finding register — fictional sample data, Appendix C of the sample PDF.
IDTitleSeverity
TMG-WAPT-001Broken Object-Level Authorization Leading to Cross-Tenant Customer Data AccessCritical
TMG-WAPT-002Business Logic Authorization Bypass Allowing Unauthorized Subscription Privilege EscalationCritical
TMG-WAPT-003Stored Cross-Site Scripting in Customer Support WorkflowHigh
TMG-WAPT-004Account Recovery Workflow Allows Unauthorized Email ChangeHigh
TMG-WAPT-005Server-Side Request Forgery in Webhook Validation FeatureHigh
TMG-WAPT-006Privilege Escalation from Standard User to Organization ManagerHigh
TMG-WAPT-007Excessive API Data Exposure Through Organization EndpointHigh
TMG-WAPT-008File Download Authorization BypassHigh
TMG-WAPT-009Insufficient Rate Limiting on Password Reset EndpointMedium
TMG-WAPT-010JWT / Session Revocation WeaknessMedium
TMG-WAPT-011CORS Trusts Unnecessary OriginsMedium
TMG-WAPT-012Verbose Error Messages Reveal Internal Application DetailsMedium
TMG-WAPT-013Missing Security Header DefenseMedium
TMG-WAPT-014Mass Assignment in Organization Profile UpdateMedium
TMG-WAPT-015Webhook Replay Protection MissingMedium
TMG-WAPT-016Insufficient File ValidationMedium
TMG-WAPT-017Business Logic Replay in Discount WorkflowMedium
TMG-WAPT-018Technology Version DisclosureLow
TMG-WAPT-019Verbose Validation ResponseLow
TMG-WAPT-020Missing Referrer-Policy HardeningLow
TMG-WAPT-021Unnecessary Client-Side Debug LoggingLow
TMG-WAPT-022Logout Does Not Immediately Clear One Non-Privileged Local Session ArtifactLow
TMG-WAPT-023Password Policy Documentation InconsistencyLow
TMG-WAPT-024Security Configuration Hardening OpportunityLow
TMG-WAPT-025Security.txt Not PresentInformational
TMG-WAPT-026API Documentation Exposure — Intended but ReviewableInformational
TMG-WAPT-027Detailed Technology FingerprintingInformational
TMG-WAPT-028Unused Security Response Header OpportunityInformational
TMG-WAPT-029Exposed Non-Sensitive Build MetadataInformational
TMG-WAPT-030Session Management Documentation ImprovementInformational
TMG-WAPT-031Security Monitoring Enhancement OpportunityInformational
TMG-WAPT-032Defense-in-Depth Recommendation for Sensitive WorkflowsInformational
13 · RISK HEATMAP & ATTACK CHAIN ANALYSIS

Risk heatmap & attack chain analysis

The full sample PDF plots all 32 fictional findings on a likelihood-versus-impact risk heatmap: the two Critical and six High findings cluster in the "Likely/Almost Certain × Major/Severe" quadrant, the nine Medium findings sit in the mid-range "Possible × Major" band, and the Low findings cluster toward "Rare/Unlikely × Minor" — a distribution that supports prioritizing the authorization and business-logic findings first.

Individual findings are often most meaningful in combination. The report's fictional composite attack-chain scenario illustrates how, starting from a low-privilege authenticated Standard User session, the cross-tenant authorization weakness (TMG-WAPT-001) permits access to another organization's profile object; the excessive API data-exposure finding (TMG-WAPT-007) means that object — and equivalent objects reachable the same way — returns more internal detail than intended; and the business-logic replay weakness in the discount-redemption workflow (TMG-WAPT-017) shows that workflow-state enforcement has gaps elsewhere in the platform. Combined, an attacker following this fictional path could reach cross-tenant data exposure together with a business-logic abuse pattern — a composite illustrative impact more significant than any single finding in isolation. This is a fictional composite scenario and must not be construed as an exploit chain against any real system.

14 · BUSINESS IMPACT ANALYSIS

Business impact analysis

The table below maps each Critical and High fictional finding to the illustrative business dimensions it most directly affects, supporting prioritization conversations beyond pure technical severity.

Illustrative business impact by finding — Critical & High findings only, fictional sample data.
FindingConfidentialityIntegrityFraud / Revenue RiskCustomer Trust
TMG-WAPT-001HighLowMediumHigh
TMG-WAPT-002LowHighHighMedium
TMG-WAPT-003MediumMediumLowMedium
TMG-WAPT-004MediumHighMediumHigh
TMG-WAPT-005MediumLowLowMedium
TMG-WAPT-006HighHighMediumHigh
TMG-WAPT-007MediumLowLowMedium
TMG-WAPT-008MediumLowLowMedium
15 · REMEDIATION ROADMAP

Remediation roadmap

The fictional sample remediation roadmap sequences all 32 findings across three phases, prioritizing the Critical and High authorization findings first. All dates and timelines shown are illustrative.

0–30 days

  • Remediate both Critical authorization findings (TMG-WAPT-001, TMG-WAPT-002)
  • Close the self-role-elevation privilege-escalation path (TMG-WAPT-006)
  • Bind account-recovery confirmation codes to their originating request (TMG-WAPT-004)
  • Implement egress restrictions for the webhook SSRF finding (TMG-WAPT-005)
  • Fix stored XSS in the support workflow (TMG-WAPT-003)

31–60 days

  • Close the business-logic replay finding in the discount workflow (TMG-WAPT-017)
  • Introduce role-aware API serialization and file-ownership checks (TMG-WAPT-007, TMG-WAPT-008, TMG-WAPT-014)
  • Add rate limiting on password reset and a short-TTL session-revocation check (TMG-WAPT-009, TMG-WAPT-010)
  • Add webhook replay protection and server-side file-content validation (TMG-WAPT-015, TMG-WAPT-016)
  • Tighten CORS allow-list and error-handling/security-header coverage (TMG-WAPT-011, TMG-WAPT-012, TMG-WAPT-013)

61–90 days

  • Complete low-risk configuration hardening (TMG-WAPT-018, TMG-WAPT-020, TMG-WAPT-023, TMG-WAPT-024)
  • Finish the security-header baseline and residual client-side debug-logging cleanup (TMG-WAPT-019, TMG-WAPT-021, TMG-WAPT-022)
  • Work through the remaining monitoring and documentation enhancements (TMG-WAPT-025 through TMG-WAPT-032)
16 · MANAGEMENT ACTION PLAN & RETEST RECOMMENDATIONS

Management action plan & retest recommendations

The full sample PDF tracks fictional management response, ownership, and validation approach for every finding in a single management action plan, ensuring each of the 32 findings appears exactly once with an owner, priority, target date, status, and validation method. TMG Security recommends a structured retest following remediation: a full retest of both Critical findings and all six High findings, including regression testing across related endpoints; a targeted retest of each Medium finding against its specific affected endpoint or workflow; and a confirmation-only review of Low and Informational items, batched into the next general assessment cycle. This retest methodology is illustrative — this report does not claim that any finding has been remediated or retested.

17 · POSITIVE SECURITY CONTROLS & TESTING LIMITATIONS

Positive security controls & testing limitations

This fictional assessment is not intended to be entirely negative. TMG Security identified a number of controls operating effectively across the NorthStar Commerce Portal, including functional MFA with single-use recovery codes for privileged roles, appropriate refresh-token rotation and access-token lifetimes, modern password hashing, centralized security logging and monitoring, a baseline cloud-based WAF, effective login-endpoint rate limiting, disallowed deprecated TLS protocols and weak cipher suites, and a documented fictional periodic access-review process for administrator-level accounts.

The following limitations apply to this fictional sample assessment: NorthStar Digital Commerce, Inc. and NorthStar Commerce Portal are fictional and no real organization or application was assessed; no real credentials, cloud credentials, or production systems were used or accessed; no real customer data was accessed at any point; no destructive testing, denial-of-service testing, social engineering, or physical security testing was performed; no real cloud-provider environment or third-party systems were tested; and all evidence, screenshots, and request/response examples referenced in the full report are synthetic.

18 · IMPORTANT DISCLAIMER
Illustrative Sample — Not an Actual Client Penetration Test

NorthStar Digital Commerce, Inc. and the NorthStar Commerce Portal are fictional. They do not correspond to any real business or application, and any resemblance to an actual organization is purely coincidental. The application URL referenced throughout this sample, portal.northstar-example.com, is a fictional, non-resolving placeholder.

No real production system was built, deployed, accessed, scanned, or tested in the creation of this document. No real client environment was engaged, and no real user data, PII, or customer records were accessed. No real credentials were used or disclosed at any point.

All vulnerabilities, findings, risk ratings, dates, and remediation statuses in this report are fictional. All proofs of concept are illustrative, synthetic, and non-destructive — none were executed against a real or live target — and all screenshots and request/response examples referenced in the full report are synthetic. No real exploitation occurred, and no real customer impact occurred.

This document is not an actual client penetration test. It does not represent evidence of the security posture of any real organization, does not constitute a certification or compliance decision, and does not constitute security, legal, or compliance advice for any real system. It may be shared with prospective clients to illustrate TMG Security's methodology and reporting standard, and should not be relied upon for compliance, legal, contractual, or procurement decisions.

19 · FREQUENTLY ASKED QUESTIONS

Frequently asked questions

What is a web application penetration test?+

A web application penetration test is an authorized, hands-on security assessment in which testers actively attempt to identify and manually validate exploitable weaknesses in a web application's authentication, authorization, business logic, API, and infrastructure-adjacent surfaces — going beyond automated vulnerability scanning to confirm which weaknesses are real and what they mean for the business.

What does a web application penetration testing report contain?+

A thorough web application penetration testing report typically includes an executive summary, defined scope and rules of engagement, a methodology overview, an attack-surface map, detailed findings with severity ratings and evidence, a risk heatmap, business-impact analysis, a remediation roadmap, and appendices such as a test case register and endpoint register. This sample report demonstrates that full structure for the fictional NorthStar Commerce Portal.

What does a web application penetration test assess?+

A web application penetration test assesses authentication and session management, authorization and access control, input validation and injection resistance, business logic, file handling, API security, server- and client-side configuration, and abuse-case resilience — testing how the application behaves under adversarial, authenticated, and unauthenticated conditions across every defined user role.

What vulnerabilities are commonly assessed during a web application penetration test?+

Common categories include broken object- and function-level authorization, business-logic bypasses, cross-site scripting, server-side request forgery, insecure file handling, excessive API data exposure, mass assignment, session-management weaknesses, and security misconfiguration — the same categories illustrated by the fictional findings in this sample.

What is the difference between vulnerability scanning and a web application penetration test?+

Vulnerability scanning uses automated tools to identify known signatures and misconfigurations at speed and scale, but it does not validate exploitability or understand business logic. A web application penetration test adds manual, authenticated, role-based testing and human validation of every candidate finding — including business-logic and multi-step workflow abuse that automated scanning generally cannot detect.

Is this an actual client penetration testing report?+

No. This is a fictional, illustrative sample report created to demonstrate TMG Security's reporting methodology and technical depth. NorthStar Digital Commerce, Inc. and the NorthStar Commerce Portal are fictional, and no real environment was tested.

How are penetration-testing findings prioritized?+

Findings are prioritized primarily by severity — reflecting exploitability, privileges required, and technical and business impact — then sequenced into a remediation roadmap, typically addressing Critical and High findings first, Medium findings as defense-in-depth follow-up, and Low/Informational items as longer-term hardening, as illustrated in this sample's roadmap.

20 · VIEW FULL SAMPLE PDF

View the full sample PDF

The complete 60-page illustrative report, including the full methodology, attack-surface map, all 32 detailed findings with evidence panels, the risk heatmap, attack-chain analysis, remediation roadmap, and every appendix — test case register, endpoint register, finding register, and test account register.

NorthStar Digital Commerce, Inc. Web Application Penetration Testing Report — Sample.pdf
WEB APPLICATION / PENETRATION TESTING REPORT · NorthStar Commerce Portal · 60 Pages · Illustrative Sample
21 · REQUEST A SIMILAR ASSESSMENT

Request a similar assessment

Looking to validate your own web application's authentication, authorization, and business-logic security? TMG Security's Web Application Security Testing team can scope a real web application penetration test built with the same structure, methodology, and reporting depth shown in this sample — attack-surface mapping, authenticated role-based testing, manual vulnerability validation, a full finding register, and a remediation roadmap your engineering team can execute against. TMG's offensive security practice also covers API Security Testing and the broader Offensive Security & Penetration Testing program this assessment type sits within. For a conceptual reference on common testing categories, see TMG's OWASP Top 10:2025 quick reference for penetration testers.