Quick Answer

API security is the practice of protecting application programming interfaces against unauthorized access, data leakage, and abuse. The OWASP API Security Top 10 (2023) lists the ten most critical risks. The most dangerous item is BOLA (Broken Object Level Authorization), where an attacker changes an identifier to reach another user's data. API penetration testing verifies these risks within authorized scope, backed by proof.

Why Is API Security Different from Web Security?

In traditional web applications, the server renders HTML pages and most business logic stays hidden on the server side. In an API-centric architecture, the client (a mobile app, a single page application, or another service) talks directly using raw data, most often in JSON format. This fundamentally changes the attack surface.

An API openly exposes its business logic and data model to the client. An attacker observing the network traffic can see which endpoints exist, which parameters are accepted, and how data is structured. Browser based protections (same origin policy, content security policy) are often irrelevant for API calls, because the client may not even be a browser.

More importantly, APIs are typically distributed across many microservices. Each service makes its own authorization decision, and when those decisions are inconsistent, authorization vulnerabilities appear. This is why API testing goes beyond the classic website security testing and WAF approach and focuses on authorization logic, data flow, and trust relationships between services.

API Types and Security Implications

Three main API architectures dominate enterprise environments, and each has distinct security characteristics:

Property REST GraphQL gRPC
Data format Usually JSON JSON Protocol Buffers (binary)
Endpoint structure Many endpoints per resource Single endpoint Service/method based
Query flexibility Fixed response Client defines the query Fixed contract
Typical vulnerability BOLA, mass assignment Nested query DoS, introspection leak Discovery via reflection, weak TLS
Discovery ease Medium (docs, fuzzing) High (if introspection is open) Low (binary, proto needed)
Rate limiting Easy per endpoint Complex (query cost) Hard (stream based)

Because REST APIs use separate endpoints per resource (for example /api/users/123), they are most exposed to object level authorization flaws. GraphQL offers flexible queries over a single endpoint; that power brings the risks of denial of service through nested queries and schema leakage through introspection. gRPC uses binary Protocol Buffers and looks more opaque on the surface, but when server reflection is left enabled, the entire service contract can be discovered.

OWASP API Security Top 10 (2023) Items

The OWASP API Security Top 10 is the industry standard reference that ranks API specific risks. Below we explain each item with what it is, an example scenario, how to test, and how to defend.

API1:2023 Broken Object Level Authorization (BOLA)

What it is: The API does not verify whether the user accessing an object is actually authorized for that object. When the object identifier in the request is changed, another user's data is exposed. This is the most common and most damaging API vulnerability.

Example scenario: A user retrieves their own invoice:

GET /api/v1/invoices/1001 HTTP/1.1
Authorization: Bearer eyJhbGciOi...

The attacker changes the identifier from 1001 to 1002:

GET /api/v1/invoices/1002 HTTP/1.1
Authorization: Bearer eyJhbGciOi...

If the server does not check whether the logged in user owns invoice 1002, another customer's invoice is returned. Sequentially enumerating identifiers can leak the entire database.

How to test: Two separate user accounts are created. User A's object identifiers are requested using user B's session. If the response data belongs to A rather than B, the vulnerability is confirmed. Numeric identifiers, UUIDs, email addresses, and indirect references are tried one by one, and identifier ranges are scanned with automation.

How to defend: Every request must enforce, on the server side, that the session owner is authorized for the requested object. Using random UUIDs instead of predictable sequential identifiers helps but is not sufficient alone; the real fix is an ownership check on every object access.

API2:2023 Broken Authentication

What it is: Authentication mechanisms are implemented incorrectly; an attacker steals credentials or bypasses verification. Weak token generation, tokens that never expire, and the absence of attempt limits all fall into this class.

Example scenario: The login endpoint has no rate limiting and no account lockout. The attacker performs credential stuffing with a stolen password list, making hundreds of attempts per second to take over accounts. Also, if the JWT signature algorithm is accepted as none, the attacker can forge an unsigned token.

How to test: Attempt limits are tested on login, password reset, and token refresh endpoints. JWT tokens are decoded; algorithm confusion (HS256 instead of RS256), the none algorithm, and weak signing keys are tried. Whether tokens expire and are invalidated on logout is checked.

