Focused RBAC Audit

SaaS RBAC Audit

Test whether roles and permissions are enforced by the backend, not only represented in the UI. We replay real API requests as lower roles, changed users, or different tenants and compare whether the same action still slips through. If role checks and tenant boundaries need to be tested together across live workflows, use the broader [tenant isolation and RBAC audit](/saas-security-audit/multi-tenant-security-audit/).

Request-level evidence Severity ratings Retest checklist From €750

Review RBAC risk

View broader security audit

Evidence Example

What evidence proves RBAC failed?

RBAC findings need request-level proof, not screenshots of hidden buttons or role tables. We document the baseline request, the lower-role replay, the role and permission state used, the expected result, the actual result, the side-effect diff, and the business risk.

Valid tenant request

PATCH /api/projects/4821/settings

Admin updates project settings and receives the expected success response.

Tenant mismatch

PATCH /api/projects/4821/settings

Unsafe result

200 OK, settings changed, or restricted data returned

Risk: This is RBAC failure because the request is valid, but the lower role should not be able to perform the action.

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 RBAC Audit

For one role-sensitive workflow or permission area

A targeted review for one workflow where role enforcement has to be proven under mismatch.

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

PROJECT INVESTMENT

From €750

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

What's included

3 to 5 critical role flows
Role downgrade testing
Action-level permission checks

Response and side-effect evidence
Reproduction steps for engineering
Remediation direction

Review RBAC risk

SaaS Permission Model Audit Most relevant

For products with roles, teams, tenants, custom permissions, exports, or support access

The most relevant option when the permission model is spread across multiple roles, object types, and internal workflows.

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

PROJECT INVESTMENT

From €1,500

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

What's included

Multiple roles and user types
Tenant and object boundary checks
Admin, support, export, and bulk action testing

Evidence-backed findings
Risk ranking and fix guidance
Retest checklist included

Review permission model risk

Full SaaS Security Audit

For broader runtime security validation

A broader audit path when RBAC is only one part of the risk picture and the API needs wider runtime validation.

Best when RBAC, API authorization, tenant isolation, 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 wider security pass.

What's included

RBAC review
API authorization testing
Tenant isolation and audit log review

API key and rate limit review
Broader findings summary
Optional implementation support

View audit

TRIGGERS

Signs the audit is worth doing now

This is most useful when role boundaries already matter to customers, support staff, or internal workflows and the product has grown beyond one simple permission tier.

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

RBAC bugs hide inside normal SaaS behavior

Role labels, team membership, and permissions can look correct in the UI or database while the API still allows a lower-privilege user to repeat the same request. That drift is common when permissions are split across frontend logic, policies, services, and queries.

COMMON LEAK PATHS

Role labels are shown in the UI, but the backend does not enforce the same rule on the request.
Inherited permissions and tenant roles are assumed to be safe without direct replay testing.
Support and admin paths gradually widen as more operational workflows are added.
Action-level checks drift over time as controllers, services, and database logic evolve separately.

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 only approved user paths and does not replay the same request as a lower role.
Logs show a successful request, not whether the caller should have been blocked from the action.
Infra scanning cannot verify role enforcement, object ownership, or response differences by role.
Frontend gating can hide the problem 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 RBAC audit checks

We focus on the places where a role model can look correct on paper but still fail when the request is replayed with a different privilege level, permission set, or tenant scope.

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

RBAC Failure

What counts as an RBAC failure?

An RBAC failure is not only a viewer clicking an admin button. It is any case where the backend accepts an action, returns data, or changes state that the caller's role should not allow.

Viewer can update restricted settings

A lower role submits the same request and the backend still allows a change it should block.

Member can invite, remove, or approve users

Membership actions should be role-gated, but the API still accepts them directly.

Manager can access owner-only billing or security settings

The role model says no, but the API returns the data anyway.

Support role sees too much customer data

