SaaS Security Audit Checklist
Use this checklist to catch SaaS security failures that hide behind valid API requests: wrong object access, tenant leaks, weak role checks, unsafe exports, and broken retest paths.
This is a public guide to the audit thinking behind Agnite Studio's SaaS security reviews. It helps you understand what gets tested before release, buyer review, or a deeper security audit.
It is not a replacement for reviewing your own app with live requests, real roles, real tenant boundaries, and request-level evidence.
Built around live request behavior
This review is not a static compliance list. It is built around the places where SaaS apps actually fail: API requests that look authenticated, but return or change data outside the correct object, tenant, role, or workflow boundary.
Release review
Use this boundary review before shipping sensitive workflows, new tenant features, admin panels, exports, or role changes.
Boundary focused
Focus on the SaaS boundaries that usually create real risk: objects, tenants, roles, sessions, exports, and mutations.
Evidence ready
Write checks in a way that produces replayable proof, not vague "access control reviewed" notes.
Six SaaS boundaries to review
Each group targets a boundary where SaaS apps commonly fail: the API accepts the request, but returns or changes data the actor should never reach.
Object access
Check direct object replay first, because BOLA often hides behind valid authentication.
- Replay the same object ID under a different user.
- Replay the same object ID under a different tenant.
- Verify unauthorized replays return 403, 404, or empty data consistently.
- Confirm object ownership is enforced in the backend, not inferred from the UI route or client state.
Tenant boundaries
Make sure list endpoints, joined queries, exports, and cached responses never escape the active tenant.
- Test list, search, filter, sort, and pagination responses.
- Inspect whether the query layer applies tenant predicates consistently.
- Check nested includes, joins, reports, and exports.
- Verify cache keys cannot reuse data across tenants.
Role rules
A changed role should change server behavior, not just the visible controls in the UI.
- Test owner, admin, support, manager, and viewer flows.
- Replay the same request after role downgrade.
- Confirm permissions are evaluated after tenant resolution.
- Check that admin-level access cannot silently escalate to owner-level actions.
Mutation paths
Read paths are not enough. State-changing requests often skip the strictest checks.
- Retest update, delete, archive, invite, and restore calls directly.
- Check bulk actions and nested writes.
- Verify export, download, and report generation paths.
- Confirm the mutation handler owns the permission check server-side.
Evidence quality
Keep enough detail that another engineer can replay the issue without guessing.
- Save the baseline request and the mutated request.
- Record the actor, tenant, role, and object used for each replay.
- Capture status, body shape, object IDs, metadata, and row counts.
- Store the diff, screenshot, or artifact next to the finding.
Retest and close
Every finding should end with a clean retest path.
- Retest the same mismatch after the fix lands.
- Verify the response no longer leaks objects, counts, names, or metadata.
- Confirm exports, downloads, search, and background jobs stay scoped.
- Keep the final result easy to review in one place.
The review maps directly to the lab scenarios
The Agnite Security Lab shows how these checks look when they are played out as controlled SaaS request scenarios. It gives the review a scenario layer before the results are summarized as findings and reports.
See the scenario layer first
The lab keeps the boundary behavior visible without exposing raw internals or unsafe request dumps.
The review connects to the full proof sequence
Follow the proof path from controlled lab scenarios, to individual findings, to report packaging, and finally to the live SaaS security audit.
Agnite Security Lab
See how controlled SaaS boundary scenarios are modeled before they become findings.
Sample Findings
Review individual examples of request-level evidence, impact, and remediation direction.
Sample Audit Report
See how findings are packaged into a buyer-facing report for engineering and leadership review.
SaaS Security Audit
Request the live audit if you need these checks applied to your own SaaS system.
Link the checklist to the live audit paths
These are the service pages that map most closely to the checklist areas and the report preview.
API Authorization Audit
Request-level authorization checks across actors, tenants, roles, and object access.
Open auditTenant Isolation Audit
Boundary testing for tenant-scoped reads, lists, exports, and shared-resource access.
Open auditRBAC Audit
Role-based access control review for roles, permissions, admin paths, and exports.
Open auditIDOR Testing
Object-level replay testing across files, records, exports, and nested resources.
Open auditSample Audit Report
See how the checklist connects to a buyer-facing report preview.
View reportTurn the checklist into real audit evidence
The checklist shows what to review. A SaaS security audit proves what actually happens when requests are replayed across users, tenants, roles, exports, sessions, and mutations.