REST API Security Assessment: Where to Check Permissions and How to Accept Results

Consider a hypothetical scenario. A B2B invoicing platform exposes a REST API to its own web app, its mobile app and partner accounting systems. A partner integration authenticates correctly: the identity provider issues a token, the API gateway verifies its signature, audience and expiry, and requests are logged as authenticated. Because of a bug in its own code, the integration requests another customer's invoice, and the API returns it. The token is genuine, the caller is who it claims to be, and the gateway did its job. The failure is elsewhere: at the service layer, nobody asked whether this caller is allowed to see this particular object.

The same hypothetical platform shows two more gaps. An update request from a customer's user carries an extra field that marks an invoice as approved, and the service writes every field it receives. A nightly export job builds tenants' CSV files from a shared cache keyed only by report type. Every request was authenticated, yet the decisions about what may be read, changed or triggered were wrong, each time in a different place.

That is the core idea behind a useful REST API security assessment. Authentication answers "who is calling"; authorization answers "what may this caller do to this object, property and function, in this tenant, right now". A valid token or a green gateway dashboard says nothing about the second question. What follows shows how to scope around that distinction, test identity, authorization, tenant isolation and business flows safely, demand usable evidence and make buyer decisions.

What a REST API security assessment covers

A REST API security assessment is an authorized, structured examination of how an API identifies callers, what it allows each one to do, how it validates incoming data and how it protects the data it returns. A website scan is not enough: access decisions are made around resources, methods, tokens, properties and machine-to-machine clients. Nor is it a certification, an attestation or an assurance opinion. It is a point-in-time technical examination of an agreed scope, with evidence for what was tested and what was found.

Inventory: APIs, versions, environments and machine clients

The assessment starts with an inventory, because untested areas can create a false impression that no vulnerabilities exist. It includes documented and undocumented endpoints, every live API version including older ones kept for legacy clients, and every environment with real or realistic data: production, staging, sandbox and partner test tenants. Health, debug, admin and internal endpoints belong on the list even when they are "not meant to be public": reachability, not intent, decides exposure.

Machine clients — partner integrations, mobile apps, scheduled jobs, webhooks, internal services and service accounts with long-lived credentials — need their own entries: how each one authenticates, which scopes or roles it holds and which tenants it can act for. Implicit trust often accumulates in service-to-service traffic; that layer is covered in the article on microservices penetration testing and evidence-led scoping.

Scope statement and written authorization

A defensible scope statement is agreed before testing starts and names at least the following:

• API inventory: endpoints, versions and environments in scope, including how undocumented discoveries will be handled
• Identity model: authentication methods, token types, session handling, roles, tenants and machine clients
• Data classification: which resources hold personal, financial or operational data
• Exclusions and constraints: excluded third-party services, production limits, rate ceilings, the testing window and who can stop the test
• Authorization record: who approved the test, for what period and for which targets

Above all, the scope must be backed by written authorization from someone entitled to grant it. Nothing in this article implies permission to test systems you do not own or have not been authorized to assess.

Identity, sessions and token trust boundaries

REST APIs run on HTTP, which MDN describes as an application-layer, client-server protocol used both for machine-to-machine communication and for programmatic access to APIs. MDN calls HTTP stateless: the protocol itself does not link requests to one another. That is often misread. Server-side sessions are still possible, and a request does not have to carry the caller's complete identity: continuity is built on top of the protocol, and each request carries something the server can use to recognise the caller.

Cookies, tokens and session identifiers

Two approaches are common. In the first, the server keeps session state and gives the client an identifier, usually in a cookie; MDN explains that cookies add state through the Set-Cookie and Cookie headers. The identifier carries no permissions: it is a reference the server resolves to stored state on each request. In the second, the client presents a token, often in an Authorization header: an opaque token is looked up by the server or identity provider, while a self-contained token carries signed claims such as subject, audience, scopes and expiry that the API verifies locally.