Internal tools or support paths expose more than the intended boundary allows.

Custom role skips backend checks

A bespoke permission set misses a code path that the default roles covered.

Role downgrade does not remove old access

A changed user keeps permissions that should have been revoked.

Export endpoint ignores role permissions

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

Bulk action skips per-object permission checks

One allowed item lets the whole batch proceed across blocked objects.

Route checks role but not object ownership

The route is allowed, but the specific object still needs its own ownership decision.

Response includes fields hidden from that role

The backend returns restricted metadata or object details even though access should be limited.

For the design side, see RBAC Design in SaaS, Authorization Testing Checklist, and the broader Broken Access Control Audit.

HOW WE PROVE IT

How the audit works in practice

The goal is to prove the failure path with repeatable request pairs and enough detail for engineering to fix the issue without guessing.

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 roles and protected actions

We identify the role matrix, permission tiers, and actions that matter to the product and its buyers.

Collect baseline allowed requests

We capture a request that should succeed for the rightful role before any mutation is introduced.

Replay as a lower role

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

Test actions, reads, and exports

We compare permission behavior across mutations, reads, exports, and nested resource routes.

Compare responses and side effects

We check status codes, response bodies, returned fields, and actual state changes rather than trusting the UI.

Classify by business risk

We separate low-impact drift from real permission failure so the team can prioritize the highest-risk paths first.

Common Failures

Common RBAC failures we look for

These are the recurring failure modes that show up when the role model looks right in the UI but not in the live API.

Viewer can update restricted settings

A lower role sends the same request and the backend still allows a change it should block.

Member can invite or remove users

The membership action should be role-gated, but the API still accepts it directly.

Manager can access owner-only billing data

The role model says no, but the API returns the data anyway.

Support role sees more than intended

Internal tools or support paths expose more customer data than the intended boundary allows.

UI role change does not change API access

The frontend updates the label, but the backend still behaves like the old role is active.

Custom role misses a backend check

A bespoke permission set skips a code path that the default roles covered.

Export endpoint ignores role permission

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

Bulk action skips per-object checks

One allowed item lets the whole batch proceed across objects that should be blocked.

Route policy checks role but not ownership

The route is allowed, but the specific object or action still needs a separate ownership 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 generic vulnerability scanning. 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 uses a permission model that customers, support teams, or internal workflows depend on.

SaaS founders

You need proof that the permission model is real before enterprise buyers ask for it.

CTOs

You need to know whether the backend actually enforces the role model the platform assumes.

Engineering leads

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

Enterprise-ready teams

Security review conversations often focus on roles, permissions, exports, and admin access proof.

Teams with custom roles or permission tiers

Custom permissions and tenant roles are easy places for drift to appear in backend enforcement.

Teams handling sensitive workflows

Billing, documents, reports, approvals, analytics, admin panels, and internal workflows all need strict access 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 RBAC testing or the broader security audit.

What is an RBAC audit?

It is a focused review of whether the backend actually enforces role-based access control across live API requests, not just in the UI or database.

Is RBAC the same as authorization?

RBAC is one way to implement authorization. Authorization is the broader concept, while RBAC is the role-based model that should enforce it for many actions.

Can the UI show correct roles while the API is still unsafe?

Yes. That is a common failure mode. The UI can hide a button, but the backend may still accept the same request directly.

Do you test custom roles?

Yes. Custom roles are a common source of drift because they often miss checks that the default roles already covered.

Do you need source code?

Not always. We can start from live requests and responses. Source access helps when the issue points to policies, services, or query logic.

Can this find broken access control issues?

Yes. RBAC failures are often a form of broken access control when the lower-privilege user can still perform the restricted action.

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 role boundary now holds.

Final CTA

Test the permission boundary before customers find the gap.

If your SaaS app uses roles, exports, admin tools, or object-level permissions, this is the place to prove the boundary actually holds.

Review RBAC risk View broader security audit