Focused SaaS Security Audit

Broken Access Control Audit

Test whether your SaaS backend actually blocks users from objects, actions, roles, or tenant data they should not reach. We replay valid requests with a lower role, the wrong user, or the wrong tenant and verify whether the API still allows the action.

Request-level evidence Severity ratings Retest checklist From €750

Request access control audit

View broader security audit

Evidence Example

Proof that the same action becomes unsafe under mismatch

A valid response for the owner does not prove the endpoint is safe. We replay the same action with the wrong user, lower role, or wrong tenant and compare what the API does.

Valid tenant request

POST /api/projects/4821/archive

Project owner archives the project and receives the expected success response.

Tenant mismatch

POST /api/projects/4821/archive

Unsafe result

200 OK, archived project state changed, or an unauthorized project record is returned

Risk: This is broken access control because the request is valid, but the action should not be allowed for that actor.

WHAT THIS PROVES

The tenant boundary failed under request replay. You receive the request pair, response evidence, severity rating, fix direction, and retest checklist.

DELIVERABLES

What you receive from the audit

The output is written for engineering and buyers who need clear proof, not generic findings language.

Evidence Package

Executive summary
Tenant boundary risk map
Affected endpoint list
Baseline and mutated request pairs
Cross-tenant evidence
Response diffs and side effects

Engineering Handoff

Severity ratings
Remediation guidance
Retest checklist
Audit log gaps if relevant
Optional architecture notes
Recommended next steps

Pricing

Pricing for focused and broader authorization audits

Start with a narrow workflow review or move into the broader audit when roles, tenants, exports, or support access make the boundary more complex.

Focused Access Control Audit

For one high-risk workflow or permission area

A targeted review for one endpoint group, object path, or workflow where access control has to be proven under mismatch.

Best when one workflow is the highest-risk gap and you need a quick evidence review.

PROJECT INVESTMENT

From �750

Includes 3 to 5 critical flows, evidence-backed findings, and fix direction for the chosen surface.

What's included

3 to 5 critical flows
Role and object mismatch testing
Action-level permission checks

Short audit summary
Reproduction steps for engineering
Remediation direction

Request audit

SaaS Broken Access Control Audit Most relevant

For products with roles, teams, tenants, exports, admin tools, or support access

The most relevant option when multiple permission levels and object types share the same API surface.

Use this when the product has enough access-control complexity that a single workflow review is not enough.

PROJECT INVESTMENT

From �1,500

Most relevant for SaaS teams that need a broader access control review with practical risk classification.

What's included

Multiple users and roles
Horizontal and vertical access testing
List, export, nested resource, and bulk action checks

Baseline and mutated request evidence
Risk ranking and fix guidance
Retest checklist included

Request audit

Full SaaS Security Audit

For broader runtime security validation

A broader audit path when broken access control is only one part of the risk picture and the API needs a wider review.

Best when tenant isolation, API authorization, RBAC, audit logs, and general API risk all need to be reviewed together.

PROJECT INVESTMENT

From �3,000+

Use this when the issue spans more than one access path and the system needs a broader review.

What's included

Broken access control testing
API authorization testing
Tenant isolation and RBAC review

Audit log review
Broader findings summary
Optional implementation support

View audit

TRIGGERS

Signals the audit is worth doing now

This is most useful when the product already has roles, customer data, and action boundaries that matter to real buyers.

COMMON TRIGGERS

A quick checklist for boundary risk

Multiple companies, workspaces, or organizations share the same product
Shared schema, shared infrastructure, or tenant context passes through code
Exports, reports, files, or analytics are tenant-scoped
Background jobs process customer data
Support or admin users can access customer accounts
Customers ask how tenant isolation is proven

BUYER PROOF

Request It Before Buyers Ask

Use this audit before a security review, enterprise sale, customer questionnaire, or tenant-sensitive release.

You get request-level evidence, risk ranking, fix guidance, and a retest checklist your team can use directly.

