old code /Engineering review · sample report
Fictional exampleSecurity audit

Your orders.
Who can see them?

A review of order access: what was found, why it matters and where to start fixing it.

System reviewed
Fictional online store
Area
Viewing one order
Example version
DEMO / 01

All data and results below are fictional and illustrate the report format. They do not represent an audit of a real project or an actual test run.

Priority: block access to other customers' orders

In this fictional scenario, a customer can read another customer's order.

The system checks that the user is signed in, but does not check whether they own the requested order. Changing the order ID reveals another customer's data.

First action

Add a server-side ownership check and cover it with tests. Resolving this issue does not require a full system rewrite.

See the supporting evidence
One confirmed issue in the example

This status applies to the fictional scenario. Supporting evidence is shown below.

The finding covers one endpoint

It does not assess the security of the whole store. Other areas have not been examined.

02 / Access flow

Signed in.
Permissions unchecked.

Identifying a user and authorizing a specific action are two separate checks.

How the issue occursFictional flow · before the fix

Required boundary: before returning data, the server checks whether the current user is allowed to access this order.

03 / Findings

From finding to evidence.

SEC–01High severityConfirmed in the example

Reading an order without checking ownership

The GET /api/orders/:id endpoint returns an order by ID to any signed-in customer. This fictional scenario has no order ownership check.

Why it matters

Another customer can see the order items, recipient name and delivery address. Private data is exposed outside its owner's account.

When it occurs

A signed-in customer supplies the ID of another customer's order. This example does not establish whether the order can be changed or deleted.

Supporting evidence and reproduction steps

Illustrative evidence for this fictional example. A real report would include anonymized results from reviewing an agreed version of the project.

  1. Create test customers A and B with separate accounts.
  2. Create order #1042 for customer A.
  3. Request that order through the API as customer B.
  4. Compare the order owner with the user who received the response.
Illustrative request and response · fictional data
GET /api/orders/1042
User context: buyer_b

HTTP 200 OK
{
  "id": 1042,
  "customerId": "buyer_a",
  "items": ["Sample product"],
  "recipient": "Test recipient A",
  "deliveryAddress": "Sample address A"
}

Expected: access denied, with no other customer's order data. In the example: a successful response containing customer A's data. A matching order ID is not sufficient to authorize access.

How to verify the fix
Acceptance criteria for a future fix. These checks have not yet been performed.
ScenarioBefore the fix in this exampleAcceptance criterion
A requests their own orderAccess grantedAccess remains available
B requests A's orderAnother customer's data returnedAccess denied, no data returned
Request without signing inAccess deniedAccess remains denied
Request for a nonexistent orderNot checkedAgreed response without unnecessary information

The exact denial status codes must be agreed in the API contract before making changes. A separate check must confirm that the response does not reveal whether another customer's order exists.

What already works in the example

Authentication is checked. The owner can read their order. Both behaviors must be preserved by the fix.

What remains unknown

Staff access, exports and order modifications have not been checked. The absence of findings in these areas does not mean there are no issues.

04 / Next step

Fix one area.
Verify the result.

The recommended first stage covers customer access to a single order. Other changes require a separate agreement.

  1. Agree on access rules

    Define who may read an order, what an unauthorized user receives and the expected response for a nonexistent order.

    Deliverable: agreed rules and verification scenarios.

  2. Add the server-side check

    Tie order retrieval to the current user's permissions. A check in the interface alone cannot prevent a direct API request.

    Deliverable: code changes and tests in the client's repository.

  3. Verify and hand over

    Run the acceptance scenarios in a test environment. Agree on deployment and recovery procedures separately before release.

    Deliverable: verification results, a change description and release instructions.

The stage is complete when its outcome can be verified.

The owner receives their order; an unauthorized user is denied access without receiving private data. Results of the agreed checks are attached. The client decides whether to release.

05 / Review scope

What this report establishes.
And where its scope ends.

Question
Can one customer read another customer's order?
Materials
Fictional scenario DEMO / 01. No real code or client data was used. A real report would identify the code version, date and materials provided.
Example scope
Reading one order via GET /api/orders/:id as its owner, another customer and a visitor who is not signed in.
Out of scope
Payments, order modifications, staff permissions, infrastructure, dependencies and load. This is not an assessment of the store's overall security.
Confidence
“Confirmed in the example” describes the predefined outcome of the fictional scenario. “Not checked” means no conclusion is available. No actual checks were performed for this demo.

The report belongs to you

A clear next step.
Your choice of developer.

The report is yours to keep after the free audit. Use it with your team, share it with another developer or discuss the next stage with Old Code.

Before we start

We agree on one question, scope, materials and delivery date. Code sharing and AI processing terms are discussed in advance.

If you continue

We agree on the outcome, price and acceptance criteria for a small stage. Fixes are not included in the free audit.

If you stop

No further stage starts without your approval. Terms for stopping during a stage are agreed before it begins.