How to defend: Multi factor authentication, strong and verified JWT signing, short token lifetimes, rate limiting on login endpoints, and account lockout are applied. The algorithm is fixed on the server side; never trust the algorithm specified by the client.

API3:2023 Broken Object Property Level Authorization (BOPLA)

What it is: The API does not enforce authorization on individual properties (fields) of an object. This appears both as excessive data exposure (returning fields the user should not see) and as mass assignment (allowing the user to update fields they should not change).

Example scenario: A profile update request expects only name and phone, but the client adds extra fields:

PATCH /api/v1/users/me HTTP/1.1
Content-Type: application/json

{"name": "Ali", "phone": "5xx", "role": "admin", "isVerified": true}

If the server blindly binds the incoming JSON to the object, the user makes themselves an administrator. Conversely, if a user list response returns passwordHash or internalNotes, that is excessive exposure.

How to test: Responses are inspected for extra fields. Sensitive fields such as role, isAdmin, balance, and verified are added to request bodies to see if they are accepted. A full object obtained from a prior read request is sent back in an update request to observe which fields are writable.

How to defend: Explicit allow list schemas are used for both input and output. Data from the client is never bound directly to the data model; only permitted fields are selected. Responses explicitly define which fields are returned.

API4:2023 Unrestricted Resource Consumption

What it is: The API places no limit on the resources (CPU, memory, network, third party costs) consumed per request. This leads to denial of service and cost explosions.

Example scenario: An endpoint accepts an unbounded limit pagination value. The attacker sends ?limit=10000000 to exhaust the server. Or when an SMS verification endpoint can be called without limit, the attacker triggers thousands of messages and runs up a large bill for the company.

How to test: Pagination, file upload size, and batch operation counts are subjected to limit testing. Excessively large values, many concurrent requests, and large payloads are sent. The rate limits of costly operations like SMS, email, and payment are inspected.

How to defend: Request size, pagination, concurrency, and execution time are limited. Rate limiting is applied per IP and per user. Costly operations get additional verification and strict quotas.

API5:2023 Broken Function Level Authorization (BFLA)

What it is: The API does not verify whether the user calling a function (usually administrative functions) is authorized for it. BOLA targets objects, while BFLA targets actions/endpoints.

Example scenario: A regular user calls an admin endpoint directly:

DELETE /api/v1/admin/users/500 HTTP/1.1
Authorization: Bearer <regular-user-token>

If the server only hides the admin button in the UI but does not check the role at the endpoint, a normal user can delete other accounts. Switching the HTTP method (trying PUT/DELETE instead of GET) also reveals authorization gaps.

How to test: Admin and privileged endpoints are called with low privileged accounts. Hidden endpoints discovered from documentation or JavaScript files are tried. Different HTTP methods (PUT, DELETE, PATCH) are tested against the same path.

How to defend: Role and permission checks are enforced centrally on the server side for every endpoint. A deny by default principle is applied; an endpoint is inaccessible unless access is explicitly granted.

API6:2023 Unrestricted Access to Sensitive Business Flows

What it is: The API does not protect a business flow against automated and excessive use. Even though each request is technically valid, mass automation of the flow harms the business.

Example scenario: The purchase flow of a limited stock product is consumed in seconds by bots, locking out real customers (scalping). Or a review/voting flow is manipulated with bots. Each request is legitimate on its own; the problem is scale and automation.

How to test: Critical business flows (registration, purchase, coupon use, invitations) are automated with scripts and repeated at high speed. The presence of bot detection, CAPTCHA, device fingerprinting, and behavioral controls is observed.

How to defend: Anti automation measures are added at the business flow level: rate limiting, bot detection, second channel verification, anomalous behavior monitoring, and per flow quotas. Protection should be prioritized by business impact.

API7:2023 Server Side Request Forgery (SSRF)

What it is: The API fetches a user supplied URL without validation. The attacker tricks the server into making requests to the internal network or to a cloud metadata service.

Example scenario: An endpoint fetches a remote image:

POST /api/v1/import-image HTTP/1.1
Content-Type: application/json