Request Audit Scope View Sample Report

PROBLEM

Access control bugs hide behind valid sessions and familiar UI

Broken access control often only appears when the request is replayed outside the happy path. The backend can keep returning success while the caller reaches actions or objects that should stay blocked.

COMMON LEAK PATHS

Role labels exist in the UI, but the backend does not enforce the same check on the request.
Object ownership is assumed from the route, not checked against the authenticated caller.
Tenant IDs and workspace scopes drift in controller, service, or query code.
Admin and support routes grow broader than intended as the product evolves.

WHY NORMAL CHECKS MISS IT

Normal Checks Do Not Replay Context

QA, logs, and infrastructure scans often confirm that a request succeeded. They do not prove the returned object, export, cache entry, or background job result belonged to the right tenant.

QA usually tests approved flows and does not retry the request as a lower role or different user.
Logs show a successful request, not whether the action belonged to the caller.
Infra scanning cannot verify object ownership, permission checks, or backend response behavior.
Frontend gating can hide the bug while the API still accepts the request directly.

AUDIT RESPONSE

The audit replays tenant-sensitive requests across changed actor, tenant, role, object, and workflow context.

WHAT WE TEST

What the access control audit checks

We focus on the exact failure paths that let a valid user reach a blocked action, object, or customer record.

Tenant Boundary Coverage

API and object access

Tenant-scoped API reads
Tenant-scoped list and search
Nested resources
Shared schema tenant filters
Joins and includes
Cross-tenant object ID reuse
Bulk update and delete

Roles and admin workflows

RBAC and role drift
Admin and support access
Tenant switching logic

Exports and data output

Export and download scope
Shared report or analytics endpoint leaks metadata
Response overexposure

Jobs, queues, and caches

Cache key isolation
Background job tenant context
Queue and scheduled job boundaries

Evidence and traceability

Audit log tenant context
Data residency assumptions
Response and side-effect evidence

AUDIT FOCUS

High-Risk Paths First

The audit follows requests, objects, roles, exports, jobs, caches, and admin workflows to find where tenant context breaks.

Changed tenant context
Changed actor or role
Changed object ownership
Changed workflow path
Response and side effects checked

Request Audit Scope

HOW WE PROVE IT

How the audit works in practice

The goal is to prove the failure path with repeatable request pairs so the fix is clear and the risk is easy to explain.

PROCESS

How the audit proves access control issues

We compare valid requests against changed tenant, actor, role, token, and object context. The result is clear evidence of where access control holds, where it fails, and which paths should be fixed first.

TIMELINE

How we test tenant boundaries

Map users, roles, tenants, and objects

We identify the permission model and the object types that matter so the test matrix matches the real product.

Capture baseline allowed requests

We record a request that should succeed for the rightful owner or permitted role before we change anything.

Replay as a lower role or wrong user

We send the request under weaker privileges to see whether the backend still accepts the action.

Replay under a different tenant

We verify whether tenant scope holds when the same route, object ID, or action is exercised from another account.

Compare status, side effects, and payloads

We check whether the response, object state, or returned data changes when the actor context changes.

Classify by risk and exploitability

We separate low-impact drift from real access control failure so the team can fix the most dangerous path first.

Common Failures

Common broken access control failures we look for

These are the failure modes that show up when the backend trusts the wrong context or only checks part of the request.

Viewer can edit or delete

A lower role sends the request and the backend still accepts a mutation it should block.

Member can reach admin routes

The route is hidden in the UI, but the API still accepts it when replayed directly.

User can read another user's object

The request is authenticated, but the object belongs to someone else and still comes back.

Role checked in UI only

The frontend hides the action, but the backend never enforces the same rule.

Bulk action skips per-object checks

One valid item in the batch can let the entire operation proceed across objects that should be blocked.

Export endpoint ignores the permission model

CSV, PDF, report, or download routes return data the caller should not be able to export.

