Sample SaaS Security Audit Report
See how Agnite Studio documents tenant isolation failures, authorization gaps, broken authentication, billing trust issues, webhook validation problems, export leaks, API key misuse, and audit log weaknesses.
This is a public sample built from controlled lab scenarios. It stays safe for buyers to review and does not expose raw internals, real client data, or source material.
What a buyer or engineering lead can expect from the audit output
This sample shows how a SaaS security audit report should read: clear boundary tested, clear vulnerable behavior, clear impact, and clear fix direction.
It is built from controlled lab scenarios, not client data. The goal is to show how request-level evidence is packaged for buyers, founders, and engineering teams without exposing raw commands, source code, local URLs, seed data, or internal systems.
Tenant isolation failures
How request handling can cross customer boundaries and expose data that should stay scoped.
Authorization and RBAC bypasses
How role checks fail when the backend trusts the wrong actor or action context.
Webhook and billing trust boundaries
How subscription state changes break down when incoming events are not verified end to end.
Authentication, API key, and export risks
How expired, revoked, or replayed credentials can still unlock data and download paths.
Findings included
The sample findings are ordered by risk and business impact. Each one shows the affected SaaS trust boundary, what failed, why it matters, and what the fixed behavior should enforce.
3 findings
Trust boundary failures that can expose tenant data or alter billing state.
Cross-tenant invoice access
An Alpha user can read a Beta invoice from the vulnerable endpoint.
Fake plan upgrade accepted
The vulnerable route trusts a client-supplied paid flag and accepts an enterprise upgrade.
Unsigned webhook accepted
A Stripe-like webhook is processed without any signature on the vulnerable route.
6 findings
Authorization, authentication, and credential issues that widen access or enable replay.
Cross-tenant project IDOR
The vulnerable project lookup exposes a Beta project to an Alpha user.
Member can invite users
A regular member can create a project invite on the vulnerable route.
Expired token still works
The vulnerable profile endpoint still accepts an expired session token.
Cross-tenant export leak
The vulnerable export includes projects from Beta and Gamma, not just Alpha.
Deleted API key still works
A deleted API key still authenticates to the vulnerable API key route.
Password reset token reused
The same reset token can be consumed more than once on the vulnerable flow.
1 finding
Visibility and logging gaps that reduce incident response and review quality.
Weak audit logs
The fixed audit log output captures richer suspicious-event metadata than the vulnerable view.
Review the sample report format, share it with engineering or leadership, and compare it against your own SaaS security review process.
Explore the evidence behind the sample report
Use these supporting pages to review the sample findings, release checklist, and controlled lab context behind the report.
Sample Findings
Review individual example findings and how each issue is framed by boundary, impact, and fix direction.
View sample findingsAudit Checklist
Use the checklist version of the same SaaS security boundaries before a release or buyer review.
View audit checklistAgnite Security Lab
See the controlled lab context used to model vulnerable and fixed SaaS behavior.
Open security labUse the sample report in buyer and engineering reviews
The sample format is designed for buyers, founders, and engineering leads who need a concise proof package before deciding whether to scope a full SaaS security audit.
Turn the sample report into a real SaaS security audit
The sample report shows the format. A real audit applies the same request-level testing to your SaaS app: tenant isolation, object access, role rules, exports, billing flows, API keys, webhooks, and authentication behavior.