Why mobile backend API testing is where serious mobile findings sit
If a compliance framework, a customer security review, a launch or a due diligence process asks for testing of your mobile app, the test should cover the APIs the app calls, not only the app binary. Most of the serious exposure in a mobile product sits on the server side, where the app's requests are accepted, authorized and answered. A test scoped to the installed package alone will miss the controls that decide whether one user can read another user's records.
The weaknesses that matter most cluster in three areas. The first is object and function level authorization: whether an endpoint such as one returning an account or order by identifier checks that the caller owns that object, and whether administrative functions are restricted to the right roles. The OWASP API Security Top 10 2023 ranks Broken Object Level Authorization first, followed by Broken Authentication and Broken Object Property Level Authorization. The second is token handling. Many apps obtain access tokens through OAuth 2.0 and OpenID Connect, so the test should examine how tokens are issued, scoped, stored on the device, refreshed, revoked and validated by each API. The third is API abuse, including missing rate limits, excessive data exposure in responses and business logic that can be automated against the backend.
The mobile standard, OWASP MASVS, covers these concerns in its network and authentication control groups, but the testing of the server behavior itself draws on API and web service requirements in OWASP ASVS chapter V4 and OAuth and OIDC requirements in chapter V10. Before commissioning the work, confirm with your provider which ASVS and API Top 10 items they will test, which accounts and roles they will use, and whether they will test production or a staging environment that mirrors it. Those answers determine whether the report will show that your backend enforces access control or only that the app behaves correctly.
What can be in scope for a mobile API test
Scope for a mobile API test is set by a short list of decisions: which hosts, identity services, mobile-specific endpoints, accounts and environments are included, and what rules govern testing. Each decision changes what is tested, what access the testers need and what the final report can claim, so agree them in writing before testing starts.
API hosts and versions
List every hostname, base path and API version the app calls in production, including older versions still served to users who have not updated. Ask which versions the client supports for minimum app versions, and whether internal gateways or backend-for-frontend services sit behind the public host. Each host not listed in scope is a host the report cannot speak to, so the inventory should come from the client's own gateway configuration rather than from the app alone.
Identity providers and token services
Name the authorization server, identity provider and any social or federated login the app uses, and state whether the client owns each one. Token issuance, refresh and revocation endpoints are often run by a managed identity service, which may restrict testing or require the vendor's own terms. Confirm which token endpoints fall inside the engagement and which belong to a third party that the client cannot authorize testing against.
Mobile-specific endpoints
Identify the endpoints that behave differently from ordinary web APIs: sync and offline reconciliation, push notification registration, file upload and file download, and deep-link handlers that call the backend. These carry their own risks, such as objects addressed by predictable identifiers in a download URL or sync requests that trust client-supplied ownership. Ask the client for the full list from the app's network traffic and backend routing, not only from API documentation.
Test accounts for each role
Authorization testing needs at least two accounts per role, typically a standard user, a second user at the same privilege level and an administrator or support role where one exists. Ask the client to provision these accounts with realistic but non-sensitive data, to document which features each role unlocks, and to confirm who may create or disable them. Without a second account per tenant, object-level checks cannot be completed.
Tenant and organization boundaries
For multi-tenant platforms, define which tenants, organizations or customer workspaces are in scope and whether the testers may use a tenant that holds real customer records. Confirm how tenant identifiers are passed (path, header, token claim) so the test can check whether one tenant can reach another. If the client cannot provide an isolated test tenant, agree the data handling rules before access is granted.
Rules of engagement and environments
Agree whether testing runs against production, staging or a dedicated test environment, and what that environment's data and configuration look like compared with production. Set request rate limits, testing windows, permitted actions such as account creation or data deletion, and an escalation contact if a test degrades service. Staging results only describe production if the environments share gateways, identity configuration and backend versions, so ask the client to confirm those differences in writing.
How a mobile API engagement runs, phase by phase
The sequence moves from a written scope of endpoints, roles and rules of engagement, through layered testing of the API behind the app, to a report and a retest that confirm which findings were fixed.
Agree scope and rules of engagement in writing
The client and DeployOpen agree which API hosts, endpoints, mobile app versions and environments are in scope, which test accounts and roles will be used, and what is excluded, such as production data or third-party services the client does not own. Rules of engagement cover testing windows, rate limits, contacts for escalation and how credentials are handled. The step closes when a signed scope document lists these items, and the client has confirmed in writing that it owns or has authority over every system named. Ask for the scope to state which user roles are provided, because authorization testing depends on them.
Map the API surface from traffic and specifications
DeployOpen builds an inventory of the API the app calls. Sources include the client's API specifications where they exist, the app builds the client supplies for test devices, and traffic captured from the app on test accounts. The inventory records endpoints, methods, parameters, authentication schemes and which roles reach each endpoint, including older app versions and undocumented routes. The step is complete when the team and the client agree on a list of endpoints and roles, and gaps between the documentation and observed behavior are logged for the client to confirm.
Test object and function level authorization
Testers check whether one user can read or change another user's objects, and whether lower-privileged roles can reach administrative functions. This work maps to the OWASP API Security Top 10 2023 categories for broken object level authorization and broken function level authorization, and to the matching ASVS V4 access control requirements. Testers compare responses across accounts and roles on the agreed test data. The step closes with a record of each endpoint tested, the roles compared and any confirmed access gaps with reproduction context suitable for the client's developers.
Test token issuance, validation and renewal
For apps that use OAuth 2.0 or OpenID Connect, testers review how the app obtains tokens, how the backend validates them, and how sessions are renewed and ended. Testing covers the category of broken authentication in the OWASP API Security Top 10 2023 and the OAuth and OIDC requirements in ASVS V10. Attention goes to token lifetimes, audience and issuer checks, storage on the device, refresh behavior and logout. The step closes with a list of token-handling weaknesses, each tied to the control it breaks, and a note on what the client's identity provider enforces versus what the API must enforce itself.
Test input handling, property exposure and abuse controls
Testers review whether the API accepts fields it should not, returns more object properties than the app needs, and limits abuse such as excessive request volume against login, password reset and high-value actions. The categories are broken object property level authorization, unrestricted resource consumption and unrestricted access to sensitive business flows in the OWASP API Security Top 10 2023, with input validation requirements from ASVS V4. Testing is bounded by the rate and volume limits in the rules of engagement. The step closes with a list of abuse-control gaps and the business flows they affect.
Report findings with fix guidance
DeployOpen writes a report that lists each finding with its affected endpoint, the role or token involved, the weakness category, severity under the client's agreed rating method and a fix recommendation developers can act on. The report separates confirmed issues from observations and notes what was out of scope or could not be tested. The step closes when the client has received the report and held a walkthrough with its development and security leads to confirm understanding of each finding.
Retest fixed findings
After the client's developers ship fixes, DeployOpen retests the findings in scope, using the same accounts, roles and endpoints where possible. Each finding is marked as resolved, partially resolved or still open, with the evidence behind that status. The step closes with a retest report that states which findings were verified and which were not retested. Confirm before commissioning whether retest is included in the fixed-scope quote or billed separately, and whether the retest report is written to serve an auditor or customer.
Which API weakness categories matter most for mobile backends
This table compares the API weakness categories we see most often behind mobile apps, how each appears in a mobile backend, and why it matters to the business. Read each row as a testing target: the right-hand column shows what a tester checks and what evidence the client should expect in the report. The main takeaway is that authorization failures on object identifiers usually matter more than any single transport or client-side issue.
| Category | What it looks like in a mobile backend | Why it matters |
|---|---|---|
| Broken Object Level Authorization (API1) | Endpoints accept an account, order or document identifier from the app and return data without checking that the caller owns it. Testing uses two test accounts and compares responses across identifiers. | Mobile apps expose many object identifiers in normal use, so one missing ownership check can expose every user's records. |
| Broken Authentication (API2) | Login, token refresh, password reset or device enrollment flows accept weak checks, or sensitive endpoints accept requests without a valid session. Testers review each flow's state handling and lockout behavior. | Authentication flaws let an attacker act as a legitimate user from a device they do not control. |
| Broken Object Property Level Authorization (API3) | Responses return fields the app never displays, such as internal roles or flags, and update requests accept fields the user should not change. Testers compare what the app renders with what the API returns and accepts. | Mobile clients hide fields visually, so hidden properties are often exposed in full API responses. |
| Unrestricted resource consumption and abuse | Endpoints used for search, upload, messaging or SMS and email triggers lack rate limits, pagination caps or cost controls. Testing reviews limits per user, per device and per IP, and checks how the backend responds at volume. | Abuse can drive cost, degrade service for other users and enable account enumeration or fraud at scale. |
| Access token storage and handling | Tokens are kept in client storage without platform protection, logged, or sent to endpoints that do not need them. Testing reviews where tokens live on the device and what the backend accepts from a stolen token. | A stolen token can outlast the app session, so storage and scope decisions set the blast radius of a device compromise. |
| Token lifetime, audience and revocation (ASVS V10) | Access tokens are long-lived, not restricted to the intended API audience, or still accepted after logout, password change or device removal. Testing compares OAuth and OIDC configuration with ASVS V10 expectations and confirms revocation takes effect. | Mobile apps often hold tokens for weeks, so weak audience checks let a token issued for one service unlock another. |
| Weak validation of OAuth and OIDC flows | Redirect URIs, PKCE use, state parameters and issuer or signature checks are misconfigured or skipped on the backend. Testers review the flow end to end with the identity provider's configuration supplied by the client. | Flow flaws can let an attacker obtain a valid token for a victim account without touching the device. |
| Verbose errors and debug exposure | Error responses reveal stack traces, internal hostnames, or identifiers of other users. Testing compares error handling across malformed, unauthenticated and out-of-scope requests. | Detailed errors speed up the discovery of the categories above and can leak personal data directly. |
How the test changes by API architecture
A single first-party backend is one service, or a monolith with a small number of deployable units, owned by the same organization that ships the app. Scope is usually the whole API surface the app calls, plus the identity provider and any admin endpoints that share the same host. Access is the simplest of the architectures: the client typically provides test tenants, seeded accounts at several privilege levels and API documentation. Effort concentrates on object and function level authorization, because one codebase often applies those checks inconsistently across endpoints.
- Scope: every endpoint the mobile client calls, including older API versions that remain reachable.
- Access: test accounts for at least two users and one privileged role, with ownership of each object clear in advance.
- Effort: driven mainly by the number of endpoints and roles, not by infrastructure.
- Hidden surfaces: debug, internal or versioned routes that the app does not call but the server still serves.
- Confirm with the client: the full endpoint inventory, whether a non-production environment mirrors production, and who can change test data during the engagement.
Before scoping, ask the client to confirm whether any endpoint exists only for the web or admin console, because those routes are often in scope even when the app does not use them.
In a microservices design, the mobile app talks to an API gateway or edge layer, which routes requests to many internal services. Authorization may be enforced at the gateway, inside each service, or in both places, and that split is where many findings occur. Scope expands to the gateway configuration, the routing rules, service-to-service trust and any internal endpoints reachable through misrouting. Effort rises with the number of services and the number of teams that own them, and the test needs an agreed view of which service owns which check.
- Scope: the gateway, the services it exposes and the routing or policy rules that decide which requests reach them.
- Access: credentials for each role across services, plus architecture diagrams that show where authorization decisions are made.
- Effort: grows with service count, so the client should rank services by data sensitivity before scoping.
- Trust boundaries: whether internal services accept requests that only the gateway should send, and how identity is propagated.
- Confirm with the client: whether a staging cluster or a shared test namespace is available, and whether the gateway can be tested without affecting other tenants.
Close the scoping discussion by asking the client which team owns the gateway policy, because that team is needed to validate and fix most authorization findings in this design.
A backend-for-frontend (BFF) is a server component built for one client application, often one for iOS, one for Android and one for the web. It aggregates calls to downstream services and shapes responses for that app. The BFF becomes the trust boundary the app sees, so it must enforce authorization for the data it returns, even when downstream services apply their own checks. Scope therefore covers each BFF as a separate target, and the test compares what each BFF exposes with what the downstream services allow.
- Scope: each BFF deployment, its downstream calls and the mapping of user identity to downstream permissions.
- Access: tokens issued to each client application, so the test can confirm that one app's BFF does not accept another app's tokens without intent.
- Effort: multiplies with the number of BFFs, but many checks repeat, which the client can use to reduce duplication.
- Response shaping: fields filtered for one app but returned unfiltered by another path.
- Confirm with the client: which BFFs share code or libraries, and whether the same downstream services sit behind all of them.
Ask the client to list every BFF and its client identifier before the test starts, since an unlisted BFF is the most common reason a scope turns out to be incomplete.
Many mobile apps call APIs the client does not own, such as payment processors, identity providers, mapping services or partner data feeds. The client can test its own integration, meaning how it stores and sends credentials, validates responses and handles errors, but it usually cannot test the provider's servers without the provider's permission. Scope must separate what the client controls from what belongs to a third party, and authorization for any test of a third party's infrastructure must come from that party, under its published testing rules.
- Scope: the client's own proxy or middleware, its credential handling and its validation of partner responses.
- Access: sandbox or test credentials from the partner, since production data and live transactions should not be exercised.
- Effort: depends on partner documentation quality and sandbox fidelity, which the client should assess before committing.
- Authorization: written permission from the partner when any test reaches its systems, and a record of who signed it.
- Confirm with the client: whether each partner permits testing, which environments are allowed, and whether the partner's terms limit test volume or methods.
Before scoping, ask the client to collect each partner's testing terms, because a test that reaches a third party without that authorization can create contractual and legal exposure for the client.
What drives the cost and duration of an API test
This table compares the factors that change the effort behind a mobile backend API test, who is paid for each part of the work, and what to ask for in a quote. Read it as a checklist: each driver shows why it matters and how to narrow it without losing coverage of the authorization paths that carry most serious findings. Fixed-scope quotes follow from the written scope, so the clearer the endpoint inventory and role model, the easier the comparison between proposals.
| Driver | Why it matters | How to scope efficiently |
|---|---|---|
| Endpoints and API versions | Effort grows with the number of routes, parameters and object types that accept identifiers. Older versions still reachable from the app often carry weaker checks. | Ask for an inventory from the OpenAPI definitions or gateway logs. Decide with the client which deprecated versions are in scope and whether they must be retired first. |
| Roles and tenant models | Object and function level authorization findings depend on comparing what each role and tenant can read or change. More roles multiply the comparisons. | List every role, plan tier and tenant boundary in writing. Group roles that share identical permissions and test the boundaries that matter most to the business. |
| Identity provider integrations | OAuth and OIDC flows for mobile apps involve token issuance, refresh, scopes and audience checks. Each provider or custom grant adds configuration to review. | Name the identity provider, flows and client types in the scope. Confirm whether the provider is in scope or only the relying API's use of its tokens. |
| Environments and test accounts | Testing needs a non-production environment that matches production authorization logic, plus accounts for each role. Missing data or accounts add setup time. | Ask the client to provide the environment, seeded data and test accounts before work starts. Confirm who manages test data resets during the engagement. |
| Test depth | A review of documented controls differs from a full adversarial test of business logic and abuse cases. Depth is the largest single lever on effort. | Agree the depth per endpoint group, such as a targeted review for read-only routes and deeper testing for payment, account and sharing functions. |
| Authenticated versus unauthenticated coverage | Most mobile API risk sits behind login. Unauthenticated scans find less, and authenticated testing needs session handling for each role. | Scope authenticated testing as the default. Keep unauthenticated checks short and limited to public routes and login, registration and recovery flows. |
| Reporting and evidence | Reports need to map findings to the requirements an auditor or customer will check, which adds review time beyond the test itself. | Ask which framework references the report should use, such as the relevant OWASP API Security Top 10 2023 categories or ASVS V4 requirements, and whether a retest summary is included. |
| Retest | Retesting confirms fixes and is usually a separate, smaller piece of work. Its size depends on how many findings are fixed and how much re-verification each needs. | Request a quote for retest as a separate line item. Ask whether it is included, how it is timed and whether it reuses the original test accounts and environment. |
| One-time testing versus retainers | A one-time test gives a point-in-time view. Retainers cover continuous testing, retests and support as the API changes, and recur on an agreed schedule. | Ask for the one-time test quote first. Consider a retainer only if release frequency or new endpoints justify recurring coverage, and confirm what the retainer includes. |
Which compliance programs expect mobile API testing
Most compliance programs do not name mobile APIs by that phrase, but many of them reach the same backend through their requirements for access control, authentication and data protection. For an app that handles sensitive data, the assessor usually asks two questions: was the app assessed against the OWASP Mobile Application Security Verification Standard (MASVS), and were the services it calls tested as well? A MASVS-based app assessment covers the client, including storage, network configuration and platform interaction, but the server side of those calls is only partly visible from the device. That gap is why an API test is often scoped and reported separately from a *Mobile Application Security Testing Guide (MASTG)* app test, with its own findings, evidence and retest cycle.
CREST's OWASP Verification Standard (OVS) accreditation, announced on 28 October 2022, covers mobile application assessments against MASVS at Levels 1 and 2, and web assessments against the OWASP Application Security Verification Standard (ASVS). It does not, by itself, state that an API test has been performed, so a provider's accreditation does not settle what your assessor will accept. Before scoping, ask your assessor or customer which standard, which version and which MASVS level they require, and whether they expect the backend APIs to be covered under the ASVS chapter for API requirements or only through the app test. Confirm whether a customer security questionnaire asks for a named test type, such as an API penetration test, because the answer changes the scope and the report format.
DeployOpen prepares the systems, controls and evidence that an assessor or customer will review, and runs security testing that can support those reviews. DeployOpen does not issue audit reports, attestations or certifications, and a test report is not a compliance result on its own. The practical step is to write down, before work starts, which framework, version, level and customer requirement the API test must serve, and which evidence the assessor needs (scope statement, test accounts and roles, findings, and retest results). That written scope is what turns a general test into evidence your auditor can use.
Common questions about mobile backend API testing cost, scope and effort
How much does mobile backend API testing cost and what drives the price?
Cost depends on the size and shape of the API surface, not on the mobile app alone. The main drivers are the number of endpoints and services behind the app, how many user roles and tenants must be tested for authorization, how complex the OAuth or OIDC token flows are, whether testers receive API specifications or must map the API themselves, and whether the test covers only the backend or also the app's client-side behavior. Costs fall into two groups: the testing engagement itself, which is one-time for a given release, and any retesting or continuous testing, which recurs. DeployOpen does not publish a price list. Ask for a quote built from a written scope that lists endpoints, roles, environments and deliverables, and check whether retesting is priced separately.
How long does a mobile backend API test take to complete?
Duration follows from the scope. An engagement covering a small API with a few roles can be far shorter than one covering dozens of services, several tenants and multiple token flows. The time needed for test accounts, environment access and clarification of business logic also affects the calendar, so the start date often moves for reasons outside the test itself. Ask the provider to state the testing window, the reporting window and what would extend either. Because the timeline is set in the written scope, confirm it there before you plan a release or a customer deadline around it.
What does the client need to provide before API testing starts?
The test needs access to the systems the mobile app really uses, so plan for it before the schedule is fixed. Typical requirements include: - Test accounts for each user role, including roles with elevated privileges, and at least two accounts per role so object-level checks can compare data between users. - API documentation, such as OpenAPI definitions or gateway routes, and a list of endpoints that are in scope or out of scope. - A staging or pre-production environment that mirrors production, plus the identity provider configuration for the OAuth or OIDC flows. - Named technical and business contacts who can answer questions about business rules and approve any testing that could affect shared services. Confirm each item with your engineering and identity teams during scoping.
Can our own team run mobile API security testing in-house instead?
Yes, many organizations run parts of this work internally, such as automated checks in CI/CD and regular reviews of authorization logic. An in-house team can cover the routine checks well because it knows the system. What an external test adds is an independent view of the same weaknesses, with a method and reporting the team can show to customers, auditors and leadership. Confirm the internal approach against the OWASP API Security Top 10 2023 categories and ASVS V4 requirements. Be clear about what is lost when work stays internal: independence from the people who built the API, a documented methodology, and an outside reviewer who has not seen the design assumptions. Many teams combine both approaches.
Does an API test satisfy a MASVS assessment or a customer security review?
An API test covers the backend part of MASVS, not the whole mobile assessment. MASVS organizes requirements into control groups such as MASVS-AUTH, MASVS-NETWORK and MASVS-PRIVACY, and some of those requirements depend on the app binary, local storage and platform behavior, which a backend test does not examine. The API test is evidence for the server-side controls. Whether it satisfies a specific MASVS level, a Google Play Data safety review or a customer questionnaire depends on what that party requires. Ask the reviewer in writing which controls and levels they expect, and agree with the provider how the report maps to them. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue the audit reports.
Is retesting included after the initial API test?
Retesting is not automatically part of the first engagement. Fixed-scope engagements define deliverables and timelines in writing, so confirm whether the quote includes a verification round after the client fixes findings, how many rounds are covered, and how long after the report that round must happen. Retesting usually checks whether specific findings are resolved and whether the fix introduced new issues in the same endpoints. Continuous testing and ongoing support are available as retainers, which suit teams that ship API changes frequently. Ask for the retest terms in the written scope so the budget and the remediation plan line up.
Can the API test run against production systems?
Testing in production is possible only when the owner approves it in writing and the rules of engagement limit the risk. Many teams test in a staging environment that matches production in configuration and data protection, because active testing can create records, trigger alerts, lock accounts or affect paying users. If production testing is considered, agree on the testing window, traffic limits, test data that is clearly marked, rollback steps, a stop condition and the people to contact if something behaves unexpectedly. Check with your cloud provider and any third party services the API calls, since their testing rules can also apply.
What the client receives and whether it satisfies an auditor or customer
A mobile backend API test produces a set of documents that serve different readers, from the board to the engineers who fix the flaws. Each one has to answer a specific question, and none of them is a certificate of security.
Scope and method statement
The report opens by recording which API hosts, versions, roles, and client builds were in scope, and which were excluded. It also states the method, including whether testing used a supplied account for each role, which API endpoints were covered, and which mobile client versions produced the traffic. Check that the in-scope list matches the endpoints your mobile app actually calls, because gaps here are the most common reason a report fails to support a customer review. Ask the provider to name the OWASP API Security Top 10 2023 categories and ASVS V4 and V10 requirements used as the reference.
Findings with severity and defensive reproduction
Each finding describes the weakness category, the affected endpoint or object type, the observed behavior, the business impact, and a severity rating with its basis. For authorization issues, the reproduction explains which role and which object ownership boundary was crossed, without providing working request sequences. Ask how severity is calculated and whether the scale is documented, since a customer or auditor will want to compare ratings across tests. Confirm that the report separates confirmed issues from items that need further validation.
Remediation guidance and developer notes
Remediation sections should name the control that failed and the change that closes it, such as enforcing object ownership checks on the server, validating token audience and issuer, or reducing the lifetime and scope of refresh tokens. Good guidance is written for the backend and mobile teams who will act on it, and avoids generic advice to 'improve authentication'. Ask whether the provider will review proposed fixes in a working session. Keep in mind that fixes to token handling often touch both the identity provider configuration and the app, so the owners should be named in the report.
Executive summary for leadership
The executive summary gives a short, plain account of what was tested, the overall risk picture, the number of findings by severity, and the decisions leadership needs to make, such as accepting residual risk or funding a fix window. It should not contain technical reproduction detail. Ask the provider to confirm that the summary and the technical body are reviewed together, so the headline numbers match the detail. Summaries that contradict the findings section are a warning sign.
Retest results and closure status
After fixes ship, a retest confirms whether each finding is resolved, partly resolved, or still open, and records the build or API version that was verified. Retest results should reference the original finding identifiers so the trail stays intact for an auditor. Ask whether retesting is included in the original quote or priced separately, and what happens if a fix lands in a later app release than the backend change. Clarify the retest window in writing before work starts.
Letter of testing for customers or auditors
A letter of testing states that a named test was performed, over a stated scope and period, against a named standard, and summarizes the outcome. It describes the testing performed and does not certify the application as secure, compliant, or free of vulnerabilities. Before signing or sending, confirm the wording and report format with your auditor or the customer who requested it, because each assessor has its own expectations for how testing evidence is presented. Compliance bodies and auditors make their own determinations from the evidence.
What the client prepares before the API test starts
The most useful thing a client can do before a mobile backend API test starts is hand the tester working access that matches how the app really behaves. Test accounts for each role and tenant come first. Object and function level authorization problems only show up when the tester can hold two or more identities at the same privilege level and at different levels, across each tenant the backend serves. Ask for at least two accounts per role and per tenant, with the data ownership of each documented, so the tester can check whether one user can reach another user's records. Confirm that accounts can be created, reset and deleted without manual help, because a tester blocked on account setup spends paid time waiting rather than testing.
Next, provide the API documentation or specifications the mobile client was built against. An OpenAPI description, GraphQL schema, gateway route list or a list of endpoints extracted from the app's network traffic all help, and the client should say which of these is current. Pair them with the identity provider configuration: the OAuth and OIDC client registrations for each app build, the scopes and audiences requested, token lifetimes, refresh token rotation settings and the redirect URIs in use. Tokens are where ASVS V10 requirements are tested, and a tester who has to reverse engineer the login flow before testing it will spend the first days of the engagement doing that work. Name who can change these settings during the test, since a change mid-test can invalidate findings already collected.
How retesting confirms that API fixes hold
The retest sequence shows whether each fix for a mobile backend API finding works as intended, without changing the original scope, and leaves a written record of what was and was not checked.
Agree the findings and retest scope in writing
Before any fixes are made, the client and DeployOpen confirm which findings are in the retest, which endpoints, roles and test accounts are covered, and which environment is used. For an original fixed-scope engagement, this is set out in the agreed scope. Where a retainer covers retesting, the retest allowance is defined there. The check is a signed scope note listing each finding ID and the environment it applies to.
Remediate findings in the client's own engineering process
The client's engineers change the API, authorization logic, token handling or gateway configuration to address each finding. DeployOpen does not usually change production code unless the written scope says so. Useful inputs to ask for include a short note per finding describing the change, the affected endpoints and the release or commit that contains it, so the retester knows what to examine.
Confirm the fixed build and test accounts are ready
Before retesting begins, the client confirms that the build or environment holds the fixed code, that the test accounts and roles from the original test still exist and have the same permissions, and that any tokens or client registrations used in the original test are available or can be reissued. Retesting against an unchanged environment or mismatched roles can give false results, so this readiness check is recorded in the retest plan.
Retest each finding against its original test case
The tester repeats the original test for each finding, using the same object identifiers, role combinations and token flows, and then checks adjacent paths the fix could have affected, such as other methods on the same resource or the same check applied to a different object type. This is evidence-based verification, not a new broad assessment. The output is a pass or fail result per finding with the request and response evidence captured in the working notes.
Update the status of each finding in the report
Each finding is marked as resolved, partially resolved, not resolved or accepted as a risk by the client, with the date of the retest and the build or environment tested. Partial fixes are described precisely, including which variants still work. The client receives an updated report that keeps the original finding IDs so the history stays traceable to earlier versions.
Record what was and was not retested
The final statement lists the findings retested, the environment and build version examined, the accounts used, and any finding or area that was not retested, along with the reason. Clients should keep this section, because it defines the limit of what the retest supports. A finding marked resolved only applies to the retested build and scope, and later API changes are outside that statement.
Decide what the retest evidence supports
The client decides how to use the retest result, for example to close tickets, to answer a customer security questionnaire, or to provide evidence to an auditor or assessment body. Ask your auditor or customer whether they accept a retest letter or an updated report, and confirm the format they need. DeployOpen prepares the evidence; independent auditors and certification bodies decide whether it meets a given requirement.
What to check when choosing a mobile API testing provider
Choosing a provider for mobile backend testing is mostly a question of evidence: who has done this work, how they work, and what you receive. The checks below turn a sales conversation into criteria you can put in writing and compare across bids.
Mobile backend and OAuth experience
Ask for examples of work on the APIs behind mobile apps, not only general web testing. A capable tester should explain how a mobile client obtains tokens through OAuth 2.0 and OpenID Connect, where refresh tokens live on the device, and how the backend decides whether a token is still valid. Ask who on the team has done this work and how long they have done it. Confirm they will name the token flows they plan to examine before testing starts.
Method mapped to the API Top 10
Request the test plan and check that it names the OWASP API Security Top 10 2023 categories it covers, starting with Broken Object Level Authorization, Broken Authentication and Broken Object Property Level Authorization. The plan should also cite the relevant ASVS V4 requirements for APIs and V10 for OAuth and OIDC. A method that only lists generic tool runs and a vulnerability scanner output is a weak signal. Expect a mapping from each category to the test cases used.
Written scope before work starts
Insist on a written scope that lists the apps, platforms, API hosts and versions, user roles, test accounts, environments and any excluded functions. Confirm whether the test covers production data, rate limits and third-party services, and who approves testing windows. A scope that says only "the mobile backend" leaves room for disputes about what was covered. Ask how the scope changes if you add an endpoint or role during the engagement, and how that change is priced and recorded.
Sample report and retest terms
Ask for a redacted sample report before you sign. It should show each finding with its affected endpoint, the reproduction steps at a defensive level, the risk rating, and a remediation recommendation that a developer can act on. Confirm in writing whether a retest of fixed findings is included, how many rounds it covers, and whether the retest result is recorded in the same report or a separate letter. Ask whether the report can go to your auditor or customer without edits.
Tester supervision and access needs
Ask who supervises the testers, how their work is reviewed before reports are issued, and what access they need. Typical requests include test accounts for each role, a staging or agreed production environment, API documentation, and a named contact for emergencies. Check whether testers use client-provided devices and accounts, and how credentials are stored and destroyed at the end. Access should be limited to what the scope requires and logged.
Accreditation confirmed with the body
If a provider cites an accreditation, ask for the scheme, the accredited service and the date it was granted, then confirm it directly with the accrediting body. For mobile work, CREST's OWASP Verification Standard accreditation covers MASVS assessments at Levels 1 and 2 and web work against ASVS. Accreditation does not replace reviewing the sample report and the tester's experience. Ask whether the accreditation covers backend API work or only app binaries.
How DeployOpen scopes, tests, reports and retests mobile APIs
DeployOpen treats the backend behind a mobile app as its own test target, with scope agreed in writing before work starts. Testing covers object and function level authorization, OAuth and OIDC token handling and API abuse, with findings handed over in a form your engineers and assessors can act on.
How we scope
- Inventory the API endpoints, versions and environments the mobile client actually calls, agreed with your team before testing begins
- Confirm which user roles, tenants and test accounts you will provide, so authorization checks cover realistic access boundaries
- Record the agreed scope, deliverables and timeline in writing, since most engagements are fixed-scope
- Agree whether the test is aligned to OWASP API Security Top 10 2023, ASVS V4 and V10, or a combination you specify
How we build
- Prepare a test environment that mirrors production configuration, or confirm with you which differences apply
- Map identity flows, including how the app obtains, refreshes and revokes tokens for backend calls
- Test object and function level authorization across user roles, tenants and sensitive operations
- Exercise rate limits, abuse paths and business logic that the backend relies on for safe operation
How we hand over
- Deliver a written report that maps each finding to the relevant OWASP API Security Top 10 2023 category and ASVS requirement
- Describe affected endpoints, the conditions under which each weakness appears and the defensive fix we recommend
- Walk your engineering and security leads through findings and agree severity ratings and remediation owners
- Provide evidence suitable for your internal reviewers, customers or auditors, without issuing any audit opinion ourselves
How we support
- Retest agreed findings after fixes are deployed, and document which items are closed, open or accepted as risk
- Offer ongoing support and continuous testing as a retainer if your API changes frequently
- Confirm retest scope and any additional fees in writing before retesting starts
- Ask us to confirm the scope of retesting for each release, so coverage tracks what changed
