Sample security audit report for an AI-built app

This is an illustrative report for a fictional application, not a real client disclosure or a completed test. All accounts, records and outcomes below are synthetic. It shows how Thunkle structures evidence so a developer can understand the issue and verify the fix.

For your own app, we agree the environment, permitted actions and deliverables before testing. See the paid audit service or read how scope affects audit cost.

Executive summary

Fictional product: a document-review portal where customers upload private reports and staff approve them.

Business rule: a customer may view documents belonging to their own workspace. A staff member may access only the workspaces assigned to them.

Illustrative result: an ordinary customer account can retrieve the contents of a synthetic document assigned to another workspace. The normal interface does not show that document, but the backend request returns it.

Recommended priority: address the document-read authorization boundary before allowing private customer documents into the affected release. This is a finding about one defined path, not a conclusion about every feature.

Scope and limitations

The example assumes an isolated test deployment and a matching source revision, with dedicated customer and staff accounts. Tests use harmless synthetic documents and approved requests.

In scope: the document-read endpoint, its authorization logic and the relevant ownership data. Out of scope: production records, destructive actions, email delivery, payment processing and infrastructure penetration testing.

A real report would record exact environment and revision identifiers, dates and approved exclusions. Those values are deliberately not fabricated here. Untested areas would remain untested, not marked as passed.

Finding A-01: cross-workspace document read

Expected behaviour

Customer A can retrieve document A in workspace A. Customer B, a member only of workspace B, cannot retrieve document A. An assigned staff reviewer can access it only under the application's stated staff policy.

Illustrative evidence

1. Customer A requests synthetic document A. The response contains its harmless fixture text. This establishes that the record exists and the normal request works.
2. Customer B requests the same synthetic record through the same application entry point.
3. In this fictional example, the response also contains document A's text instead of denying access.
4. Source review in the example identifies a signed-in-user check without a corresponding workspace-membership check before the record is returned.

A real evidence attachment would record sanitized request context, response excerpts and the affected code path. It would not publish authentication tokens or private documents.

Impact and severity reasoning

The example demonstrates a confidentiality breach between workspaces. The route can expose a document to an account that should not receive it.

A high-priority rating would be justified if the production-equivalent route serves sensitive customer documents under the same conditions. Severity must still consider actual data sensitivity, access prerequisites and reachability. This example does not invent a CVSS score or claim that a write/delete operation is also vulnerable.

Recommended remediation

Enforce authorization where the document is retrieved, using trusted membership and role information. Keep the permitted staff exception explicit; do not grant every signed-in account that exception.

Review equivalent entry points such as file downloads and exports. If database row-level policies are part of the design, check that the calling identity and any privileged server code preserve the intended boundary. Removing a link from the screen is not the authorization fix.

Re-review acceptance criteria

The original authorized request should still work. Customer B's cross-workspace request should not return document A or a usable private-file location. An assigned staff reviewer should retain only their intended access.

Also test a removed member, an unassigned staff account and a missing document where those paths are in scope. Compare the deployed result with the source change. Record whether the finding is fixed, partially fixed or still reproducible, and explain any remaining limitations.

Example status: not tested. This public sample has no real deployment, so it cannot contain a truthful “verified fixed” result.

What a real engagement adds

The actual report connects these sections to your application, authorized evidence and agreed coverage. Findings are prioritized so you can decide what blocks release and what can follow.

Thunkle's paid developer-led audit includes remediation guidance and a free re-review of agreed fixes. Implementation can be quoted separately. No audit can guarantee the absence of every vulnerability, and this sample is not a security certificate.

Request an audit for your application. Share the platform, roles and critical workflows first; sensitive access is arranged separately.