API Security Testing for Analysts: The OWASP API Top 10 as Test Cases

API security testing for analysts means proving that the API enforces the rules the business specified: who may see which object, which fields, which functions, and how often. That maps almost exactly onto the OWASP API Security Top 10 (2023), where most risks are authorization and business logic failures rather than exotic exploits. Analysts know those rules better than anyone, and can test most of them with Bruno or Postman and two test users.

To test API security as an analyst: get written authorization and an approved test environment; create at least two test identities with different ownership and roles; then turn each OWASP API Security Top 10 risk into test cases. Request user A’s objects with user B’s token (API1), break and misuse credentials (API2), look for exposed sensitive fields and try to set server-owned ones (API3), push limits (API4), call admin functions as a normal user (API5), abuse business flows (API6), probe URL-accepting fields only with security team approval (API7), and check configuration, old versions, and third-party trust (API8 to API10).

APIs for Analysts, advanced track. Builds on Part 5, API test cases and Part 6, chaining with JavaScript. Full learning path: APIs for Analysts.

What are the rules of engagement for analyst security testing?

Read this section before sending a single request. Security testing without permission is not testing, and in regulated industries it can be a disciplinary or legal matter.

• Written authorization first. Agree the scope, environments, and dates with the system owner and the security team.
• Approved test environments only. Never production, unless the security team explicitly runs a controlled exercise that includes you.
• Test identities and synthetic data. No real customer data, no borrowed colleague credentials.
• Only systems you are authorized to test. Never probe third-party APIs, including a vendor’s sandbox, beyond their published terms.
• No scanners, fuzzers, or load tools unless the security team owns and schedules them.
• Report privately through the agreed process, with tokens and data redacted. A security finding does not go in a public channel.

Scope matters too. What follows is functional security testing: verifying specified authorization and business rules at the API. Penetration testing and vulnerability research remain the security team’s work, and the best outcome of an analyst’s security tests is often a better-targeted brief for them.

Why are analysts well placed to test API security?

Because the most common API vulnerabilities are not about cryptography; they are about rules. Can a corporate user see another company’s payments? Can a maker approve their own payment? Can a client set their own fee? Can a refund exceed the original payment? Those are requirements questions first. The analyst wrote, or can read, the roles, the ownership model, and the four-eyes rules, so the analyst knows which request should fail.

How do you set up for API authorization testing?

Two identities minimum, three for role tests.

Identity	Tenant or owner	Role	Purpose
User A	Company A	Maker	Creates the objects under test
User B	Company B	Maker	Attempts to access A’s objects
User A2	Company A	Viewer	Tests function-level limits within the same tenant

In Bruno or Postman, hold each token in its own variable, never in files, and capture object IDs created by user A:

security-tests/
├── environments/sit.yml          # baseUrl; tokens come from .env
├── 00-setup/
│   └── create-payment-as-user-a.yml   # captures paymentIdA
├── 10-object-authorization/
├── 20-authentication/
├── 30-property-authorization/
├── 40-resource-limits/
├── 50-function-authorization/
└── 60-business-flows/

Setting the token per request is one line in a pre-request script:

// Bruno: act as user B for this request
req.setHeader("Authorization", `Bearer ${bru.getVar("tokenUserB")}`);

What are the OWASP API Security Top 10 risks, and how do you test each?

API1:2023 Broken Object Level Authorization

The risk: the API checks that the caller is authenticated but not that they may access this object. Change an ID, get someone else’s data.

Test	Expected
GET /payments/{paymentIdA} as user B	403 or 404; no payment data in the body
PATCH or POST /payments/{paymentIdA}/cancel as user B	Refused; payment unchanged when re-read as user A
List endpoints as user B with filters naming A’s IDs or references	A’s objects never returned
Nested routes: /accounts/{accountIdA}/transactions as user B	Refused
IDs in bodies, not just paths: a refund for paymentIdA created by user B	Refused

