REST API security testing

Why REST API security testing is required before launch or audit

If a compliance framework, a customer security review, an insurer or a launch checklist asks for REST API security testing, the test should check whether one caller can reach data or functions that belong to another caller, which scanners routinely miss. A REST API test measures the API against the OWASP API Security Top 10 2023, with most of the effort going to broken object level authorization (API1) and broken function level authorization (API5), followed by broken object property level authorization (API3), unrestricted resource consumption (API4), unrestricted access to sensitive business flows (API6) and undocumented endpoints under improper inventory management (API9). Authorization flaws are hard for automated tools because they depend on who the caller is, which object they own and which role they hold, so a scanner has no way to know that one customer's record should be invisible to another.

The OWASP Web Security Testing Guide has an API testing category, and ASVS chapter V4, API and Web Service, gives reference requirements for the same concerns. ASVS 5.0.0 says automated DAST and SAST tools cannot fully verify many access control and business logic requirements, and it favors documentation or source led testing. For the buyer, this means the test needs an OpenAPI or equivalent specification where one exists, a list of endpoints found outside the documentation, and at least two test accounts with different roles and tenants. Confirm with your provider whether they will also test with a valid account at each privilege level and whether they will check the API gateway and any undocumented versions, such as older paths still reachable in production.

Before commissioning the test, decide which framework the evidence will serve. PCI DSS requirement 11.4.1 requires application-layer testing that covers attacks such as manipulation of APIs to bypass application features, so an API in a cardholder data path must be in scope. An ASVS-based verification report lists the requirements checked and any that do not apply, which is more useful to an auditor than a list of findings alone. Ask the provider how their report will map findings to the framework you need, and what they will retest after fixes are deployed.

What can be in scope for a REST API test

Scope decides which endpoints, roles and environments a REST API test can actually reach, so it shapes both coverage and effort. The cards below cover the decisions to settle in writing before testing starts, and why each one changes what the findings can be trusted to say.

Which APIs and versions

Confirm which API versions, gateways and services are in the test, including deprecated versions that still accept traffic. Each version can carry its own authorization logic and validation rules, so a test of the current version alone can miss live exposure. Ask the client to list every base path, and mark any version that is retired but still reachable as in scope or explicitly excluded.

Target environment choice

Staging, production-like and production environments differ in data, configuration and integrations, so findings from one do not always hold in another. Production testing shows real exposure but needs tighter controls on data and load. Ask whether the environment matches production authentication, gateway rules and feature flags, and record any differences in the scope document.

Roles and test accounts

Object and function level authorization problems only show up when the tester holds several roles, such as anonymous, standard user, administrator and partner. Each role needs its own account with realistic data ownership. Agree in writing how many accounts are provided, who creates them, and how they are reset between test runs, since fewer roles means fewer authorization checks the report can support.

Tenants and data ownership

In multi-tenant APIs, a request can cross tenant boundaries even when the user role looks correct. Confirm which tenants are in scope, whether the tester needs accounts in two or more tenants, and which tenant data may be read, modified or deleted during the test. Clear ownership rules decide whether cross-tenant checks are possible and how the client reviews any sensitive records the tester touches.

Rate limits and testing windows

Tests for unrestricted resource consumption and abuse of sensitive business flows can degrade shared services, trigger lockouts or breach a partner's terms. Agree the request volumes, excluded endpoints, permitted times and who to contact if a service slows. Ask for the rate limit configuration in advance so the tester can check limits without causing an outage.

Specifications and undocumented endpoints

An OpenAPI or similar specification, gateway route list and changelog show the intended surface, while traffic logs and source code reveal endpoints the documentation omits. Supplying these inputs changes a test from guesswork to a documentation-led review, which covers the inventory risks in API9:2023. Confirm which artifacts the client can share and whether internal or debug routes must be excluded.

How a REST API security test runs, phase by phase

The sequence turns an agreed API inventory into evidence of where object, function and property level authorization, resource limits and undocumented endpoints hold or fail, and ends with a retest of the fixes.

