Focused SaaS Security Audit

IDOR Testing for SaaS

Test whether changing object IDs, file IDs, report IDs, or nested resource IDs lets one user access another user's data. We swap the ID, actor, or tenant context and verify whether the backend still returns the wrong resource.

Request-level evidence Severity ratings Retest checklist From €750

Request IDOR testing

View broader security audit

Evidence Example

Proof that the same object becomes unsafe under mismatch

A valid response for the rightful owner does not prove the resource is safe. We replay the request under a different account or tenant and compare what comes back.

Valid tenant request

GET /api/files/file_8842

User A opens a file they own and receives the expected metadata and download options.

Tenant mismatch

GET /api/files/file_8842

Unsafe result

200 OK with another user's file metadata, download URL, invoice, report, or record

Risk: This is IDOR or broken object-level authorization because the API trusts the object ID without proving ownership.

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 evidence, 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 IDOR Test

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

A targeted review for one object family where ownership has to be proven under mismatch.

Best when one object 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
ID mutation testing
Ownership mismatch checks

Response evidence
Reproduction steps for engineering
Remediation direction

Request testing

SaaS Object Authorization Audit Most relevant

For products with files, records, reports, invoices, tenants, workspaces, or exports

The most relevant option when multiple object types, owners, and download paths 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 authorization review with practical risk classification.

What's included

Multiple object types
User, role, and tenant mismatch testing
Nested resource and export checks

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

Request testing

Full SaaS Security Audit

For broader runtime security validation

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

Best when IDOR, BOLA, 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 access path and the system needs a wider security pass.

What's included

IDOR and BOLA testing
API authorization testing
Tenant isolation and RBAC review

Audit log review
Broader findings summary
Optional implementation support

View audit

TRIGGERS

Signs the testing is worth doing now

This is most useful when the product already exposes object identifiers and the same API surface serves multiple customers, roles, or workspaces.

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

IDOR bugs hide inside normal SaaS request flow

The API can look healthy, the session can be valid, and the response can still expose an object that belongs to someone else. That is why IDOR issues are so easy to miss in products with shared data, downloads, and nested resources.

COMMON LEAK PATHS

Object IDs appear in routes, responses, exports, or client state and are trusted too much by the backend.
File IDs, report IDs, invoice IDs, and record IDs can be replayed across users or tenants.
Nested resources are checked at the parent level but never revalidated at the child level.
Frontend controls hide actions, while the backend still accepts the copied request 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 typically uses the rightful account and does not replay the same object request under another actor.
Logs show a successful request, not whether the object belonged to the caller.
Infra scanning cannot verify ownership checks, file download rules, or response overexposure.
Static analysis may find risky patterns, but it cannot prove the live API response is safe.

AUDIT RESPONSE

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

WHAT WE TEST

What the IDOR test checks

We focus on the exact failure paths that let a valid user reach an object they should not own or view.

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 that engineering can replay during remediation.

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 which objects matter, how they are owned, and which routes resolve them in the live API.

Collect baseline requests

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

Mutate IDs and context

We change file IDs, report IDs, tenant IDs, nested IDs, or actor context to test the boundary.

Replay as another user or tenant

We send the same request from a different account, role, or workspace to see whether object ownership is enforced.

Compare response and download behavior

We check status codes, response bodies, metadata, and download results instead of trusting route success.

Classify by exposure risk

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

Common Failures

Common IDOR failures we look for

These are the recurring failure modes that show up when object IDs are trusted more than ownership rules.

Another user's file opens

The file ID is reused from a different account and the file still returns.

Invoice ID exposes another account

A billing record is fetched directly even though it belongs to a different customer.

Export ignores ownership

An export or report download returns data from an object that the caller should not control.

Nested child object skips parent check

The parent object is valid, but the child object should still need its own ownership check.

Signed download link can be reused

A link that should stay scoped to one user or object can be reused in the wrong context.

Deleted object still returns

A direct ID still resolves an object that should no longer be reachable through normal access.

List endpoint leaks object IDs

Search or list results expose IDs that can be reused to fetch data outside the caller's boundary.

Alternate route bypasses ownership

One endpoint checks ownership, but another path that resolves the same record does not.

Predictable numeric IDs make replay easier

Sequential IDs or weak patterns make the object boundary easier to probe and confirm.

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 broad compliance review.

Who Should Care

Who should care about this audit

It matters most when the product already carries customer files, records, or exports that should never cross object boundaries.

SaaS founders

You need proof that customer objects do not leak when the product adds sharing or collaboration features.

CTOs

You need to know whether object access is enforced in the backend or only assumed from the UI.

Engineering leads

You need a concrete test matrix, a fix path, and a way to retest the resource after remediation.

Enterprise review teams

Security questionnaires often ask for object-level proof across files, invoices, reports, and downloads.

Teams handling sensitive data

Customer files, records, invoices, reports, analytics, documents, and exports need strong ownership checks.

Teams with collaboration features

Shared workspaces, teams, organizations, and tenant features increase the risk of IDOR and BOLA style bugs.

Related proof/resources

Open audit path

Proof hub

Open the supporting proof pages

Review the sample report, sample findings, release checklist, and security lab that sit behind this audit path.

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 test

Short answers for teams deciding whether they need focused IDOR testing or the broader security audit.

What is IDOR in a SaaS API?

IDOR is a broken object-level authorization issue where a user can replay an object ID and access a file, record, or resource they do not own.

Is IDOR the same as BOLA?

They are closely related. BOLA is the broader broken object-level authorization term, while IDOR usually refers to the identifier-driven version of the same failure.

Can this happen even if authentication works?

Yes. Authentication proves who the caller is. IDOR happens when that authenticated caller can still reach another user's object.

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 object lookup code.

Do you test files and exports?

Yes. Files, reports, downloads, exports, and signed URLs are common places where object ownership drift shows up.

Can this find cross-tenant leaks?

Yes. We test the same object across users, workspaces, and tenants to see whether the boundary still holds.

What do we receive after testing?

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

Final CTA

Test the object boundary before customers find the gap.

If your SaaS API exposes files, reports, invoices, or nested resources, this is the place to prove the object boundary actually holds.

Request IDOR testing View broader security audit