Support role sees too much

Internal support or admin tooling exposes more customer data than intended.

Route policy allows access, object owner is never checked

The route is reachable, but the specific object or action still needs a separate permission decision.

Comparison

Why this is not another multi-tenant security guide

Guides explain how tenant isolation should work. This audit tests whether your SaaS actually enforces it across real requests, roles, exports, jobs, caches, and admin workflows.

Guides / generic scanners

Explain common risks.

Give general advice.

May miss tenant-specific business logic.

Do not prove your live tenant boundary.

Do not provide reproducible request pairs.

Agnite tenant boundary audit

Tests your SaaS flows directly.

Replays requests across tenant, actor, role, and object context.

Compares real responses and side effects.

Provides evidence, severity, reproduction steps, and fix guidance.

Includes a retest checklist your team can rerun after fixes.

What this is not

Not a generic vulnerability scan. Not only authentication review. Not only source code review. Not infrastructure scanning. Not a broad compliance checklist.

Who Should Care

Who should care about this audit

It matters most when the product already handles customer data, shared workflows, or permissioned actions that can cross an account.

SaaS founders

You need proof that customer data and actions stay inside the right account as the product grows.

CTOs

You need to know whether the backend actually enforces the rules the platform design assumes.

Engineering leads

You need a concrete audit target, a fix path, and a way to retest the flow after the change.

Teams preparing for enterprise customers

Security review conversations often focus on object ownership, tenant boundaries, and admin access proof.

Teams with role-based access

Owner, admin, manager, member, viewer, and support flows need backend checks, not just UI labels.

Teams handling sensitive workflows

Customer records, files, approvals, invoices, reports, and internal workflows all need strict action checks.

Related proof/resources

OPEN REPORT

Sample Audit Report

Open a polished example report showing the audit scope, tested authorization paths, risk summary, and recommended fixes.

Open report

VIEW FINDINGS

Sample Findings

Review 10 realistic SaaS security findings, including tenant isolation failures, broken role checks, exposed object access, and unsafe data responses.

View findings

OPEN CHECKLIST

Audit Checklist

Use the same checklist to review object access, tenant boundaries, RBAC rules, exports, webhooks, and sensitive response data before release.

Open checklist

OPEN LAB

Security Lab

See the lab scenarios behind the report, including how cross tenant access, IDOR, RBAC gaps, and audit logging issues are tested.

Open lab

FAQ

Questions buyers ask before they book the audit

Short answers for teams deciding whether they need targeted access control testing or the broader security audit.

Is this the same as API authorization testing?

It overlaps heavily, but this page is broader. It covers actions, object ownership, roles, tenants, and permission boundaries across the live API.

What is broken access control in SaaS?

It is when an authenticated user can reach an object, action, or customer area they should not be allowed to access. The API accepts the request, but the permission check is wrong or incomplete.

Can a user be authenticated and still trigger a finding?

Yes. That is the point of the audit. Authentication proves who the user is. Broken access control is about what that user can actually do or reach.

Do you test frontend permissions?

We use the frontend as context, but we do not rely on it. The real test is whether the backend still accepts the request when it is sent directly.

Do you need source code?

Not always. We can start from live requests and responses. Source access helps when the failure points to query logic, service boundaries, or permission drift in code.

Can this find BOLA or IDOR issues?

Yes. Broken access control testing often surfaces BOLA and IDOR style issues when object IDs, ownership checks, or tenant boundaries are missing.

What do we receive after the audit?

You receive findings, reproduction steps, evidence, risk explanations, and remediation guidance. If the issue is structural, the report will also point to the broader system changes that should follow.

Can you retest after fixes?

Yes. The same baseline and mutated requests can be replayed after remediation to confirm the access check now holds.

Final CTA

Test the access check before customers find the gap.

If your SaaS API handles shared objects, permissioned actions, or tenant-specific data, this is where you prove the control holds.

Request access control audit View broader security audit