Agree scope and rules of engagement in writing
The client and DeployOpen agree in writing which API hosts, versions, environments, business functions and data classes are in scope, which are excluded, and what load and destructive actions are allowed. The client confirms the test environment is production-like, who is the technical contact for incidents, and whether testing windows apply. The step closes when the signed scope names every host and account the tester will use. Ask the provider to state the fixed deliverables and the conditions that would change the scope.
Collect specifications, tokens and test accounts
The client supplies OpenAPI or other specifications, gateway configuration, authentication details and at least two test accounts per role, such as a standard user, a second user of the same tenant and an administrator. Where the client cannot provide these, the tester documents the gap, because authorization tests depend on comparing identities. This step is done when each role has working credentials recorded in the scope document and access is confirmed through a basic request to each host.
Review documentation and build the endpoint inventory
The tester reads the specification, changelogs and any developer documentation, then compares them with the traffic and routes the client provides. The output is an inventory listing each endpoint, method, parameter, role that should reach it, and the data it returns. Gaps between documented and observed endpoints are recorded as candidates for the API9 Improper Inventory Management review, including old versions, debug routes and internal paths exposed at the edge. The step closes when the client has signed off the inventory as the basis for testing.
Test unauthenticated and authenticated access
Using the methodology in the OWASP Web Security Testing Guide API testing category, the tester first checks what each endpoint exposes without credentials, then repeats requests as each test role. This covers broken authentication (API2), token handling, and whether roles are enforced consistently across methods and versions. Testers act as both anonymous and logged-in users, which aligns with the authenticated testing expectation in CIS Control 16.13. The step closes when each endpoint has a recorded result for every role.
Test object, function and property level authorization
The tester compares what each role can read and change against the access rules implied by the documentation and the business design, testing identifiers across accounts (API1), function access by role (API5) and returned or accepted properties (API3). Because automated tools cannot fully verify access control, this stage depends on the tester's judgment and on the documentation or source the client supplies, in line with the hybrid testing approach that ASVS 5.0.0 encourages. Rate limits (API4), sensitive business flows (API6), SSRF (API7) and misconfiguration (API8) are checked in the same pass where the scope includes them. Each finding is recorded with the request pattern, the affected role pair and the data exposed.
Validate findings and reproduce them safely
Each candidate issue is confirmed with the smallest evidence needed, using test accounts and test data only, and is rated by the impact the client's data and business flows would carry. The tester avoids destructive actions outside the agreed rules of engagement and stops where continued testing could affect live customers. The step closes when every finding has a status of confirmed, not reproduced or not applicable, with the evidence kept for the report.
Deliver a report mapped to the agreed framework
The report includes the scope, the inventory, the methods used, each confirmed finding with its API Top 10 category, reproduction steps written for developers, a risk rating, and recommended fixes at the level of control design rather than exploit detail. If the client needs an ASVS-based assurance view, the report lists which requirements were checked, which had exceptions and which do not apply, since a standard penetration test report lists issues by exception. The client receives a walkthrough with the engineering team. This step is done when the report is accepted and the fix owners are named.
Retest fixes and close the findings
After the client's engineers change the API, the tester repeats the original checks for each fixed finding, confirms the control now holds for every affected role and endpoint, and checks that the change did not open a neighbouring path. Findings are closed with a written retest record listing the date, build or version tested and the outcome. Ask the provider in the quote whether the retest is included in the fixed scope, how many retest rounds are covered and what is needed to start one.

Which API weakness categories the test targets

This table compares six OWASP API Security Top 10 2023 categories as they appear in REST targets, with what each looks like at a high level and why it matters to the buyer. Read it as a scoping aid: each category becomes a set of test objectives agreed in writing before work starts, not a checklist of attacks to run.

Category	What it looks like in a REST target	Why it matters
API1 Broken Object Level Authorization	Endpoints that take an object identifier in the path, query or body but do not confirm the caller owns or may access that specific record	Often the most common API flaw in practice, and it can expose one customer's data to another without any elevated privilege
API3 Broken Object Property Level Authorization	Responses that return internal or sensitive fields, or requests that accept fields the caller should not be able to set, such as role or balance attributes	Exposure often hides in verbose JSON responses that clients never display, so it is missed by reviewing the user interface alone
API4 Unrestricted Resource Consumption	Missing or weak limits on request rate, payload size, page size, file uploads, or costly operations such as exports and notifications	Drives service degradation and cost overruns, and can enable abuse of paid or third-party services the API calls
API5 Broken Function Level Authorization	Administrative or privileged operations reachable by ordinary roles, or inconsistent checks between similar endpoints and HTTP methods	Lets a low-privilege account perform actions reserved for staff, and is frequently missed when role checks live only in the client
API9 Improper Inventory Management	Old API versions, debug or internal endpoints, and undocumented routes still deployed next to the supported ones, with no current specification	Testers and defenders cannot protect what they do not know exists, so the test scope must include discovery against the official inventory
API2 Broken Authentication	Weak token validation, unprotected login or recovery paths, long-lived or poorly scoped tokens, and inconsistent authentication across gateways and services	Compromised authentication lets an attacker act as a legitimate user, which undermines the other controls in this list

