Focused SaaS Security Audit

Object-Level Authorization Audit

Test whether each returned resource actually belongs to the caller's allowed user, tenant, role, or workspace context. We replay valid routes with the wrong user, lower role, or different tenant and compare what the API returns at the resource layer.

Request-level evidence Severity ratings Retest checklist From €750

Request object-level audit

View broader security audit

Evidence Example

Proof that an allowed path can still return the wrong resource

A valid response for the rightful owner does not prove the path is safe. We replay the route under another user or tenant and compare what comes back.

Valid tenant request

GET /api/accounts/acc_1842/documents/doc_8842

User A opens a document inside their own account and gets the expected object response.

Tenant mismatch

GET /api/accounts/acc_1842/documents/doc_8842

Unsafe result

200 OK with another user's document, metadata, download link, report, invoice, or internal record

Risk: This is object-level authorization failure because the path is allowed, but the returned resource should not be.

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 Object Authorization Audit

For one object type, file flow, or high-risk workflow

A targeted review for one resource family where ownership has to be proven in live requests.

Best when one flow is the highest-risk gap and you need fast proof on it.

PROJECT INVESTMENT

From €750

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

What's included

3 to 5 critical object flows
Object ownership mismatch testing
Nested route checks

Evidence-backed findings
Reproduction notes
Remediation direction

Request audit

SaaS Object-Level Access Audit Most relevant

For products with records, files, reports, tenants, roles, exports, or nested resources

The most relevant option when multiple object types, download paths, and tenant scopes share the same API surface.

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

PROJECT INVESTMENT

From €1,500

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

What's included

Multiple object types
User, role, and tenant mismatch testing
List, export, download, and alternate route checks

Risk ranking and fix guidance
Retest checklist included

Request audit

Full SaaS Security Audit

For broader runtime security validation

A broader audit path when object-level authorization is only one part of the risk picture and the system needs wider runtime validation.

Best when object-level authorization, API authorization, tenant isolation, 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 control area and the system needs a wider security pass.

What's included

Object-level authorization testing
API authorization testing
Tenant isolation and RBAC review

Audit log review
Broader findings summary
Optional implementation support

View audit

TRIGGERS

Signs the audit is worth doing now

This is most useful when object IDs are visible and multiple customers, roles, or workspaces can access overlapping route patterns.

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

Object-level authorization bugs hide inside normal SaaS APIs

A SaaS API can look correctly protected at the route level while still returning someone else's resource. That is why these issues often sit behind files, exports, nested resources, and alternate routes where the wrong resource is fetched after the request has already been approved.

COMMON LEAK PATHS

Route permissions are checked, but ownership is not verified before the resource is returned.
Nested resource lookups can trust the parent route and skip the child check.
Tenant IDs, file IDs, record IDs, and export IDs are exposed but not consistently enforced.
Frontend controls hide the action, while the backend still returns the resource directly.

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 uses the rightful account and does not replay the approved route under another user or tenant.
Logs show a successful request, not whether the returned object belonged to the caller.
Infrastructure scanning cannot verify object ownership or response-level leakage.
Static analysis can hint at risky paths, but it cannot prove the live response is safe under mismatch.

AUDIT RESPONSE

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

WHAT WE TEST

What the audit checks

We focus on the exact places where a route can be allowed while the returned resource is still unauthorized.

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 request pairs and object comparisons so engineering can fix the issue without guesswork.

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 object types and ownership rules

We identify the files, records, reports, exports, and nested objects that matter to the product.

Collect baseline valid object requests

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

Replay as the wrong user or tenant

We send the approved request under a different actor, role, or tenant and compare the result.

Test nested, alternate, list, export, and download routes

We inspect the other routes that might resolve the same resource through a different code path.

Compare status, payload, metadata, and side effects

We check whether the response body, metadata, or download behavior reveals the wrong object.

Classify by exposure risk

We separate harmless drift from real object exposure so the team can prioritize the highest-risk paths first.

Provide reproduction and remediation guidance

We document the exact replay pair and the fix direction needed to close the resource check.

Common Failures

Common object-level authorization failures we look for

These are the recurring failure modes that show up when a valid path returns the wrong resource.

Route allows access, resource belongs to another user

The endpoint is reachable, but the returned document or record belongs to someone else.

Parent resource is checked, child resource is not

The parent route looks safe, but the nested object still needs its own ownership check.

Report export returns another account's data

The generated output crosses customer boundaries even when the route itself looks normal.

File metadata is hidden but download URL still works

The API masks the object in one place but still exposes the downloadable resource elsewhere.

List endpoint reveals replayable object IDs

Search or list results expose IDs or links that can be reused in direct object requests.

Support role bypasses object ownership

Privileged access is broader than intended and can cross customer boundaries.

Lower role can read or update restricted object

The role model exists, but the backend does not enforce it at the object layer.

Archived object still returns through direct ID

The object should be hidden or closed, but a direct route still exposes it.

Alternate endpoint exposes the same resource without checks

One path is safe, but another route that resolves the same resource skips the validation step.

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 route permission review. Not only authentication review. Not only source code review. Not infrastructure scanning.

Who Should Care

Who should care about this audit

It matters most when the product already exposes customer objects that should never cross account boundaries.

SaaS founders

You need proof that customer objects stay inside the right boundary as the product grows.

CTOs

You need to know whether object-level checks are real across APIs, downloads, exports, and nested routes.

Engineering leads

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

Enterprise review teams

Security conversations often focus on BOLA, IDOR, broken access control, and resource-level proof.

Teams handling customer records

Documents, invoices, analytics, reports, files, and exports all need object-aware enforcement.

Teams with complex hierarchies

Organizations, workspaces, teams, and nested account structures increase object-level risk.

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 focused object-level testing or the broader security audit.

What is object-level authorization?

It is the control that decides whether the caller can access the specific object returned by an API route, not just whether the route itself is reachable.

Is this the same as IDOR or BOLA testing?

It overlaps heavily. IDOR and BOLA are common object-level authorization failures, and this audit is designed to find that class of problem in live SaaS APIs.

Can route permissions pass while object authorization fails?

Yes. That is one of the main failure modes we test. A route can be allowed while the returned object still belongs to someone else.

Do you need source code?

Not always. We can start from live requests and responses. Source access helps when the issue points to query logic, route handlers, or ownership checks in code.

Do you test files and exports?

Yes. Files, reports, downloads, exports, and nested resources are common places where object-level checks drift.

Can this find cross-tenant leaks?

Yes. We test the same resource across users, tenants, and workspaces to see whether the access rule still holds.

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 resource check now holds.

Final CTA

Test the resource layer before customers find the gap.

If your SaaS platform exposes files, records, reports, exports, or nested resources, this is where you prove the access rule holds.

Request object-level audit View broader security audit