Sample Findings
A public proof gallery showing how SaaS boundary failures can survive normal QA, then surface only when requests are replayed with the right tenant, role, object, or entitlement context.
These examples show issues where the request can look valid, authenticated, and correctly shaped, while still returning data or performing actions outside the caller's scope.
Severity first
Each card starts with severity so buyers can see what carries business risk before reading the proof detail.
Boundary area
Each finding is grouped by the SaaS boundary it touches, such as tenant isolation, billing, authentication, exports, or logging.
Fix direction
Each finding ends with a short remediation direction so the page moves from proof to next step.
Ten examples showing how authorization, tenant isolation, exports, billing, webhooks, API keys, sessions, and audit evidence can fail.
A different tenant can read the same object ID
A valid request returned another tenant's record instead of blocking the replay.
What failed
The object was resolved before tenant ownership was enforced.
Fix direction
Resolve tenant scope before object lookup and retest the same mismatch.
List results include rows from the wrong tenant
The list endpoint returned the correct shape but the wrong customer rows.
What failed
The tenant predicate was missing from the query path.
Fix direction
Add tenant scoping at the repository layer and verify list output again.
Fake billing upgrade accepted without verified payment or entitlement
A plan or entitlement state changed even though the backend had not verified the payment event.
What failed
The application trusted a client-visible billing state instead of server-side payment and entitlement verification.
Fix direction
Only grant paid capabilities after verified provider events, idempotent webhook handling, and server-side entitlement checks.
CSV export replays data beyond the caller's scope
A normal export request returned more records than the active tenant should see.
What failed
The export job reused a broad data source without the caller's boundary.
Fix direction
Bind exports to tenant scope at query time and validate the generated file.
Support tooling can bypass the customer boundary
A support path accepted the request with broader access than the normal user flow.
What failed
The elevated route did not recheck the target account or object.
Fix direction
Require the same tenant and ownership checks in the support path.
Child objects inherit the wrong parent context
The parent was valid, but the nested record belonged to a different customer.
What failed
The child object was never revalidated after the parent lookup.
Fix direction
Check both parent and child ownership before returning the nested object.
Delete-by-ID still works under a role downgrade
A lower-privilege actor was still able to execute the same mutation.
What failed
The mutation path trusted a route the role should no longer control.
Fix direction
Move the permission check into the mutation handler and replay the downgrade test.
Role labels change in the UI, but backend access does not
The visible role changed, but the API still behaved as if the higher privilege remained.
What failed
The backend did not fully refresh the permission decision after the role change.
Fix direction
Recompute authorization server-side on every protected request.
A blocked path still exposes extra customer fields
The main action was limited, but the response returned more data than needed.
What failed
The serializer included fields that should have been stripped for the caller.
Fix direction
Trim the response shape to the approved field set before returning it.
Denied requests leave too little review evidence
When access was blocked, the report did not keep enough detail to explain the decision.
What failed
The sample output lacked enough request context for later review.
Fix direction
Record the original request, mutated request, actor, tenant, and response diff.
The public examples are modeled in the Agnite Security Lab
The Agnite Security Lab models controlled SaaS scenarios before they are condensed into the public findings. The lab page explains the scenario layer without exposing raw internals.
Open the scenario layer
Use the lab page to understand how the proof gallery is built without surfacing vulnerable internals, source code, or localhost-only artifacts.
Move from examples into the full proof set
Sample Audit Report
See how these findings sit inside a buyer-facing report.
View full sample reportAudit Checklist
Review the same SaaS boundaries in a release-check format.
View audit checklistAgnite Security Lab
See the controlled scenarios behind the public examples.
Open security labSaaS Security Audit
Request the audit if these risks apply to your SaaS.
Request this auditConnect the findings to the audit paths
These are the closest service pages that explain the same boundary failures in live audit form.
API Authorization Audit
Request-level authorization testing for actors, roles, tenants, and object access.
Open auditTenant Isolation Audit
Boundary testing for tenant-scoped reads, exports, reports, and shared-resource access.
Open auditBroken Access Control Audit
Runtime access control testing across actions, roles, objects, and permission boundaries.
Open auditObject-Level Authorization Audit
Resource-level access testing across records, files, reports, exports, and nested resources.
Open auditRBAC Audit
Role and permission validation for admin paths, exports, and object access.
Open auditAudit Log Review
Evidence review for events, authorization decisions, and tenant context.
Open auditNeed findings like these for your SaaS?
Findings like these usually mean authorization logic is scattered across routes, roles, query filters, exports, background jobs, billing flows, or webhook handlers. Agnite Studio tests those boundaries directly and turns the evidence into a clear remediation plan.