Why object and function level authorization needs authenticated, role-based testing

Broken object level authorization (API1:2023) and broken function level authorization (API5:2023) are found by testing as several different users, not by a scanner pointed at one login. The question a tester answers is whether account A can read, change or delete a record that belongs to account B, or call an administrative route that a standard user should never reach. Answering that requires at least two accounts per relevant role, a tenant or organization boundary to cross, and the identifiers each account legitimately owns. A scanner sending requests with a single token sees only the responses that one identity is allowed to receive, so it cannot judge whether another identity's data leaked through the same endpoint.

The OWASP Application Security Verification Standard (ASVS) places this work in chapter V8 Authorization, and its 5.0.0 guidance says automated DAST and SAST tools cannot fully verify many access control requirements. CIS Controls v8.1 Safeguard 16.13 makes the same point for critical applications: authenticated testing, with testers acting as both authenticated and unauthenticated users, is better suited to finding business logic flaws than automated scanning. Before commissioning a test, confirm with the provider that it will hold a matrix of roles (for example anonymous, standard user, tenant administrator and platform administrator) and will test each endpoint against every role that should be denied. Ask how the tester will obtain tokens for each role and who owns those test accounts after the engagement.

Ask the provider to produce that role-to-endpoint matrix as a deliverable, because it shows which authorization decisions were verified and which were not. An ASVS-aligned report should list the requirements checked and any that do not apply, not only the defects found. Your own team should confirm that test accounts are provisioned in a non-production tenant with realistic but synthetic data, that each role's permissions match the documented design, and that the specification used by the tester is current. An undocumented or deprecated endpoint that still enforces a weaker check is the most common place where these two flaws survive, so the test scope should explicitly include it.

What drives the cost and duration of an API test

This table compares the components that move the price and schedule of a REST API test, from endpoint count to authentication model and retest. Read each row as a question to answer in the written scope, because the cheapest way to keep effort down is to settle these inputs before testing starts. No price list is published, and a quote follows from the written scope.

Driver	Why it changes effort	How to scope it efficiently
Endpoints and services	Each endpoint, method and parameter combination must be checked for object and function level authorization, so effort grows with the surface, not the page count.	Provide an inventory or OpenAPI definition per service, and agree which services are in scope and which are excluded.
Roles and test accounts	Authorization testing compares what each role can read and change, so every additional role adds a comparison set across the endpoints.	List roles, their permissions and the number of accounts per role, and confirm that test tenants hold realistic but non-production data.
Authentication model	OAuth 2.0, OpenID Connect, API keys and mutual TLS each need different token handling, and token expiry or refresh logic slows manual testing.	Name the grant types, token lifetimes, certificate processes and any gateway that validates tokens before the service.
Specs and source code	A current OpenAPI or GraphQL schema lets testers find undocumented endpoints and check property exposure quickly. Without it, discovery takes longer and coverage is harder to prove.	Share the latest spec, version history and a list of deprecated or internal routes. Ask whether source access is possible, since ASVS 5.0.0 favors documentation or source led testing.
Environments	Testing against a production-like staging environment with the same gateway, rate limits and configuration produces findings that transfer. Mismatched environments need extra validation.	Confirm which environment is tested, whether it mirrors production controls, and who handles test data resets and rate limit exemptions.
Assessment depth (ASVS L1 to L3)	Higher ASVS levels add more requirements to verify and more evidence to record, so the effort rises with the level chosen.	Choose the level per API based on data sensitivity and regulatory need. ASVS guidance is to start at L1 for critical concerns and move up as needed.
Business flows	Multi-step flows such as payment, account changes or bulk operations need sequencing, state setup and abuse scenarios, which take longer than single request checks.	List the sensitive flows (API6:2023 scenarios) and state which ones require business logic testing.
Rate limits and resource controls	Verifying API4:2023 controls means testing thresholds safely against the live gateway, which requires coordination and monitoring.	Agree test windows, source addresses and the thresholds to verify, and confirm who watches the service during testing.
Retest	Each fix needs confirmation, and a retest that covers only the reported findings costs less than a full retest of the API.	Ask whether retest is included in the fixed scope, which findings it covers and how long after the report it remains valid.

