Sample report · Illustrative scenarios
What an attacker could reach—and how to stop it
These are fictional reconstructions inspired by real types of security failures. Domains, accounts, responses and test histories are invented. They are not customer results or proof that EverBreach has performed these tests.
What needs attention
In the recruitment scenario, an ordinary applicant account can read another applicant’s details and CV. In the photo-store scenario, an unpaid visitor can retrieve a full-resolution image. Both failures happen on the server side; hiding a button in the interface would leave the access open.
High · Contain immediately
An applicant account can read other applicants’ recordsResponsible team: Application team and recruitment-system owner
Restrict the applicant-list endpoint and CV downloads while the permission checks are corrected.
High · Close unpaid access
Full-resolution images are available before paymentResponsible team: Commerce application team and storage/CDN owner
Make original files private and stop returning usable download links to unpaid visitors.
What this example covers
Two separate example environments: a recruitment portal and a photo store. Testing uses seeded applicant records, synthetic CVs, test images and test accounts with agreed roles. No real applicant data or paid content is accessed.
High · Contain immediately
1. An applicant account can read other applicants’ records
- Responsible team
- Application team and recruitment-system owner
- Immediate action
- Restrict the applicant-list endpoint and CV downloads while the permission checks are corrected.
Business impact
Names, contact details and CVs can reveal employment history and other personal information. An attacker could use them for targeted fraud or disclose them publicly. If the same missing check applies to the full intake, the exposure could extend to all new applicants; the limited test below does not establish that total.
What was demonstrated
Applicant A received records for seeded applicants A and B and downloaded B’s synthetic CV. An anonymous request received 401. This is a failure to check what a logged-in user may access, not a bypass of login. Testing stopped after the two agreed records.
How an attacker could use this
- Create or use an ordinary applicant account; no recruiter access is needed.
- Request the application list used by the portal. The server returns another applicant’s record as well as the account’s own record.
- Use the returned record identifier to request that applicant’s CV. Repeating this against more records could broaden the exposure. Bulk collection was not performed.
Why this surfaced in this test
Example trigger: a new application release. The same test account and fixtures received 403 from the list route in r41, then 200 in r42. In this reconstruction, reviewing the change identifies a new route that omitted the recruiter check. The model and test setup were unchanged; the key was the application change.
Evidence and remediation
Example environment: careers.example.com · release r42
Illustrative request and response
GET /api/applications?status=new
Session: applicant_test_A (no recruiter role)
HTTP 200
[{id:"test-A", email:"a@example.com"},
{id:"test-B", email:"b@example.com"}]
GET /api/applications/test-B/cv
Session: applicant_test_A
HTTP 200 · application/pdf (synthetic CV)
Control: no session -> HTTP 401Why access was possible
The list route checks only for a valid session. It does not require a recruiter role or restrict records to their owner. The CV route has the same missing object-level permission check. A non-guessable record ID would not fix this: the list already discloses the IDs.
Fix the underlying problem
- Temporarily deny applicant access to the list and document routes. Preserve relevant access logs and establish when the affected release became reachable.
- On the server, allow recruitment-wide listings only to authorized recruiters. Allow applicants to read only their own permitted records. Apply the same policy to CV downloads and direct storage access.
- Add tests for applicant A, applicant B, an authorized recruiter and no session. Include list, detail, export and attachment routes; deny access by default.
- Review logs for access outside those permissions and involve the organisation’s incident-response and privacy contacts to assess any actual exposure. Avoid copying personal data into ordinary tickets.
Acceptance criteria for the retest
Applicant A can use the intended self-service features but receives 403 or 404 for B’s record and CV, with no data in the response. The list denies applicant accounts. Authorized recruiters retain their intended access; anonymous requests fail. Direct file access also fails. Save these cases as regression tests.
Confirmed in this example: cross-applicant disclosure of two seeded records and one synthetic CV. Not established: access to every applicant, past misuse, or exposure of a production database.
OWASP · Broken object-level authorizationHigh · Close unpaid access
2. Full-resolution images are available before payment
- Responsible team
- Commerce application team and storage/CDN owner
- Immediate action
- Make original files private and stop returning usable download links to unpaid visitors.
Business impact
The store delivers the product before completing the sale. Visitors could save or redistribute the original without buying it. If other catalogue entries use the same response and storage rules, the weakness could affect many images. The example demonstrates one agreed test image, not a download of the catalogue.
What was demonstrated
A test buyer with no purchases received an original-image URL in the photo response. A separate request without a session retrieved the full-resolution test image. The order remained unpaid and no payment was made.
How an attacker could use this
- Open a photo’s purchase page as an unpaid visitor.
- Read the image details the application sends to the browser before checkout. They include the original file’s address, even though the page only displays a preview.
- Request that address directly. The file server returns the original without checking a purchase. Other images would need to be tested before claiming catalogue-wide access.
Why this surfaced in this test
Example trigger: a retest after a model update. Release r17, accounts, fixtures, tools, instructions and test budget are held constant. The later run follows the link from preview to original; the earlier run did not report it. The flaw already existed. One pair of runs cannot prove the model update caused the improvement; repeated comparable runs would be needed.
Evidence and remediation
Example environment: studio.example.com + media.example.com · release r17
Illustrative request and response
GET /api/photos/test-photo-01
Session: buyer_test_A · purchases: []
HTTP 200
{"previewUrl":"/previews/test-photo-01.jpg",
"originalUrl":"https://media.example.com/originals/test-photo-01.jpg"}
GET originalUrl · no session
HTTP 200 · image/jpeg · full resolution
Order state: unpaid · no payment submittedWhy access was possible
The interface hides the download button until payment, but the API exposes the original URL beforehand and the file host serves it publicly. Both controls are missing: purchase authorization in the application and private access at the file origin.
Fix the underlying problem
- Remove public access to original files at storage and CDN level. Invalidate cached public copies and previously exposed access links where applicable; keep previews available.
- Return previews to unpaid visitors. Before issuing access to an original, verify payment status on the server with the payment provider and check that the buyer owns the entitlement for that image. Do not trust a browser success page or client-supplied paid flag.
- Serve originals through an authorized download route or issue short-lived, narrowly scoped signed URLs only after that check. A signed URL is usable by whoever possesses it until it expires; do not expose it before payment.
- Test unpaid, pending, failed and cancelled payments, plus a valid purchase and access to a different image. Verify the file host cannot bypass the application’s decision.
Acceptance criteria for the retest
Unpaid requests receive a preview and no usable original URL. Direct original-file requests fail. Pending, failed and cancelled payments do not grant access. A verified buyer can download only the purchased image; another image is denied. Expired download links fail and public previews still work.
Confirmed in this example: one original test image retrieved without payment. Not established: access to every image, actual lost sales, or a model-specific detection advantage.
OWASP · Transaction authorizationTurn findings into assigned work
Example handoff for an internal team or an external provider. Use only the findings relevant to your system and attach the actual report.
Hello, Please review the attached findings and assign an owner to each relevant issue. RECRUITMENT: restrict applicant-list access to authorized recruiters and enforce access checks on each application and CV download. Preserve relevant logs and review the possible exposure window. PHOTO STORE: keep originals private. Grant download access only after server-side confirmation of payment and entitlement to that specific image. Check both storage and CDN access. Please confirm the containment action, proposed permanent fix, cost and target date before implementation. Include the report’s allowed and denied access cases in regression tests, then arrange a retest. Thank you.
What this report does not establish
These scenarios illustrate the depth of an application assessment, not the coverage of the current external scanner. A real engagement must separately agree application access, test accounts, permitted actions and stop conditions. The examples show limited proofs using test data; they do not establish a real breach, total exposure or an AI model’s general success rate.