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.
10 findings across SaaS trust boundaries
Scope
Tenant isolation, RBAC, billing, webhooks, exports
Evidence
Request and response artifacts
Format
Severity, evidence, impact, fix direction
Status
Controlled sample, not client data
This public sample shows the structure and level of evidence used in an Agnite SaaS security audit. It uses controlled lab scenarios instead of client data, so the findings can be reviewed without exposing private systems, source code, internal URLs, or raw request dumps.
What a buyer or engineering lead can expect from the audit output
The report focuses on security boundaries that matter in multi-tenant SaaS products: who made the request, which tenant or object was targeted, what the vulnerable behavior allowed, what the fixed behavior should enforce, and how the issue should be retested.
Each finding is framed around impact, proof summary, and remediation direction so the risk is understandable to both engineering and business stakeholders.
The public version intentionally omits raw commands, request dumps, source code, local URLs, repository names, and seed data.
Boundaries covered in the sample audit
Application
Fictional multi-tenant SaaS lab
Review type
Controlled security review of vulnerable and fixed request paths
Evidence model
Observed behavior, impact, proof summary, and remediation direction
Coverage
Tenant isolation, RBAC, billing, webhooks, exports, API keys, sessions
Findings ordered by risk and business impact
Critical issues are shown first because they can expose tenant data, alter billing state, or accept forged trust signals. High severity issues cover privilege escalation, credential misuse, replay paths, and bulk data exposure.
| Finding | Severity | Area | Proof Summary |
|---|---|---|---|
| Cross tenant invoice access | Critical | Tenant isolation | An Alpha user can read a Beta invoice from the vulnerable endpoint. |
| Fake plan upgrade accepted | Critical | Billing | The vulnerable route trusts a client-supplied paid flag and accepts an enterprise upgrade. |
| Unsigned webhook accepted | Critical | Webhooks | A Stripe-like webhook is processed without any signature on the vulnerable route. |
| Cross tenant project IDOR | High | IDOR / BOLA | The vulnerable project lookup exposes a Beta project to an Alpha user. |
| Member can invite users | High | RBAC | A regular member can create a project invite on the vulnerable route. |
| Expired token still works | High | Broken authentication | The vulnerable profile endpoint still accepts an expired session token. |
| Cross tenant export leak | High | Exports and downloads | The vulnerable export includes projects from Beta and Gamma, not just Alpha. |
| Deleted API key still works | High | API keys | A deleted API key still authenticates to the vulnerable API key route. |
| Password reset token reused | High | Broken authentication | The same reset token can be consumed more than once on the vulnerable flow. |
| Weak audit logs | Medium | Audit logging | The vulnerable audit log misses key actor, target, tenant, and result context. |
Each finding uses the same evidence format
Every finding explains why the issue matters, what behavior proved the weakness, and what control should be added or corrected.
Cross tenant invoice access
Financial records, billing history, and tenant identity data can be exposed across customer boundaries.
An Alpha user can read a Beta invoice from the vulnerable endpoint.
Enforce tenant-scoped authorization on every request and reject any object that falls outside the caller's tenant.
Fake plan upgrade accepted
An attacker could unlock premium service tiers without a real payment event or billing validation.
The vulnerable route trusts a client-supplied paid flag and accepts an enterprise upgrade.
Move billing state decisions to trusted server-side checks and verify plan changes against authoritative subscription data.
Unsigned webhook accepted
Forged events can alter subscription state, credits, or entitlement data without a valid trust boundary.
A Stripe-like webhook is processed without any signature on the vulnerable route.
Verify webhook signatures before processing, reject unsigned payloads, and make event handling idempotent.
Cross tenant project IDOR
Project metadata, names, and tenancy details can be enumerated across customers.
The vulnerable project lookup exposes a Beta project to an Alpha user.
Bind object lookups to the authenticated tenant and deny any request that references an out-of-scope object.
Member can invite users
Unprivileged users can expand access and create unauthorized accounts inside a tenant.
A regular member can create a project invite on the vulnerable route.
Enforce role checks on the server and restrict invite creation to the minimum privileged role required.
Expired token still works
Expired credentials can continue to access user data after they should be invalid.
The vulnerable profile endpoint still accepts an expired session token.
Validate token expiry on every request and reject sessions once they are past their allowed lifetime.
Cross tenant export leak
Bulk export paths can leak multiple tenants' project identifiers and internal structure at once.
The vulnerable export includes projects from Beta and Gamma, not just Alpha.
Scope exports to the caller's tenant and apply the same authorization checks used by interactive reads.
Deleted API key still works
Revoked credentials can continue to access protected endpoints.
A deleted API key still authenticates to the vulnerable API key route.
Check key revocation status at request time and invalidate any cached auth state when a key is deleted.
Password reset token reused
One-time password reset links can be replayed to keep resetting or hijacking accounts.
The same reset token can be consumed more than once on the vulnerable flow.
Make password reset tokens single use, expire them quickly, and invalidate them after the first successful redemption.
Weak audit logs
Poor audit trails make it harder to investigate abuse, denied actions, and support activity.
The vulnerable audit log misses key actor, target, tenant, and result context.
Log actor, target, action, tenant, result, and request context so security and support teams can reconstruct incidents.
Confirm the vulnerable behavior is gone
Start with the trust boundary failures first
Fix the issues that break trust boundaries before polishing lower-risk hardening work.
Close the critical trust boundary issues first: cross-tenant invoice access, fake plan upgrade accepted, and unsigned webhook accepted.
Fix high severity tenant scoping and privilege escalation paths next, including cross-tenant IDORs, RBAC bypasses, and API key scope issues.
Harden broken auth and replay paths so expired, reused, and revoked credentials are rejected consistently.
Improve audit fidelity so suspicious actions, denied requests, and support activity are easier to investigate.
Need this level of evidence for your SaaS?
If your product has tenants, roles, billing flows, exports, API keys, webhooks, or sensitive audit trails, Agnite Studio can test those boundaries and return clear findings with remediation direction.