test("user B cannot read user A's payment", function () {
  expect([403, 404]).to.include(res.getStatus());
  const body = res.getBody() || {};
  expect(body).to.not.have.property("instructedAmount");
  expect(body).to.not.have.property("debtor");
});

Test every endpoint that takes an identifier, in paths, query parameters, and bodies. BOLA ranks first because it is common and trivially exploitable. It also appeared as TC-34 in Part 5 for exactly that reason.

API2:2023 Broken Authentication

The risk: weaknesses in how the API establishes identity.

Test	Expected
No token	401
Expired token	401
Token with one character changed in its signature	401
Token issued for another environment	401
Token sent in a query string instead of the header	Not accepted
Repeated failed logins or token requests	Lockout or throttling per the requirements
Token after logout or revocation	401

API3:2023 Broken Object Property Level Authorization

The risk: the caller may access the object, but not every property. Two forms: excessive data exposure in responses, and mass assignment in requests.

Test	Expected
Read own payment as a viewer role	Restricted fields such as internal risk notes or full account numbers absent or masked
Create a payment with "status": "ACSC" in the body	Field ignored or request rejected; payment starts in its initial status
Update a profile with "role": "admin"	Ignored or rejected
Create a payment with "fee": "0.00"	Ignored; fee calculated by the server
Compare response fields against the documented schema	No undocumented fields leaking internal data

Mass assignment is the security side of a design principle from API design review: server-owned fields must not be writable.

API4:2023 Unrestricted Resource Consumption

The risk: no effective limits on request size, frequency, or cost.

Test	Expected
?limit=100000 on a list	Capped at the documented maximum
Oversized request body	413 or a clear validation error
Burst beyond the documented rate limit	429 with Retry-After
Expensive operations such as exports or reports repeated quickly	Limited or queued
Very long strings in every text field	Rejected by length validation

Keep bursts small and agreed with the environment owner. The goal is to confirm limits exist, not to degrade a shared test environment.

API5:2023 Broken Function Level Authorization

The risk: a user can call functions intended for another role.

Test	Expected
Viewer calls POST /payments	403
Maker calls POST /payments/{id}/approve for their own payment	403: four-eyes rule enforced at the API
Regular user calls /admin/... endpoints discovered in documentation or the browser Network tab	403
Same path, different method: GET allowed, DELETE attempted	403 or 405

The own-approval case is the analyst’s test. Segregation of duties is a business control; whether the API enforces it or only the screen hides the button is exactly what this proves.

API6:2023 Unrestricted Access to Sensitive Business Flows

The risk: a legitimate flow can be automated or repeated in ways that harm the business, without breaking any single rule.

Test	Expected
Partial refunds whose total exceeds the original payment	Refused once the remaining amount is reached
Many small-value payments to new beneficiaries in quick succession	Velocity controls trigger per requirements
Beneficiary added and paid immediately, bypassing a cooling-off period	Cooling-off enforced by the API
Promotional or fee-waiver flows repeated per account	Limited per the business rule

These tests come straight from business rules and fraud controls, which is why they are the most analyst-specific category in the list.

API7:2023 Server Side Request Forgery

The risk: the API fetches a URL supplied by the client, such as a webhook URL, a logo URL, or a document link, and can be tricked into calling internal addresses.

Identify every field that accepts a URL. Then, only with the security team’s explicit approval and in their chosen environment, verify that URLs pointing to internal or loopback addresses are rejected, that only allowed schemes such as https are accepted, and that redirects are not followed to disallowed destinations. Probing cloud metadata or internal network addresses is an area where the security team should design or run the test with you.

API8:2023 Security Misconfiguration

Test	Expected
Trigger a 500 or malformed request	No stack traces, SQL, framework names, or internal hostnames in the body
Plain http:// request	Refused or redirected; never served over plain HTTP
Cross-origin request headers	Access-Control-Allow-Origin not * on authenticated endpoints
OPTIONS and unusual methods	Only intended methods enabled
Response headers	No detailed server version banners

