Menu

Sample assessment

What a review report looks like

An illustrative example of the structure, depth and tone of an Independent Application Review.

This is a fictional example. “Harbourline Client Portal” and “ Harbourline Bookkeeping” do not exist. No real application was tested, and this is not a customer engagement. The findings are representative of issues commonly found in small applications, written to show how we document and explain them.

Independent Application Review · Illustrative example

Harbourline Client Portal

Prepared for
Harbourline Bookkeeping (fictional)
Prepared by
Purple Tree Owl
Report date
Illustrative example — not dated
Classification
Confidential (in a real engagement)

1. Executive summary

The Harbourline Client Portal is a genuinely useful application that does what it was designed to do. The interface is clear, the hosting choice is sensible for the firm's size, and several good security practices — such as HTTPS everywhere and hashed passwords handled by a reputable authentication provider — are already in place.

However, we identified one high-priority issue that should be resolved before more clients are invited: under certain conditions, a signed-in client can view statements belonging to another client. We also found that error pages reveal unnecessary technical detail, that some lists will become slow as data grows, and that there is no documented, tested way to recover the database.

None of these issues requires rebuilding the application. With the recommended changes — most of which are small — the portal would be in a sound position for its intended use.

Priority Findings
High 1
Medium 3
Low 1

2. Application overview

A small customer portal where clients of a bookkeeping firm upload receipts, view statements and message their bookkeeper. Built by the firm's owner over several months using an AI coding assistant, a popular JavaScript framework, a managed Postgres database and a serverless hosting platform.

3. Review scope

Examined

  • Source code repository (read-only access) at an agreed commit
  • Hosting, environment and database configuration (read-only)
  • Authenticated testing in a staging copy using two test client accounts
  • Review of authentication, authorization, data handling and error handling
  • Architecture, scalability and operational readiness
  • Usability and accessibility spot checks on key user journeys

Not examined

  • Testing against the live production environment
  • The third-party authentication provider's own infrastructure
  • Formal penetration testing or denial-of-service testing
  • Email deliverability and the firm's office network
  • A full WCAG conformance audit

4. Priority definitions

High
Could directly expose data, money or control of the system, or seriously disrupt the business. Address before relying on the application further.
Medium
A real weakness or limitation that increases risk or cost. Plan to address it soon.
Low
A quality, usability or hardening improvement. Address as part of normal maintenance.

5. Findings

HCP-01 High Security — authorization

Clients can view other clients' statements by changing a number in the address

Observation
The statement download page checks that a visitor is signed in, but does not check that the requested statement belongs to them. Statement identifiers are sequential numbers.
Business impact
Any client could read other clients' financial statements. This is a serious confidentiality breach with potential regulatory, contractual and reputational consequences.
Supporting evidence
In the staging environment, test client A requested /statements/1042 (belonging to test client B) and received the full document. The server route reads the statement by ID without filtering by the signed-in client's account.
Recommendation
Enforce ownership on the server for every statement, message and receipt query (for example, always filter by the signed-in account ID). Add an automated test that proves one client cannot read another's records. Consider non-sequential identifiers as an additional layer, not as the fix. Review access logs, if available, to determine whether this was ever used.
HCP-02 Medium Security — information exposure

Error pages reveal internal implementation details

Observation
When a request fails, the application returns the full error message, including database table names, file paths and framework version.
Business impact
This does not expose client data directly, but it gives an attacker a map of the system and makes other weaknesses easier to find and exploit.
Supporting evidence
Submitting a malformed date in the receipt upload form produced an error page showing a database query, an internal file path and a stack trace.
Recommendation
Show visitors a friendly, generic error message with a reference number. Record full details only in server-side logs, with access restricted to the people who maintain the application.
HCP-03 Medium Architecture — performance and scalability

Receipt and message lists load every record at once

Observation
Lists retrieve all of a client's receipts and messages in a single query, without pagination or limits.
Business impact
Performance is fine today, but long-standing clients will see slower pages each year, and database costs will grow faster than the number of clients.
Supporting evidence
The receipts query has no limit clause. In staging, a test account seeded with 5,000 receipts took several seconds to load the page.
Recommendation
Add pagination (for example, 25 items per page) with an index on the client and date columns. This is a small change now and a larger one later.
HCP-04 Medium Operational readiness

Backups exist but recovery has never been tested or documented

Observation
The managed database provider takes daily automated backups, but nobody at the firm knows how to restore one, how much data could be lost, or how long recovery would take.
Business impact
If data is accidentally deleted or corrupted, recovery could be slow, incomplete, or depend on finding the right person at the right moment.
Supporting evidence
Backup settings were confirmed in the database provider's console. No recovery procedure exists in the repository or the firm's documentation.
Recommendation
Write a one-page recovery procedure, perform one test restore into a separate environment, and record how long it took. Repeat at least annually.
HCP-05 Low Design and usability — accessibility

Form fields are missing accessible labels

Observation
Several form fields use placeholder text instead of visible labels, which disappear when a user starts typing and are not reliably announced by screen readers.
Business impact
Some clients may find forms harder to complete, leading to support requests and errors in submitted information.
Supporting evidence
Observed on the receipt upload and profile forms during keyboard and screen-reader spot checks.
Recommendation
Add visible labels connected to each input, and keep placeholder text for examples only.

6. Recommended next steps

  1. Fix HCP-01 before inviting additional clients, and confirm the fix with an automated test.
  2. Address HCP-02 and HCP-04 within the next few weeks; both are small, contained changes.
  3. Schedule HCP-03 and HCP-05 into normal improvement work.
  4. Optional: a short follow-up review to confirm the high-priority fix.

In a real report, this section is followed by an appendix describing methods, tools, test accounts used and the exact version reviewed.

What to notice about this format

  • The summary comes first and is written for the business owner, not the developer.
  • Strengths are acknowledged. A useful review tells you what's working, not just what isn't.
  • Scope is explicit, including what was not examined — so nobody mistakes the report for more than it is.
  • Every finding links impact to evidence and a specific fix, so it can be acted on by a person or an AI coding tool.

Want a report like this for your application?

Request an Independent Review About the review service