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, I agree the environment, permitted actions and deliverables with you before testing. See the paid audit service or read how scope affects audit cost.

Comparing proposals? Use the audit scope and evidence matrix to record coverage and exclusions.

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.

Audit scope and evidence matrix

An audit quote should tell you what the reviewer will examine, how they will check it and what evidence you will receive. “Auth, payments and database reviewed” leaves too much open. Use the matrix below to compare the actual work behind two quotes.

This is my proposed starting template for an AI-built SaaS, not a universal package. A prototype with no private data needs a different review from a multi-tenant product processing payments. Choose the rows that match your product and record what is excluded.

For billing, ask about more than whether a checkout button works. Stripe documents signature verification, retries, duplicate delivery and non-guaranteed event order. Those behaviours belong in the test design when an application relies on Stripe events. They do not prove that any particular integration is broken. Stripe webhook documentation.

For recovery, check exactly what the backup contains. Supabase explicitly separates database backups from the objects stored through its Storage API. If customer files are essential, a database-only restore is incomplete evidence of product recovery. Supabase backup documentation.

Give every row a status

Use these labels in the scope and the final report:

• Verified within scope: the agreed check ran against the recorded version and produced the expected result.
• Finding: the evidence demonstrates a departure from the expected behaviour.
• Blocked: the check could not be completed, with the missing access or dependency named.
• Not tested: no result is being claimed.
• Not applicable: the reviewer explains why the control or workflow does not apply.

A report with zero findings and several blocked checks does not establish the same thing as a report with completed coverage. “Verified” is still limited to the checks performed and the version tested.

Automated checks and developer review have different jobs

Automated tools can inspect dependencies, search code, check configuration, and run repeatable permission tests. A developer still needs to define what the application is supposed to allow, investigate relevant results and decide whether the evidence supports the claimed impact. Manual review also has limits: a reviewer can miss a path, misunderstand a requirement or lack access to the deployed configuration.

Ask for the method used on each important boundary. A tool report can be useful evidence. So can a carefully recorded manual test. Neither should be presented as comprehensive without a defined scope.

Where a quote references OWASP ASVS, ask which version and requirements it covers. ASVS provides verifiable requirements and recommends versioned identifiers. A claim that an audit is “OWASP based” is less informative than a named subset with recorded outcomes. This matrix is a planning aid, not a reproduction of ASVS or a claim of full ASVS verification. OWASP ASVS.

Copy this evidence record into the brief

Workflow / requirement:
Expected behaviour and who confirmed it:
Environment and source revision:
Permitted test actions and exclusions:
Method: source review / automated test / manual test / configuration review
Accounts, roles and synthetic fixtures required:
Positive control:
Rejected or invalid case:
Observed result and sanitized evidence reference:
Status: verified within scope / finding / blocked / not tested / not applicable
Impact and confidence:
Remediation recommendation:
Re-test criteria, owner and agreed coverage:

Do not paste production secrets or customer records into a quote request. Agree on access arrangements, test accounts and evidence handling before the assessment begins. Tests that send messages, create payments, delete data or affect availability need explicit limits.

Separate the report from the repair

Confirm whether the price covers investigation, implementation, a re-test or some combination. Ask how newly discovered scope is handled and what a “free re-review” includes. Recovery testing and code maintainability should not quietly appear as promises inside a security-only quote.

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.