Handoff Security / BUSINESS SECURITY
Sample security report: from finding to developer action
A fictional booking example shows how an issue can be explained to an owner and handed to a developer.
An illustration, not a client case study
The example below uses synthetic data. It is not evidence of a client engagement or a claim that the same issue exists on your website.
How to read the report
Start with the owner summary, then read the agreed scope, evidence, business impact and suggested repair. A finding should explain which access boundary failed and how a developer can verify the repair.
What a retest means
A retest checks the original reported issue within the agreed time and effort limits. It does not certify the entire application or cover every subsequent change.
Booking example: a customer sees someone else’s booking
On this fictional booking website, a signed-in customer could read another customer’s booking because ownership was not checked.
- Why it matters
- Private booking details could be exposed.
- What needs attention
- Check viewing permissions before releasing this function.
- Who acts next
- The owner prioritises; the developer fixes access checks using Handoff’s evidence and guidance.
Technical details for your developer
01 / Scope & coverage
Demo scope: one fictional booking application; two workflows (view booking, update booking), two roles (customer, administrator), and two endpoints (GET /bookings/{id}, PATCH /bookings/{id}). Two synthetic customer accounts and one administrator account. Coverage records include checks with no confirmed issue; untested areas remain outside the conclusion.
02 / DEMO-01 · Missing booking ownership check
Affected function: viewing a booking through GET /bookings/{id}. Illustrative priority: High, because a normal customer account can read another customer’s private booking without that customer’s permission. Actual severity depends on verified access and exposed data.
03 / Synthetic reproduction & evidence
- Sign in as synthetic customer A. Confirm booking DEMO-A belongs to A and DEMO-B belongs to synthetic customer B.
- Request GET /bookings/DEMO-A, then request GET /bookings/DEMO-B using A’s same session.
- Illustrative result: both return 200; the second response contains {"id":"DEMO-B","owner":"customer-B","service":"Demo appointment"}. Expected: deny access and return no booking data.
04 / Business impact
The demonstration exposes another customer’s booking details. Names or contact details would increase the impact if present; those fields were not part of this synthetic evidence. No claim is made about access to every record.
05 / Developer guidance
Enforce server-side authorisation for each booking read and update using the authenticated user and the booking owner or an explicitly permitted role. Reject unauthorised access before returning data. An unpredictable record ID alone is insufficient. Add regression checks for own-record, other-customer and administrator access. Your developer implements the changes.
06 / Example retest record
DEMO-01 · Illustrative retest after a fictional developer change: A requests DEMO-B and receives 403 with no booking data; A can still read DEMO-A. Status: original reproduction blocked in the tested conditions. This is not a new assessment or proof that all access-control issues are fixed.
07 / Limitations & a report with no confirmed findings
This demonstration does not show a complete assessment. Untested endpoints, third-party platforms, denial-of-service and source-code review are excluded. A real report records agreed scope, checks, results and limitations even when no vulnerabilities are confirmed. No confirmed findings does not establish complete security.
Let’s start with your website.
No technical knowledge needed.
Enquire about my websiteExclude passwords, tokens, customer data, private links and sensitive screenshots.