Sample security report

See what an actionable finding looks like.

A useful report connects the issue, its impact, and the work needed to fix it. This fictional example shows the structure without using customer data.

Discuss a review

GK Data / illustrative security review record

Tenant boundary review

Controlled example / billing-api.example.test

Fictional specimen
Scope
One fictional API
Finding
Tenant access control
Severity
Illustrative / High
Status
Retest example

F-01 / controlled example

Tenant object lookup does not enforce the current organization context.

Controlled records only. No payload, token, or live system detail is shown.

Evidence chain

  1. 01 Expected organization-bound lookup
  2. 02 Controlled cross-tenant record result
  3. 03 Bounded impact and remediation direction
Expected → observed → impact → remediation → retestEvidence minimized

Fictional interface model

Show the control that failed, then the evidence needed to fix it.The visual represents a report layout. It is not a report download and contains no real assessment data.

Important context

Every name, system, account, and result below is fictional.

This specimen explains report structure. It is not customer work or evidence about a live system.

NamespaceReserved .test examples

The sample uses the reserved .test namespace and controlled accounts to explain structure without referring to a customer or live target.

Delivered reportsTied to one engagement

A delivered report reflects the written authorization, observed environment, controlled proof, and limitations of that engagement.

Security review record

Start with what was authorized and available.

Scope context keeps a finding from becoming a statement about systems, roles, or environments that were not tested.

Scope

Fictional target

billing-api.example.test, one multi-tenant billing API and selected invoice-read workflow.

Roles

Controlled accounts

Standard users in fictional Organization A and B, plus a designated administrative role for expected behavior comparison.

Environment

Safe context

Non-production example with test records. No customer data, real tokens, or external services are represented.

Executive view

State the failed control, affected workflow, and limits.

The example does not claim a wider compromise or a condition beyond the defined workflow.

Illustrated outcomeA tenant-isolation decision that needs correction

The fictional review identifies a tenant-isolation decision that would need correction before relying on the illustrated workflow for multi-organization use.

Finding anatomy

Record expected behavior, observed behavior, impact, and remediation.

This fictional finding shows the fields an engineer and decision maker need. It intentionally omits a reusable exploit payload.

Expected

Organization-bound lookup

An authenticated standard user should receive only invoice records owned by their current organization.

Observed

Controlled cross-tenant result

In this fictional example, a controlled record reference returns another controlled organization’s test invoice.

Prerequisites

Normal user access

A valid controlled test account and controlled record reference are required. No elevated role is assumed.

Evidence handling

Minimize and mask

Preserve only what supports the result. Remove credentials, tokens, unnecessary identifiers, and sensitive fields.

Demonstrated impact

Tenant boundary bypass

The illustrated outcome is access to a controlled invoice record across a tenant boundary, not access to unrelated systems.

Severity reasoning

Explain assumptions

Severity connects data sensitivity, prerequisites, exposure, business context, and constraints that change consequence.

Remediation direction

Correct the authorization decision where it is made.

Fix the control in the service, then prove the nearby paths follow it.

  • 01

    Resolve invoices through the authenticated organization context, not only a caller-supplied reference.

  • 02

    Apply the same ownership rule to read, export, update, and delete operations that touch the tenant-owned object.

  • 03

    Add controlled authorization tests for equivalent routes and roles so the requirement remains visible as the application changes.

Retest example

A retest status must name what was checked.

Record the version, environment, checked paths, and evidence supporting the result.

Illustrative statusFixed in the fictional retest

The controlled cross-tenant request is denied after the example ownership check is added. Equivalent controlled read and export paths are also checked. This is an example of status language, not evidence of a real fix.

Method and limitations

Coverage statements must name what was and was not tested.

A report describes a defined review at a point in time.

  • 01

    Document authorized targets, roles, environment, exclusions, and testing constraints.

  • 02

    Distinguish confirmed outcomes from hypotheses, scanner signals, and conditions that could not be safely tested.

  • 03

    Record material negative results only for the specific paths and conditions checked.

  • 04

    A report cannot prove the absence of all vulnerabilities.

Application security reporting

Need a report your team can use to fix the issue?

Security testing

Share the application, security question, and constraints. GK Data will respond with focused scoping questions before research begins.

Discuss a security reviewExplore website services