What the client receives and whether it satisfies an auditor

A REST API test produces a set of documents, and their value depends on what the reader needs them to prove. The cards below cover the report sections, the difference between an issues-by-exception report and an ASVS-style verification report, and the limits of what a customer letter can say.

Scope and method record

The report opens with the agreed scope: which base URLs, API versions, gateways and environments were in and out of bounds, and which accounts and specifications the tester used. It also records the methodology, mapped to the OWASP API Security Top 10 2023 categories and the relevant WSTG API testing guidance. Check that the scope names every version and environment that customers actually call, because an untested version is a common gap an auditor will question.

Endpoint and role coverage summary

A coverage table lists the endpoints tested, grouped by resource, and the roles or test accounts used against each, such as anonymous, standard user, tenant admin and service account. It shows which endpoints were reached only through the published specification and which were found through traffic or inventory review. Ask for this table before the test starts in draft form, since it is the fastest way to confirm that object and function level checks covered every role that matters.

Findings with severity and defensive detail

Each finding states the affected endpoint, the weakness category, the observed behavior at a defensive level, the business impact and a severity rating with its rationale. Reproduction detail should show that the issue exists and how to verify the fix, without publishing working exploit steps or payloads. Ask whether the severity method is documented, since a rating without a stated basis is hard to defend to an assessor.

Remediation guidance per finding

For each finding, the report explains the control that should be added or corrected, such as per-object ownership checks, response schema filtering, rate limits or removal of undocumented routes. Guidance should point to the component that owns the fix, whether that is the gateway, the service or the identity layer. Clients should expect guidance to be specific enough for developers to act on without a second call with the tester.

Issues by exception versus verification report

A traditional penetration test report lists issues found, and silence about a requirement does not show it was checked. An ASVS-style verification report also records the scope, summarizes every requirement checked, marks each as passed, failed or not applicable, and gives guidance for each exception. Where a framework or assessor expects evidence that controls were verified, ask for the second form and agree the requirement list at the start.

Retest results and limits of a customer letter

A retest confirms which findings were fixed, which remain open and which are accepted as risk, with dated evidence for each change. A customer letter or summary statement can describe testing that took place, but it is not an audit opinion, attestation or certification, and it does not replace the assessor's own report. Independent auditors and certification bodies decide whether evidence satisfies a framework, so confirm their acceptance criteria before the test is commissioned.

How REST API testing changes by architecture

A monolithic REST backend usually exposes one application programming interface in front of one codebase and one authorization layer. That makes the object and function level checks (API1:2023 and API5:2023) easier to map, because every route can be traced to a controller and every controller to a role model. The main risk is that authorization logic is scattered across handlers rather than enforced in one place, so a route added later can skip a check that its neighbors have.

Scope: Tests usually cover the whole route table, including admin, batch and import endpoints that sit beside customer-facing ones.
Identity: Testing needs at least two test accounts per role, plus one account per tenant if the application is multi-tenant, so cross-account object access can be checked.
Inventory: Ask for the routing configuration or generated OpenAPI file, and confirm whether it is current with the deployed build.
Property exposure: Responses often return full entity objects, so check each endpoint for fields hidden in the UI but present in the JSON (API3:2023).
Hidden versions: Confirm whether older route prefixes or debug endpoints remain reachable after a refactor.

Before commissioning, confirm which roles, tenants and route groups must be covered and whether source access is available for a documentation-led test.

What the client prepares before the API test starts

The most useful preparation is a complete endpoint inventory that the tester can check against the API's own definitions. Start with the current OpenAPI document or other specification for each API, including versions still in use, and list any endpoints that exist in code, gateways or routing rules but are missing from the spec. Ask the platform team to confirm which hosts, base paths and versions are live in each environment, and which are deprecated but reachable. Undocumented endpoints, shadow versions and forgotten admin routes must be disclosed in scope, not discovered mid-test. Testing them is where broken function level authorization and improper inventory management usually surface, and a tester who finds an unlisted route on their own will need to stop and agree scope before continuing.

Next, prepare test accounts for every role and tenant that the API distinguishes. For object and function level checks, a tester needs at least two accounts per role, owned by separate tenants or users, so that cross-account access can be tested in both directions. Document how each token is issued, including the identity provider, grant type, token lifetime, refresh behavior and any scopes or claims that gate access. Confirm whether service accounts, API keys and machine-to-machine credentials are in scope, and who can rotate them during the test. Agree how test data is seeded and reset, since destructive tests against shared records will affect other users.

