Reporting and Evidence

PTK can generate useful raw evidence, but the final report should explain impact, exploitability, and remediation in terms the target owner can act on.

Evidence Checklist

For each finding, collect:

• affected URL, route, endpoint, or page
• user role and authentication state
• exact request and parameter, when applicable
• payload or changed value
• response status, body excerpt, redirect, or runtime behavior
• screenshots only when they add clarity
• PTK finding details and engine
• SAST code reference or IAST source/sink evidence when relevant
• reproducible steps
• expected vs actual behavior
• remediation guidance

Redact:

• passwords
• session cookies
• JWT signatures and sensitive claims
• API keys
• personal data
• private tenant/customer identifiers

Triage Rules

Use these rules before reporting:

• Merge duplicate evidence into one finding when the root cause is the same.
• Do not inflate severity because many routes show the same weakness.
• Do not report passive/header findings without explaining application impact.
• For SCA, verify reachability and usage before assigning high severity.
• For SAST, pair risky code with runtime reachability when possible.
• For IAST, prove the source is attacker-controllable and the sink is meaningful.
• For DAST, prove the payload changed behavior in a security-relevant way.

Report Structure

Use this structure for most findings:

# [Severity] Finding title

## Summary

One or two sentences describing the weakness and affected component.

## Affected Asset

- URL:
- Endpoint:
- User role:
- Environment:

## Impact

Explain what an attacker can do and what business/security risk follows.

## Steps to Reproduce

1. Sign in as ...
2. Navigate to ...
3. Send or perform ...
4. Observe ...

## Evidence

Include request/response snippets, runtime evidence, PTK engine evidence, or code references.

## Root Cause

Explain why the issue exists.

## Recommendation

Provide specific remediation steps.

## Retest Steps

Explain how to verify the fix.

JWT Finding Template

# JWT validation weakness

## Token Location

- Header/cookie/storage:
- Affected endpoint:

## Original Claims

```json
{
  "sub": "...",
  "role": "..."
}
```

## Test Performed

Describe the changed header, claims, signature, carrier, or validation assumption.

## Result

Explain what the server accepted or rejected.

## Impact

Describe privilege, impersonation, auth bypass, or session risk.

## Recommendation

Validate signature, algorithm, issuer, audience, expiry, key source, and carrier consistently.

DOM XSS / IAST Finding Template

# DOM XSS through unsafe client-side sink

## Affected Page

- URL:
- Route:

## Source

URL/hash/storage/cookie/message/form/API response.

## Sink

Dangerous API, for example `innerHTML`, script creation, navigation assignment, or `eval`.

## Runtime Evidence

Describe PTK IAST evidence and the manual trigger.

## Impact

Explain attacker control and victim interaction.

## Recommendation

Use safe DOM APIs, contextual output encoding, sanitization, and Trusted Types where appropriate.

SCA Finding Template

# Vulnerable client-side component

## Component

- Name:
- Version:
- Loaded from:

## Affected Pages

List pages where PTK observed the component.

## Vulnerability

Reference CVE/advisory and affected feature.

## Application Impact

Explain whether the vulnerable feature is reachable in this app.

## Recommendation

Upgrade, remove, isolate, or mitigate the component.

Export Handling

When exporting PTK results:

• store artifacts outside the repository
• keep engagement artifacts separate per target/client
• encrypt sensitive evidence when required
• do not commit scan exports, browser profiles, cookies, or traces
• include only the minimum evidence needed in the final report