Illustrative Human Code Review Report

Sample / Booking app

Scope and method

Illustrative scope: a signed-in booking lookup and its client-side error handling. The fictional app is assumed to have authentication middleware. The question is whether users can access only their own bookings and understand failed requests.

This example illustrates manual inspection and recommended validation. No application was run and no tests were executed. Production infrastructure, payment flows, dependencies, and other endpoints are outside this sample.

Finding priorities: 1 high · 1 medium · 1 low
Suggested order: Ownership check → failure handling → shared response types
Overall assessment: The illustrated lookup needs an ownership check before being used with private booking data. The rest of an application cannot be assessed from this excerpt.

High · R-01 · Access control

Booking lookup does not check ownership

Code location: src/api/bookings.ts:8–12 (fictional excerpt)

8   const booking = await db.booking.findUnique({
9     where: { id: params.id },
10  });
11  if (!booking) return notFound();
12  return Response.json(booking);

Evidence and why it matters: The query uses the supplied booking identifier but does not include the authenticated user’s identity. In this example, signing in alone does not establish ownership of the returned booking.
Potential consequence: If identifiers can be obtained or guessed, a user could potentially retrieve another user’s private booking details. Actual impact depends on the surrounding authorization controls and returned fields.
Recommended improvement: Restrict the lookup by both booking ID and the authenticated user’s ID. Return an appropriate response when no authorized record is found, and avoid disclosing unnecessary private fields.
Validation to perform: Test that the owner can retrieve a booking, another signed-in user cannot, and an unauthenticated user is rejected. These are proposed tests, not executed results.

Medium · R-02 · Reliability

A failed request can look like a successful load

Code location: src/client/bookings.ts:22–26 (fictional excerpt)

22  try {
23    const response = await fetch('/api/bookings/' + id);
24    setBooking(await response.json());
25  } catch {
26    setLoading(false);
27  }

Evidence and why it matters: The code does not check the response status before treating the body as booking data. A network error only stops loading, without displaying a useful error state.
Potential consequence: A visitor could see an empty or misleading screen and be unable to distinguish an unavailable booking from a successful load.
Recommended improvement: Handle non-success response statuses explicitly, validate the expected data shape, and show an actionable error state. Keep loading state cleanup in a consistent completion path.
Validation to perform: Exercise success, forbidden, missing-record, server-error, malformed-response, and network-failure cases using controlled fixtures.

Low · R-03 · Maintainability

Define the booking response in one place

Code locations: src/api/bookings.ts:12 and src/client/bookings.ts:24.

Observation: The excerpts return a database record directly and consume unvalidated JSON. There is no explicit response contract in the reviewed code.
Potential consequence: Changes to the record shape can affect the client unexpectedly and make it harder to see which fields are intended for exposure.
Recommended improvement: Define the intended response fields, use a shared type or schema where appropriate, and validate data at the boundary. Check the rest of the project before introducing a duplicate abstraction.

Summary and next steps

For these fictional areas, address authorization first, improve error handling next, and make the response contract explicit. Recheck the agreed paths after changes. A real report would distinguish verified behavior from potential concerns and record any tests actually performed.

High means a potentially serious impact deserves prompt attention in the reviewed context. Medium means a meaningful reliability or maintenance risk. Low means a narrower improvement. Severity depends on evidence, exposure, and context; it is not a claim that exploitation has occurred.

Manual code review does not guarantee that all issues have been identified. This sample is not penetration testing, a comprehensive security audit, or a security certification. Implementation and retesting would require an agreed scope.

Discuss your own project

The estimate is free. I confirm the review scope, fixed price, deliverables, and timing before you decide whether to proceed.