Finally, settle the operational details that protect production and avoid false alarms. Share the rate limit settings per endpoint and per client, and state whether they are enforced at the gateway, the application or both, because resource consumption tests need to know the threshold before they run. Provide environment access, VPN or IP allowlist entries for the tester's source addresses, and a named technical contact who can respond during the agreed testing windows. Record any change freezes, scheduled releases or batch jobs that overlap the window, and confirm who may halt the test. Your own security operations team should know the window and the source addresses in advance, so alerts raised by the test are triaged rather than escalated as incidents. Confirm each of these items in writing before the scope is signed.

What to check when choosing an API testing provider

A provider's API test is only as good as its method, its access to the API and the evidence it hands back. The cards below cover the checks that separate a credible REST API tester from a scanner with a sales deck. Ask each question in writing and compare answers across bidders before you sign a fixed-scope agreement.

Experience with the OWASP API Top 10

Ask which items of the OWASP API Security Top 10 2023 the provider tests by default and how it covers each one. Strong answers name object and function level authorization, property exposure and resource consumption, and explain how each is verified. Ask for an anonymized sample of how a finding in one of these categories was written up. Treat a list of tools with no test logic behind it as a warning sign.

Named methodology and ASVS mapping

Ask which methodology the provider follows and whether it maps results to OWASP ASVS requirements, the verification levels it targets and the chapters covered for APIs, including V4 API and Web Service and V8 Authorization. A named method should show how test cases are chosen, how authorization checks are repeated across roles and how coverage is recorded. Ask how the method accounts for requirements that do not apply to your API.

Requests for specs and test accounts

A credible tester asks for the OpenAPI or other API description, sample requests, authentication flows and at least two test accounts per role, including accounts that should be denied access to each other's objects. Without these, the tester has to guess object identifiers and role boundaries, which is where most authorization findings come from. Confirm who creates the accounts, how they are removed afterward and whether they are isolated from live customer records.

Handling of production data

Ask whether testing runs in a staging environment that mirrors production, or against production with a written data-handling agreement. Ask how the provider avoids reading or copying personal or payment data, how it stores evidence and how long it keeps it. Confirm the rules for rate limit and load testing, since resource consumption tests can affect live services. Get these terms in the statement of work, not only in a conversation.

Report format against auditor needs

Ask for a sample report before you buy. A traditional penetration test report lists issues by exception, which may not satisfy an assessor who needs the scope, a summary of every requirement checked and the requirements that do not apply, as described in ASVS 5.0.0. Confirm that the report includes reproduction steps for developers, severity rationale, and an executive summary your auditor or customer will accept.

Retest terms in writing

Ask whether a retest of fixed findings is included in the price, how many retest rounds are allowed and within what period the retest must happen. Confirm whether the retest produces an updated report that shows each finding as closed, open or accepted, so the record can go to your auditor. Ask whether authorization findings are retested with the same role accounts used in the original test.

Verifying a CREST OVS accreditation claim

If a provider says it holds CREST OVS accreditation, check it on CREST's public record before you rely on it. CREST's accreditation covers the testing organization's ability to run web application assessments against ASVS and mobile assessments against MASVS, at Levels 1 and 2. It does not cover API testing as a separate scheme, and it does not make a report an ASVS certification. Confirm the accredited scope in writing.

REST API security testing questions buyers ask

How much does REST API security testing cost?

No single price applies, because the quote follows from the written scope. The main cost drivers are the number of endpoints and resources, how many roles and tenants must be tested, whether the tester receives an OpenAPI or other specification, how much authentication logic sits behind the API, and whether the work is a one-off test or part of a recurring program. Most engagements are fixed-scope, so the quote itself should list the endpoints or services covered, the test accounts and roles, the test environment, the deliverables and any retest included. Ask for those items to be written out, and ask which parts would recur, such as retesting or continuous testing under a retainer.

How long does an API penetration test take?

The duration depends on the agreed scope, and DeployOpen only states a timeline in the written scope. The factors that lengthen the work are a large number of endpoints, many roles and object types, complex workflows that span several services, and undocumented or changing interfaces that need mapping first. Work goes faster when the specification is current, test accounts are ready on the first day, and the test environment matches production behavior. Ask the provider to show the planned phases, such as discovery, authorization testing, reporting and any retest window, and to confirm the start conditions in writing before scheduling.

What does my team need to provide for an API test?

