Public demonstration · No client data

Web application security assessment.

A fictional, publication-safe example showing how CyberKareem structures scope, evidence, risk, remediation, and retest decisions.

Open designed PDF Discuss an assessment

Every organization, hostname, account, finding, date, request, and outcome below is fictional. This page demonstrates reporting structure only and is not evidence of a real assessment.

Executive view

Decision-first risk communication.

The fictional Example Portal assessment identified one high-risk authorization failure and one medium-risk authentication-control weakness. No critical issue or direct server compromise path was demonstrated within the sample scope.

Overall posture: ElevatedAuthorization control requires priority action.
Findings: 41 High, 1 Medium, and 2 Low.
Retest state: PendingValidation follows remediation evidence.

What matters now

Enforce object ownership server-side on every account-scoped API operation.
Add rate limits and detection to the authentication recovery workflow.
Reuse centralized policy checks instead of endpoint-specific ownership logic.
Retest the exploit path and a legitimate-user control after remediation.

Assessment frame

Boundaries and evidence rules.

In scope

portal.example.test

api.example.test/v1

Web and JSON API

Test identity

Two standard users

One organization admin

Synthetic tenant data

Excluded

Production systems

Social engineering and denial of service

Third-party platforms

01
Map
Roles, trust boundaries, routes, assets, and data flows.
02
Test
Authentication, authorization, input handling, sessions, and business logic.
03
Validate
Reproduce with a negative control and minimize impact.
04
Explain
Connect technical evidence to business exposure and a precise fix.
05
Retest
Verify the original path, regression coverage, and legitimate behavior.

Finding detail

Reproducible evidence with a negative control.

AK-WEB-001

Cross-tenant invoice access through object-level authorization failure

High

A standard authenticated user can substitute an invoice identifier belonging to another fictional tenant. The API returns the foreign invoice because it checks authentication but does not constrain the record to the caller's tenant.

Affected component: GET /v1/invoices/{invoiceId}
Weakness: CWE-639, authorization bypass through a user-controlled key
Prerequisite: Any authenticated standard user and a valid invoice identifier
Impact: Cross-tenant billing metadata disclosure

Reproduction trace

Authenticate as fictional User A in Tenant A.
Request User A's own invoice and record the expected 200 response.
Replace only the invoice identifier with a synthetic Tenant B identifier.
Observe a 200 response containing Tenant B billing metadata.
Repeat with a random identifier and observe the 404 negative control.

GET /v1/invoices/inv_example_tenant_b HTTP/1.1
Host: api.example.test
Authorization: Bearer <tenant-a-standard-user-token>

HTTP/1.1 200 OK
{"id":"inv_example_tenant_b","tenant":"tenant-b","total":"[synthetic]"}

Finding resolution

Express the fix as a policy invariant.

Root cause

The lookup uses the user-controlled invoice identifier as its only record constraint. Authentication establishes identity, but the data-access layer does not enforce the caller's tenant or an explicit invoice permission.

Recommended implementation

Derive the tenant from the trusted server-side session.
Query by invoice ID and tenant ID, then fail closed.
Centralize ownership checks across read, update, export, and delete routes.
Add own-tenant, foreign-tenant, missing-object, and privileged-workflow tests.
Review sibling object endpoints for identifier-only lookups.

Retest acceptance criteria
Test	Expected result
Tenant A reads Tenant A invoice	200, complete authorized response
Tenant A requests Tenant B invoice	404 or policy-equivalent denial, no foreign metadata
Tenant A exports Tenant B invoice	Denied by the same centralized policy
Authorized support workflow	Allowed only through explicit, auditable privilege

Supporting record

Engineering handoff and retest roadmap.

Synthetic finding register
ID	Severity	Finding	Owner
AK-WEB-001	High	Cross-tenant invoice access	API team
AK-AUTH-002	Medium	Recovery workflow lacks bounded rate limiting	Identity team
AK-WEB-003	Low	Session cookie omits SameSite policy	Platform team
AK-INFO-004	Low	Verbose framework detail in error responses	API team

0 to 7 days

Contain

Fix AK-WEB-001, add tenant-bound query controls, and review sibling object routes.

8 to 30 days

Standardize

Deploy recovery rate limits, centralize authorization policy, and add integration coverage.

30 to 60 days

Verify

Retest every finding, review access logs, and track the remaining hardening work.