The two models fail differently. Session identifiers must be unpredictable, live for a sensible time and be invalidated on logout and privilege change. For self-contained tokens, what matters is the signature, accepted algorithms and issuers, audience, expiry, revocation and the mapping from claims to permissions; CISA's Secure by Design materials are dedicated in part to protecting tokens and assertions from forgery, theft and misuse. In both models the credential proves at most who is calling, but it does not decide which object, property or function the caller may reach.

Where trust decisions are made

To find authorization gaps, map every point where the system makes a trust decision and establish what each one actually checks. The table is a starting point; the real map comes from the target architecture.

Authorization at object, property and function level

The OWASP API Security Top 10 2023 separates authorization into three distinct categories: broken object level authorization, broken object property level authorization and broken function level authorization. The list is an awareness document, and its order should not be read as a ranking of how often each problem occurs in a given estate. Its value for an assessment is the vocabulary: three different questions, each needing its own tests.

Object-level authorization

Object-level authorization asks whether the caller may act on this specific record; it is the gap in the opening scenario. Testers need at least two accounts per role and, in multi-tenant systems, accounts in at least two tenants. They confirm that each identity sees its own objects and is refused for others', across every method of the resource and every API version that serves it. Indirect paths need the same check: a parent object, a search filter, a report reference or an export link.

Property-level authorization and mass assignment

Property-level authorization asks whether the caller may read or write a specific field. On the way out, responses expose internal flags, other users' contact details or another role's pricing when a full object is serialized instead of a filtered view. On the way in, mass assignment happens when a service binds every field in the request body to its model, so the caller can set status, role, owner or approval properties the interface never offered. The assessment checks, for each role, which properties are returned and which supplied ones are accepted, ignored or rejected. The durable fix is explicit allow-lists of properties per role and operation, not a block-list of dangerous fields.

Function-level authorization

Function-level authorization asks whether the caller may invoke an operation at all. Administrative and bulk operations, approvals, impersonation, configuration changes and support tooling often live in the same API as ordinary functions, distinguished only by path or method. The assessment builds a role-to-function matrix from documentation and traffic and checks refusal outside each role's column, including undocumented methods and older API versions that lack a later permission check.

Tenant isolation across synchronous and asynchronous paths

In multi-tenant SaaS, tenant isolation is what buyers care about most, yet it is often tested too narrowly. A read endpoint that refuses another tenant's record is necessary but not sufficient: data also crosses tenant boundaries through paths that bypass visible read endpoints.

An assessment of tenant isolation should cover at least these paths:

• Exports and reports: files, scheduled reports and download links are scoped to the requesting tenant and do not work for another
• Background jobs and queues: work items carry explicit tenant context, and workers enforce it rather than trusting an identifier from the message
• Caches: keys for per-tenant or per-user data include tenant and, where relevant, permission context, so another tenant's result is never served
• Indirect references: search indexes, storage paths, webhooks, notification templates and embedded identifiers get the same ownership checks as direct reads
• Administrative and support paths: cross-tenant tooling is separated, logged and available only to the roles that need it

Asynchronous paths are harder to test because results appear later and elsewhere. The scope should therefore agree how jobs will be triggered and observed safely, for example in a test tenant with seeded data. Multi-tenant scoping is discussed more broadly in the guide to penetration testing for SaaS companies.

Business flows and resource consumption

The OWASP API Security Top 10 2023 lists unrestricted resource consumption and unrestricted access to sensitive business flows as separate categories. They are related but not the same, and an assessment should treat them separately.

Resource consumption is the cost of a request or a stream of requests: CPU, memory, storage, paid third-party calls, outbound messages and expensive queries. Checks cover pagination, payload and file sizes, batch sizes, query complexity, timeouts and rate ceilings per client, tenant and credential. Sensitive business flows are legitimate functions used at a scale or in a sequence the business never intended: bulk sign-ups, repeated discount and referral redemption, automated buying of limited stock, skipped approval steps. Every request can be authorized and still be part of a harmful flow.

