Open betaSAMPLE — fictional data

Example Corporation — Q1 2026 Web Application Assessment

This is a fictional EvidnZ sample report intended to show the format and structure of a delivered engagement. All names, hostnames, IP addresses, and findings are invented for demonstration.

Executive summary

Example Corporation engaged an independent penetration testing team to assess its customer-facing support portal (support.example.test). Testing focused on authentication, session management, input handling, and authorization on privileged routes. The engagement identified one high-severity issue related to reflected input handling, plus several lower-severity observations covering hardening opportunities.

The high-severity finding is exploitable through a crafted URL delivered over a trusted channel and can lead to session compromise of authenticated support agents. Recommended remediations are outlined per finding and prioritized in the summary table.

Scope

Application: support.example.test (staging)
Roles tested: unauthenticated visitor, customer, support agent
Testing window: 2026-01-08 through 2026-01-19
Out of scope: production systems, third-party auth providers, denial of service

Finding 1 — Reflected XSS in support-portal search parameter

Severity:HighCVSS:7.4CWE:CWE-79Asset:https://support.example.test/search

Description

The q query parameter on the support portal search endpoint reflects user input into the rendered HTML without contextual encoding. An attacker can craft a link that executes JavaScript in the victim's session when opened from a trusted channel such as email, chat, or a ticket comment.

Business impact

An attacker who convinces an authenticated support agent to open a crafted link can hijack the agent session, exfiltrate customer information available in the agent console, and pivot to internal ticket data. The finding is directly reachable from the internet and requires no privileged access.

Attack scenario

Attacker crafts a URL containing a JavaScript payload in the q parameter.
Attacker submits the URL through a support ticket or emails it to a shared support inbox.
A support agent opens the URL from the trusted inbox.
The payload executes in the agent's authenticated session and calls back to the attacker.

Evidence

Figure 1 — Reflected payload rendered in the support search results (sensitive values redacted).

Recommendations

Contextually encode reflected values in the search results template.
Apply a strict Content Security Policy that blocks inline script execution.
Add automated regression coverage for search-endpoint input handling.
Train support agents to open external links from customer-supplied URLs in an isolated profile.

Start with EvidnZ

Turn your own evidence into structured findings and report-ready exports.

Create a free report Back to home