The tester needs enough access to test the API as a real user would, along with the context to test it properly. Typically this includes:

An OpenAPI or similar specification, or an inventory of the endpoints in scope, including versions still in use
Test accounts for each role and tenant, with known permissions and clear boundaries between them
Valid tokens or the means to obtain them, plus documentation of the authentication flow and token lifetimes
A non-production environment with representative data, or written agreement on testing against production
Named contacts for questions and for stopping the test if the service is affected

Ask the provider to confirm each item against your environment before the scope is signed.

Can our internal security team test our REST APIs without outside help?

Internal teams can test many API issues, especially if they have the skills and time to work through object and function level authorization, property exposure and rate limits. The main limits are independence, time and coverage of business logic. An outside tester brings a separate view of the design and can report findings to an auditor or customer with a clear method. Many organizations use both, with internal staff running routine checks and an external test at key releases. Whatever the mix, ask who will write the report, how findings are validated, and whether the method can be reproduced by your own team.

How does retesting work after an API penetration test?

Retesting checks whether the reported findings were fixed, and it is usually scoped separately from the original test. The tester confirms each finding against the same endpoints, roles and test accounts, then records whether it is resolved, partially resolved or still open. Retesting typically requires the client to deploy fixes to the test environment first and to share a list of what changed. Ask whether a retest is included in the quote, how many rounds it covers, the window in which it must happen, and how the final report will show closed and open items.

Is an automated API scanner enough to test our APIs?

An automated scanner is useful for finding known misconfigurations, missing headers, unsafe defaults and some injection patterns, but it is not enough on its own. The OWASP API Security Top 10 2023 includes broken object level and function level authorization, sensitive business flows and improper inventory, which depend on understanding who should see what. OWASP's ASVS guidance notes that automated DAST and SAST tools cannot fully verify many requirements, especially business logic and access control. Scanners work best as one input to a manual test that uses roles, specifications and test accounts.

Will an API penetration report satisfy PCI DSS or a customer security review?

A penetration test report can support a PCI DSS assessment or a customer review, but the report alone does not decide compliance. PCI DSS requirement 11.4.1 requires application-layer penetration testing that covers the vulnerabilities listed in requirement 6.2.4, including abuse of application features through API manipulation, so the scope must reflect the payment-related APIs. DeployOpen does not issue audit reports or certifications, and assessors decide acceptance. Confirm early with your qualified security assessor or customer what they expect in the report, such as scope statements, methodology, tester qualifications and how findings were validated.

Which OWASP guidance should an API test follow?

A useful API test combines the OWASP API Security Top 10 2023 as the risk list, the OWASP Web Security Testing Guide for method, and OWASP ASVS for verification requirements. The WSTG v4.2 includes an API testing category, and ASVS chapters such as V4 API and Web Service and V8 Authorization define what to verify. Ask the provider which version of each guide the test will use, how requirements are mapped to findings, and whether the report will list requirements that were checked and found compliant, not only defects. ASVS guidance favors documentation-led testing over testing without any source or specification.

How DeployOpen scopes, tests, reports and retests APIs

DeployOpen is a Chainscore Labs company that runs security testing for applications and APIs alongside the self-hosted platforms it implements inside client environments. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before testing begins.

How we scope

We agree in writing which API hosts, versions, resource groups and roles are in scope before testing starts.
We confirm which test accounts, tenants and roles the client will provide, with at least two users per privilege level where authorization is tested.
We record whether the API specification is available, and whether it reflects the production surface, so undocumented endpoints can be identified and listed.

How we build

We map each endpoint to the OWASP API Security Top 10 2023 categories, with object and function level authorization given the most attention.
We review the specification, gateway rules and token handling alongside live requests, because many authorization checks cannot be verified by automated tools alone.
We test rate limits, resource consumption and property exposure by role, and we confirm test traffic limits with the client before any load-related checks run.

How we hand over

Findings are written with the affected endpoint, the role used, the evidence captured and the remediation direction for the engineering team.
The report lists the endpoints and categories tested, including those with no findings, so the client can show coverage to an auditor or customer.
We walk the client's engineers through the results and agree which findings need retesting, with the retest scope recorded in writing.

How we support

Retesting of agreed findings is scoped separately so the client can confirm fixes against the original evidence.
Ongoing support, upgrades and continuous testing are available as retainers for APIs that change between releases.
Clients should confirm with us how API changes will trigger new testing, such as new endpoints, new roles or changes to the gateway.