Safe testing requires prior agreement: show a weak limit with the fewest requests needed, without exhausting resources, and ask the product owner what counts as abuse. How to scope that work is explained in the article on business logic security testing services.

The HTTP surface beyond the endpoint list

MDN's reference explains that a request method indicates the purpose of a request; GET and POST are the most common. For an assessor, what matters is which methods a resource actually accepts, not which ones are documented, and whether authorization is enforced consistently across all of them. A classic gap is a resource that is protected for reading but accepts an undocumented method that modifies data; it only shows up when methods are tested systematically.

MDN groups status codes into five classes, and how an API uses them is revealing: inconsistent responses disclose whether a resource exists, and server errors leak implementation details. MDN also documents Content-Type with MIME types and content negotiation through Accept, so the API's reaction to unexpected content types and formats is worth checking.

CORS determines which origins a browser permits to read API responses. It matters for browser clients, but does not replace server-side authorization or constrain an arbitrary non-browser client. According to MDN, conditional requests help prevent lost updates when several clients write at once, which makes them relevant to data integrity. WebSocket upgrades and proxied traffic should be explicitly in or out of scope. A compact checklist:

• Method coverage per resource, including undocumented methods
• Authentication requirements on every endpoint, including health, debug and legacy versions; public exceptions must be intentional and limited in the data and actions they expose
• CORS policy for endpoints used by browsers
• Token, session identifier and cookie handling, lifetime and revocation
• Security-relevant events logged in a form defenders can actually use

Method and yardsticks

Planning, execution and post-execution discipline

NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, was published in September 2008 and superseded SP 800-42 from 2003. Its purpose is to help organizations plan and conduct technical security tests and examinations, analyze findings and develop mitigation strategies. For an API engagement, that means process discipline: plan the work and the rules of engagement, execute the tests within those limits, and after execution analyze the results, turn them into mitigation and retest.

The guide describes techniques with their benefits and limitations rather than a complete program. An assessment should therefore combine techniques and state the limits of each, taking concrete checks from application-specific guidance, since the document predates most API tooling.

ASVS, WSTG, OWASP Top 10 lists and CWE

Those checks come from the OWASP Web Security Testing Guide (WSTG), whose authentication, authorization, session management and input validation areas apply directly to REST. State the WSTG version used: OWASP notes that versioned content reflects a point-in-time state.

The OWASP Application Security Verification Standard (ASVS) provides a basis for testing technical security controls and a list of secure development requirements, normalizing the coverage and rigor of verification. For buyers, it turns a vague promise to "test the API" into an agreed list of verifiable requirements. Identifiers can change between versions, so OWASP recommends version-pinned references such as v5.0.0-1.2.5 and treats an unversioned identifier as referring to the latest content. Lists are published in CSV, JSON and other formats, so results are easy to track per requirement and per API: pass, fail, not applicable.

The OWASP Top 10 for web applications and the OWASP API Security Top 10 are awareness documents: good for explaining priorities, but no substitute for a test plan, and checking only ten headings leaves gaps. MITRE's CWE, including the CWE Top 25 Most Dangerous Software Weaknesses, supplies root-cause vocabulary; CISA's Secure by Design alerts aim to eliminate whole vulnerability classes; and NIST Cybersecurity Framework 2.0 sets the risk-management outcomes in which assessment results are read. How to combine these references is shown in the article on application security audit from scope to decision.

Safe test data and production constraints

Test conditions carry real risk: authorization testing touches other people's data. Production is more realistic, but testing can affect availability and customers. Staging generally reduces risk to customers. How far its findings apply to production depends on differences in gateway rules, identity provider settings, feature flags and job schedules; those differences and the limits of the conclusions must be recorded.

Whichever environment is chosen, rules of engagement should define:

• Test accounts for each role and test tenants with synthetic data, so cross-tenant checks never require reading real customers' records
• Non-destructive limits: which write, delete and bulk operations are allowed, and on which objects
• Rate ceilings and time windows, especially for resource and business-flow tests
• Handling of real data seen by accident: minimal viewing, copying only what evidence requires, prompt notification
• An emergency stop: contacts on both sides and the conditions for pausing

