Demonstration report. Synthetic application, not a customer engagement.

A finding you can act on.

This example shows how evidence, impact, a fix and verification fit together. It does not describe a real customer or assess your application.

Reviewed scope and version

Application: Demo Projects, a synthetic SaaS app
Version: demo-v1, illustrative snapshot
Scope: One project-read endpoint and its ownership control
Method: Illustrative Tier 1 source review
Excluded: Other routes, deployment testing and third-party services
Status: Example finding, remediation not verified

Illustrative severity: high

A signed in account can read another account’s project.

The endpoint confirms that a session exists, then loads the project by its ID alone. It never checks that the current account owns that project. A valid session is not enough to authorize access to every record.

Synthetic evidence

Using two invented accounts and a dummy project, the example source behaves like this:

Demo account A owns project demo-project-a.
Demo account B requests GET /api/projects/demo-project-a.
Illustrated response: 200, project A returned.
Expected: 403 or 404, with no project data.

Illustrated query:
  projects.findOne({ id: requestedId })
Missing constraint:
  ownerId: authenticatedAccount.id

Invented identifiers and expected behavior only. No request was sent to a customer system.

Potential impact

In an app with this flaw, a user who obtains another project’s ID could read its private data. The actual impact would depend on the exposed fields and how project IDs become available. This example does not demonstrate writes or deletion.

Prioritized remediation

Enforce ownership on the server using the authenticated account ID. Never trust an owner ID supplied by the browser.
Constrain the database query by both project ID and account ownership. If row level security is part of the design, verify that its policy enforces the same boundary.
Review related read, update and delete paths for the same missing check.
Add regression tests using separate accounts and verify the intended shared-access rules.

Example coding-agent fix prompt

Review the project-read endpoint in this synthetic example. Enforce ownership with the authenticated server session and constrain the query by project ID and owner. Add tests that let the owner read their project, deny a second account and deny signed out access. Preserve any explicitly designed sharing rules. Do not include secrets or customer data. Explain the change and the test results for review before deployment.

Verification checklist

Account A can read its own synthetic project.
Account B receives a denial with no project data.
A signed out request receives no project data.
Changing a client-supplied owner field cannot bypass the check.
Intended sharing still works within its permission rules.
The reviewed fix and test results identify the exact code version.

A real report records what was actually examined and verified, along with remaining limitations. This demonstration is not a complete report, a security guarantee or evidence of badge eligibility.

Get ready for your own review.

Start with the free readiness checklist. No email or payment required.

Check if your app is ready

Automated checks start at $99 and do not include a badge. Tier 1 reviews start at $999 and Tier 2 at $1,999, with 50% deposits. Your app size sets the price. The scope, refund terms and agreement come before payment.