API9:2023 Improper Inventory Management

The risk: forgotten API versions, undocumented endpoints, and non-production environments that are less protected.

• Call the previous version (/v1/...) of endpoints that have a /v2: do the same authorization tests pass there?
• Compare endpoints seen in the browser’s Network tab against the published contract: any undocumented ones?
• Check whether test environments reachable by partners contain real data.

Old versions are the classic gap: controls added to v2 that were never back-ported. API versioning and breaking changes covers retiring them properly.

API10:2023 Unsafe Consumption of APIs

The risk: your system trusts data from third-party APIs more than user input.

Use a mock of the third-party API, such as a Prism mock from its OpenAPI file with edited examples, to return oversized fields, unexpected types, script content in text fields, redirects, and timeouts. Your system should validate, sanitize, and fail safely, exactly as it would for user input. Mock-driven testing is covered in Part 7.

How do you automate authorization tests across endpoints?

BOLA and function-level tests share one shape: an endpoint, an identity, an expected refusal. That is a data file.

[
  { "caseId": "SEC-01", "method": "GET",  "path": "/v1/payments/{{paymentIdA}}",        "actor": "tokenUserB",  "expect": [403, 404] },
  { "caseId": "SEC-02", "method": "POST", "path": "/v1/payments/{{paymentIdA}}/cancel", "actor": "tokenUserB",  "expect": [403, 404] },
  { "caseId": "SEC-03", "method": "POST", "path": "/v1/payments/{{paymentIdA}}/approve","actor": "tokenUserA",  "expect": [403] },
  { "caseId": "SEC-04", "method": "POST", "path": "/v1/payments",                       "actor": "tokenUserA2", "expect": [403] }
]

A before-request script sets the method, the interpolated URL, and the actor’s token from the row; a tests script asserts the status is in expect and that no protected fields appear. Adding an endpoint to the security suite becomes adding a line, which is how coverage keeps pace with the API. The data-driven mechanics are shown in full in Part 5, and running the suite on every build in API tests in CI.

How do you report an API security finding?

Privately, precisely, and without spreading the weakness.

ID: SEC-03   Severity (proposed): High   Environment: SIT   Date (UTC): 2026-09-15
Rule: Maker cannot approve own payment (REQ-PAY-044, four-eyes control)
Observed: POST /v1/payments/{id}/approve by the creating maker returned 200;
          payment moved to APPROVED.
Expected: 403 with SELF_APPROVAL_NOT_ALLOWED; status unchanged.
Evidence: Request and response attached, tokens redacted. Trace ID: a1b2c3d4.
Scope note: UI hides the approve button for the maker; the API does not enforce it.

The scope note is often the most valuable line: it tells everyone the control existed only in the screen.

The APIs for Analysts learning path

Beginner: What is an API · API glossary · JSON for analysts · HTTP status codes · Your first collection · Why did my API request fail? · Reading an API contract

Intermediate: Analyze an API · Document an API · API test cases · Chaining and scripts · Webhooks · GraphQL

Advanced: POCs and demos · API design review · Versioning and breaking changes · API security testing (you are here) · API tests in CI

The takeaway

The OWASP API Security Top 10 (2023) is mostly a list of authorization and business logic failures, which makes it a natural test design framework for analysts. Work inside written authorization, set up at least two test identities, and turn each risk into cases: other users’ objects, broken credentials, exposed and writable properties, missing limits, role bypass, abusable business flows, and, with the security team, URL fetching, configuration, old versions, and third-party trust. Automate the repeatable authorization checks from a data file, and report findings privately with the rule, the evidence, and whether the control lived only in the UI.

For the test design discipline behind these cases, see API Testing and QA Mastery for BAs. Want help scoping an authorization test suite for your own API? Book a 1:1 Tech BA Coaching Call.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: API Security, OWASP, Authorization Testing, QA, Payments