Another trade-off is how much information testers get. Black-box testing resembles an outside attack but spends much time on discovery; specifications, an account per role and, where possible, source code raise coverage per day. Automation is broad and repeatable for known patterns, but authorization and logic flaws require knowing who may do what, which means a human tester working with several roles. Either way, results are a point-in-time snapshot, and the report should say so.

Evidence, retest and acceptance

NIST treats analyzing findings and developing mitigation strategies as part of testing itself. Each finding should include reproducible evidence; the affected endpoints, methods and versions; the roles and tenants used; a version-pinned ASVS reference where it applies; a CWE classification; a risk rating that reflects exposure and data sensitivity; a fix; and a retest result. Evidence should let an engineer reproduce the behaviour with test accounts and be sanitized of sensitive data.

The matrix below shows how a buyer can define acceptance before the engagement, so that "fixed" means the same thing to everyone.

The bigger payoff comes from root causes. According to MITRE, understanding common root causes feeds development and architectural planning and helps eliminate entire classes of defect. Turn repeated findings into shared authorization libraries, gateway policies, serializer defaults and regression tests, re-assess after new authentication flows, tenants or API versions, and track remediation time and recurrence. That loop is covered in the article on vulnerability remediation control and proving that fixes work.

Buyer decisions: scoping and choosing an API assessment

With the method and yardstick clear, choosing a provider is easier. CISA's Secure by Demand guide is intended for procurement discussions, and joint guidance from ASD's ACSC and CISA on choosing secure technologies emphasizes verifiability. The principle is the same here: ask providers to show how they work, not just describe it.

1. Inventory and authorizationList APIs, versions, environments and machine clients, then obtain written approval, rules of engagement and stop conditions.
2. Trust boundariesMark where identity, tokens, sessions and tenant context are checked and where services rely on someone else's check.
3. Authorization matrixPlan object, property and function tests across roles and tenants, including exports, jobs, caches and indirect references.
4. Safe executionTest on synthetic tenants within agreed limits, combining automated breadth with manual authorization testing.
5. Evidence and retestAccept findings against the evidence matrix, confirm fixes by retest and lock recurring causes into regression tests.

Questions to ask a provider

• Which WSTG version and ASVS requirements will define coverage, and how will planning, execution and reporting work?
• How many accounts, roles and tenants are needed to test object, property and function authorization?
• How will tenant isolation be tested in exports, background jobs, caches and indirect references, not only in reads?
• Can we see a redacted sample report, the retest policy and the rules for production work, including accidental access to real data and emergency stops?

Warning signs

• Raw scanner output relabelled as a penetration test
• An OWASP Top 10 list used as the only checklist
• References to standards without version numbers
• No discussion of authorization testing across multiple roles and tenants
• Language that presents the assessment as certification, attestation or a guarantee of security
• Reluctance to put written authorization and scope in place before testing

Verify claims about certifications, customers and results independently. Internet exposure, sensitive data and multi-tenancy justify deeper manual authorization testing and a broader selection of ASVS requirements; internal low-sensitivity APIs can start with automation plus a focused manual review of authentication and authorization. Record the depth in writing before work starts so results can be compared across releases and providers. To do that, you can prepare your pentest scope with Pentest.red and agree systems, access, constraints and expected evidence in advance.

What You Should Have After an API Assessment

A REST API security assessment is useful when it is authorized, planned and evidence-led, and when it does not mistake a successful login for correct access. NIST SP 800-115 supplies process discipline, WSTG test cases, ASVS version-pinned requirements, the OWASP API Security Top 10 2023 vocabulary for object, property and function authorization, resource consumption and business flows, and CWE root-cause language. Together with an inventory, a trust-boundary map, tenant-isolation tests across jobs, exports and caches, and a retest loop, they show the depth of testing, confirmed issues and retest results for the tested API version. Subsequent changes require further observation and, where appropriate, reassessment.