{"imageUrl": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

If the server fetches this URL blindly, temporary credentials are leaked from the cloud provider's metadata service. Internal addresses like http://localhost:8080/admin can also be targeted.

How to test: All parameters that accept a URL are identified (webhook, image import, PDF generation, link preview). Internal IPs, localhost, cloud metadata addresses, and a controlled external server (out of band) are supplied to these parameters. Whether a callback reaches the controlled server is monitored.

How to defend: User supplied URLs are validated against a strict allow list. Internal IP ranges and metadata addresses are blocked. Redirects are not followed or are restricted. Calls are made from a separate network segment.

API8:2023 Security Misconfiguration

What it is: Insecure defaults, missing hardening, or unnecessary exposed features exist at any layer of the API stack. Missing security headers, overly permissive CORS, verbose error messages, and open debug endpoints belong here.

Example scenario: The API accepts credentials together with Access-Control-Allow-Origin: *, so a malicious site can make requests using the user's session. Or an error response returns a full stack trace and database query, exposing the internal structure.

How to test: Security headers, CORS policy, TLS configuration, the verbosity of error messages, and unnecessary HTTP methods (TRACE, OPTIONS) are audited. Default credentials, exposed admin panels, and old API versions are searched.

How to defend: A consistent, hardened, and automated configuration is applied across all environments. Error messages are kept generic and do not leak internal detail. CORS is opened only to trusted origins. Unnecessary features and methods are disabled.

API9:2023 Improper Inventory Management

What it is: The organization does not fully know which APIs, which versions, and which endpoints are live. Old (/api/v1), test (/api/beta), or shadow APIs remain exposed without being updated.

Example scenario: While production /api/v2 is hardened, a forgotten /api/v1 gives access to the same data with weak authentication. The attacker discovers the old version and bypasses all protections of the new one.

How to test: Version numbers, subdomains, old paths, and documentation files (Swagger/OpenAPI definitions) are searched. Unknown endpoints are derived through passive reconnaissance, DNS, certificate transparency logs, and JavaScript analysis.

How to defend: A central, up to date inventory of all APIs and versions is maintained. Deprecated versions are shut down. Test environments are isolated from production data and from the internet. OpenAPI definitions are made the source of access control.

API10:2023 Unsafe Consumption of APIs

What it is: Developers trust data from third party APIs more than data from their own users. If an integrated external service is compromised or returns bad data, that data is processed without validation.

Example scenario: The response from a payment or enrichment service is written to the database without validation. If the external service responds with an injection payload, that payload runs in the internal system. Blindly following redirects also produces SSRF like outcomes.

How to test: External API integrations are mapped. Where possible, the external service's response is simulated (by intercepting with a proxy) to observe the application's behavior when malformed or malicious data is returned. Whether TLS validation is active is checked.

How to defend: Third party data is validated and sanitized like user data. TLS is enforced on external calls and certificates are validated. Redirects from external services are not followed. Timeout and circuit breaker mechanisms are used.

The API Penetration Testing Process

An enterprise API penetration test is much more than running random tools. It follows a structured, scoped, and evidence based process. For the standards and pricing of the process, see our penetration testing process and pricing article; here we focus on API specific steps.

1. Scoping and Authorization

Before testing, the target APIs, domains, environments (production or staging), account roles, and excluded operations are explicitly defined in writing. In API testing, providing at least two accounts at the same privilege level (for example two normal users, plus one admin) is critical for BOLA and BFLA testing. Test limits for costly operations (SMS, payment) are set.

2. Discovery and Inventory

All endpoints, parameters, and data flows are mapped. OpenAPI/Swagger documentation, mobile app traffic, JavaScript files, and network capture (proxy) data are combined to produce a complete surface. For GraphQL, the introspection query is tried; for gRPC, server reflection is checked. This step also directly assesses the API9 (inventory) risk.

3. Authentication and Session Analysis

Authentication flows, token structure (JWT claims), token lifetime, and the refresh mechanism are examined. How the token is generated, signed, and invalidated is verified.

4. Authorization Testing

This is the heart of the process. Each endpoint is exercised with different accounts and different object identifiers to find horizontal (BOLA) and vertical (BFLA) privilege escalation. This is where automation and human analysis come together.

5. Business Logic and Input Testing

Mass assignment, excessive data exposure, SSRF, injection, and sensitive business flow abuse are tested. Business logic flaws are the area that automated tools miss and that requires human reasoning.

6. Verification and Reporting

Every finding is verified with proof (PoC) and false positives are eliminated. This is the foundation of enterprise trust; noisy, unverified reports waste time. In our verified vulnerability, false positive free testing approach, every vulnerability is presented with proof and closed with a clear remediation recommendation.

API Testing Tools

No single tool is enough in API testing; a combination of manual discovery, automated scanning, and custom scripts is required.

  • Postman: Widely used to build API requests, manage collections, and manually test authorization flows. Repeatable scenarios are set up with environment variables and test scripts.
  • Burp Suite: Captures traffic via a proxy, replays requests (Repeater), automatically mutates parameters (Intruder), and scans identifier ranges for BOLA. It is the backbone of enterprise API testing.
  • OWASP ZAP: An open source intercepting proxy and scanner. By importing an OpenAPI definition, it performs automated endpoint scanning and offers passive and active scanning.
  • GraphQL tools: Specialized tools that extract the schema via introspection and generate nested query payloads test GraphQL specific risks.

These tools are powerful, but detecting authorization logic and business flow vulnerabilities at scale, without false positives, requires automation.

Automated and Continuous API Testing with KAOS

KAOS, the AI security engine, is the AI powered offensive security agent developed by DSET. In authorized penetration tests, it automates reconnaissance, vulnerability detection, exploit generation, and verification (with proof/PoC, free of false positives).

In API testing, KAOS performs automatic endpoint discovery to map the surface, systematically runs BOLA and BFLA tests with multiple accounts, and verifies findings with proof. In continuous scanning mode, new versions and changed endpoints are re tested regularly, so API9 inventory drift is caught early. All testing runs within authorized, defined scope. KAOS does not replace an experienced tester; it automates the repetitive, wide surface work so the expert can focus on business logic analysis.

Special Notes for REST, GraphQL, and gRPC Testing

REST: Because of its resource based structure, BOLA testing is central. Every /{resource}/{id} pattern is tried with different accounts. For mass assignment, the full object is sent back.

GraphQL: A single endpoint offers flexible queries. If introspection is open, the entire schema leaks; it must be disabled. Nested relational queries (for example the authors of comments of authors) cause denial of service if there is no depth limit. Query cost and depth limiting are tested. Authorization must be checked at each field level.

gRPC: Uses binary Protocol Buffers and HTTP/2. If server reflection is open, the service definition is discoverable. TLS configuration, resource consumption in streaming calls, and method level authorization are priority test areas.

Frequently Asked Questions

Are API security and web application security the same thing?

No. Web application testing mostly focuses on server rendered pages, while API testing focuses on raw data exchange, authorization logic, and inter service trust. APIs directly expose business logic and the data model; therefore authorization vulnerabilities like BOLA and BFLA are far more dominant in APIs.

What is the most common API vulnerability?

BOLA (Broken Object Level Authorization) ranks first in the OWASP API Security Top 10 and is the most frequently encountered vulnerability in practice. The attacker changes the object identifier in the request to access another user's data. The fix is server side ownership verification on every object access.

Are GraphQL APIs more secure than REST?

By nature they are neither more nor less secure; they carry different risks. GraphQL's flexibility creates its own risks such as denial of service through nested queries and schema leakage through introspection. Enforcing authorization at the field level and limiting query depth/cost is essential.

How often should API penetration testing be done?

At least once a year and after every significant architectural change, new version release, or new integration is recommended. Because APIs change frequently, continuous (automated) scanning combined with periodic deep manual testing gives the most effective result. Tools like KAOS provide the continuous scanning layer.

Why do false positive reports cause problems?

Unverified findings waste teams' time, let real vulnerabilities hide in the noise, and erode trust. That is why verifying every finding with proof (PoC) and presenting it with a clear remediation recommendation is essential to an enterprise test.

Sources

API security is the fastest growing attack surface for modern organizations, and when tested incorrectly, a single BOLA vulnerability can put all customer data at risk. Combine expert analysis with KAOS's continuous, evidence based automation to verify your APIs against real world attacks.

DSET Information and Cyber Security (founded 2003). For enterprise API security testing and continuous scanning with KAOS: +90 536 662 38 09.