# OWASP API Security Top 10:2023

Locale: `en`

Source: `/en/compliance/owasp-top-10/api/`

Summary: A guide to the current stable OWASP API Security Top 10:2023 categories for APIs, integrations, and service-to-service boundaries.

On this page

1. [Overview](/en/compliance/owasp-top-10/api/#topic-overview)
2. [API1:2023 Broken Object Level Authorization](/en/compliance/owasp-top-10/api/#broken-object-level-authorization)
3. [API2:2023 Broken Authentication](/en/compliance/owasp-top-10/api/#broken-authentication)
4. [API3:2023 Broken Object Property Level Authorization](/en/compliance/owasp-top-10/api/#broken-object-property-level-authorization)
5. [API4:2023 Unrestricted Resource Consumption](/en/compliance/owasp-top-10/api/#unrestricted-resource-consumption)
6. [API5:2023 Broken Function Level Authorization](/en/compliance/owasp-top-10/api/#broken-function-level-authorization)
7. [API6:2023 Unrestricted Access to Sensitive Business Flows](/en/compliance/owasp-top-10/api/#unrestricted-access-to-sensitive-business-flows)
8. [API7:2023 Server Side Request Forgery](/en/compliance/owasp-top-10/api/#server-side-request-forgery)
9. [API8:2023 Security Misconfiguration](/en/compliance/owasp-top-10/api/#security-misconfiguration)
10. [API9:2023 Improper Inventory Management](/en/compliance/owasp-top-10/api/#improper-inventory-management)
11. [API10:2023 Unsafe Consumption of APIs](/en/compliance/owasp-top-10/api/#unsafe-consumption-of-apis)
12. [Readiness Assessment](/en/compliance/owasp-top-10/api/#compliance-readiness-checklist)
13. [Related Frameworks](/en/compliance/owasp-top-10/api/#related-compliance-frameworks)

# OWASP API Security Top 10:2023

A guide to the current stable OWASP API Security Top 10:2023 categories for APIs, integrations, and service-to-service boundaries.

Edition 2023. Risk names follow the official OWASP publication.

API1:2023

## Broken Object Level Authorization

Broken Object Level Authorization, often called BOLA, occurs when an API accepts an object identifier such as a user, order, or document ID without proving the caller owns or may access that object. A normal user can change an ID in a request to read, alter, or delete another account's data.

**Risk at a glance**

| What can go wrong | An API accepts an object identifier without confirming that the caller is allowed to access that specific object. |
| --- | --- |
| Business effect | Changing an identifier can expose or change another customer's record, file, payment, or transaction. |
| First control to verify | Authorize every object reference server-side. |

[![API1:2023 Broken Object Level Authorization: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-broken-object-level-authorization-en-v1.webp)](/assets/compliance/owasp-api-broken-object-level-authorization-en-v1.webp)

**API1:2023 Broken Object Level Authorization**

Every object reference requires authorization.

- **Attack entry** — A caller changes an API object identifier.
- **Security failure** — Ownership authorization is missing.
- **Impact** — Another customer record is exposed or changed.
- **Stop/control** — Authorize every object reference server-side.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

Changing an identifier can expose or change another customer's record, file, payment, or transaction.

### Risk-reduction focus

- Authorize every object reference server-side.
- Use tenant-aware data access patterns.
- Test create, read, update, delete, and export paths.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API2:2023

## Broken Authentication

Broken Authentication means an API misidentifies clients or fails to protect credentials and tokens. Predictable tokens, unchecked signatures or expiry, unlimited password guessing, and sessions that survive password change can let an attacker call every trusting endpoint as someone else.

**Risk at a glance**

| What can go wrong | API identity, token, session, credential, or recovery mechanisms can be bypassed, replayed, or abused. |
| --- | --- |
| Business effect | An attacker can impersonate a user or service and access the API with an invalid or stolen identity. |
| First control to verify | Use established identity protocols and token validation. |

[![API2:2023 Broken Authentication: Attack entry, Security failure, Impact, Risk reduction](/assets/compliance/owasp-api-broken-authentication-en-v2.webp)](/assets/compliance/owasp-api-broken-authentication-en-v2.webp)

**API2:2023 Broken Authentication**

A token must establish the correct identity.

- **Attack entry** — An attacker replays an expired token
- **Security failure** — The API skips the token expiration check
- **Impact** — An invalid token still grants access to an account or service
- **Risk reduction** — Validate signatures, expiration, and session status

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

An attacker can impersonate a user or service and access the API with an invalid or stolen identity.

### Risk-reduction focus

- Use established identity protocols and token validation.
- Protect credential issuance, rotation, and revocation.
- Rate-limit and monitor authentication and recovery.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API3:2023

## Broken Object Property Level Authorization

Broken Object Property Level Authorization occurs when an API authorizes an object but not which fields a caller may read or change. A response may expose salary or internal flags, or a request may accept isAdmin. It combines the roots of excessive data exposure and mass assignment.

**Risk at a glance**

| What can go wrong | An API exposes or accepts properties that the caller should not be able to read or modify. |
| --- | --- |
| Business effect | Sensitive fields can leak, or a client can alter a role, price, workflow state, or internal-only attribute. |
| First control to verify | Define explicit read and write schemas by role. |

[![API3:2023 Broken Object Property Level Authorization: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-broken-object-property-level-authorization-en-v1.webp)](/assets/compliance/owasp-api-broken-object-property-level-authorization-en-v1.webp)

**API3:2023 Broken Object Property Level Authorization**

Object authorization includes every field.

- **Attack entry** — A client adds a role property to JSON.
- **Security failure** — Properties are not restricted by permission.
- **Impact** — Roles, prices, or sensitive fields change or leak.
- **Stop/control** — Use explicit role-based read and write schemas.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

Sensitive fields can leak, or a client can alter a role, price, workflow state, or internal-only attribute.

### Risk-reduction focus

- Define explicit read and write schemas by role.
- Return only fields required by each use case.
- Reject mass assignment and unknown properties.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API4:2023

## Unrestricted Resource Consumption

Unrestricted Resource Consumption means an API lacks suitable limits for request volume, payload size, pagination, query complexity, or paid downstream calls such as SMS and biometrics. A malicious or faulty client can consume CPU, memory, bandwidth, or provider credit until cost or availability suffers.

**Risk at a glance**

| What can go wrong | Requests can consume excessive compute, memory, storage, network capacity, or paid downstream services. |
| --- | --- |
| Business effect | A client can degrade service, create unexpected cost, or make critical API functions unavailable to others. |
| First control to verify | Set rate, size, depth, and time limits. |

[![API4:2023 Unrestricted Resource Consumption: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-unrestricted-resource-consumption-en-v1.webp)](/assets/compliance/owasp-api-unrestricted-resource-consumption-en-v1.webp)

**API4:2023 Unrestricted Resource Consumption**

API resources need enforced bounds.

- **Attack entry** — Automation sends oversized repeated requests.
- **Security failure** — Rate, size, depth, and time limits are absent.
- **Impact** — Service degrades and costs rise.
- **Stop/control** — Enforce quotas and bounded requests.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

A client can degrade service, create unexpected cost, or make critical API functions unavailable to others.

### Risk-reduction focus

- Set rate, size, depth, and time limits.
- Apply quotas and cost-aware controls by client.
- Monitor saturation and degrade safely.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API5:2023

## Broken Function Level Authorization

Broken Function Level Authorization means user and administrator endpoints are not clearly separated or roles are not checked for every sensitive function, such as export, approve, refund, or user administration. A caller with an ordinary token can guess a path or method and invoke elevated work directly.

**Risk at a glance**

| What can go wrong | An API endpoint or action is reachable by a caller whose role should not perform that function. |
| --- | --- |
| Business effect | A normal user can invoke administrative, approval, reporting, or configuration actions. |
| First control to verify | Enforce function permissions in the API layer. |

[![API5:2023 Broken Function Level Authorization: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-broken-function-level-authorization-en-v1.webp)](/assets/compliance/owasp-api-broken-function-level-authorization-en-v1.webp)

**API5:2023 Broken Function Level Authorization**

A hidden endpoint does not authorize an action.

- **Attack entry** — An ordinary token guesses an admin route.
- **Security failure** — Function permission checks are missing.
- **Impact** — A normal user invokes administrative work.
- **Stop/control** — Enforce permissions in the API layer.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

A normal user can invoke administrative, approval, reporting, or configuration actions.

### Risk-reduction focus

- Enforce function permissions in the API layer.
- Deny by default and centralize policy decisions.
- Test every role against every sensitive endpoint.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API6:2023

## Unrestricted Access to Sensitive Business Flows

Unrestricted Access to Sensitive Business Flows means an API exposes a legitimate business action without compensating for large-scale automation. Ticket buying, coupon use, account registration, or comment posting may be correct functions, yet harmful when a machine repeats them at scale. The gap is business abuse control, not necessarily injection.

**Risk at a glance**

| What can go wrong | An API permits automation or repetition of a legitimate high-value business flow without enough abuse resistance. |
| --- | --- |
| Business effect | Attackers can exhaust inventory, manipulate promotions, enumerate offers, or overwhelm verification and booking flows. |
| First control to verify | Model abuse cases for valuable workflows. |

[![API6:2023 Unrestricted Access to Sensitive Business Flows: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-unrestricted-access-to-sensitive-business-flows-en-v1.webp)](/assets/compliance/owasp-api-unrestricted-access-to-sensitive-business-flows-en-v1.webp)

**API6:2023 Unrestricted Access to Sensitive Business Flows**

A valid request can abuse a business flow.

- **Attack entry** — Bots repeat a valid booking flow.
- **Security failure** — Abuse resistance is absent.
- **Impact** — Inventory and critical flows are exhausted.
- **Stop/control** — Apply risk-based automation limits.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

Attackers can exhaust inventory, manipulate promotions, enumerate offers, or overwhelm verification and booking flows.

### Risk-reduction focus

- Model abuse cases for valuable workflows.
- Use rate, velocity, and fraud controls suited to the flow.
- Observe business metrics and investigate anomalies.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API7:2023

## Server Side Request Forgery

Server Side Request Forgery, or SSRF, occurs when an API fetches a caller-supplied URL without strict destination validation. An attacker can coerce a trusted server to reach an internal service, metadata endpoint, or destination unavailable through the external firewall.

**Risk at a glance**

| What can go wrong | A server fetches a caller-controlled URL or network destination without enough destination controls. |
| --- | --- |
| Business effect | The server can be used to reach internal services, metadata endpoints, or trusted network resources. |
| First control to verify | Allow-list required destinations and protocols. |

[![API7:2023 Server Side Request Forgery: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-server-side-request-forgery-en-v1.webp)](/assets/compliance/owasp-api-server-side-request-forgery-en-v1.webp)

**API7:2023 Server Side Request Forgery**

Caller-supplied destinations are untrusted.

- **Attack entry** — A caller supplies a URL for server fetch.
- **Security failure** — Destinations and protocols are unconstrained.
- **Impact** — Internal services become reachable.
- **Stop/control** — Allow-list destinations and protocols.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

The server can be used to reach internal services, metadata endpoints, or trusted network resources.

### Risk-reduction focus

- Allow-list required destinations and protocols.
- Block private, loopback, and metadata ranges as appropriate.
- Use egress controls and log outbound requests.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API8:2023

## Security Misconfiguration

API Security Misconfiguration is unsafe setup of gateways, servers, cloud services, CORS, TLS, error handling, or API features. Production introspection or debug endpoints, wildcard credentialed CORS, and unnecessary methods expand the attack surface even when business logic is correct.

**Risk at a glance**

| What can go wrong | API gateways, CORS, headers, cloud resources, error handling, or defaults expose more than intended. |
| --- | --- |
| Business effect | Consumers may obtain debug data, invoke unnecessary methods, or connect to an exposed management surface. |
| First control to verify | Harden gateways and cloud services from a baseline. |

[![API8:2023 Security Misconfiguration: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-security-misconfiguration-en-v1.webp)](/assets/compliance/owasp-api-security-misconfiguration-en-v1.webp)

**API8:2023 Security Misconfiguration**

The gateway defines API exposure.

- **Attack entry** — A consumer finds permissive CORS.
- **Security failure** — Gateway and cloud defaults lack hardening.
- **Impact** — Debug or management surfaces are exposed.
- **Stop/control** — Harden from a verified baseline.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

Consumers may obtain debug data, invoke unnecessary methods, or connect to an exposed management surface.

### Risk-reduction focus

- Harden gateways and cloud services from a baseline.
- Disable unused methods and detailed production errors.
- Continuously test configuration drift.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API9:2023

## Improper Inventory Management

Improper Inventory Management means an organization does not fully know which API hosts, endpoints, versions, environments, and owners are exposed. Forgotten legacy APIs, public staging, and undocumented debug endpoints can miss patching and monitoring, giving attackers a path the team no longer remembers.

**Risk at a glance**

| What can go wrong | Teams do not know all API hosts, versions, environments, owners, and exposed data flows. |
| --- | --- |
| Business effect | An old or shadow endpoint can remain internet-accessible with outdated controls or undocumented sensitive data. |
| First control to verify | Maintain an owned inventory of API versions and hosts. |

[![API9:2023 Improper Inventory Management: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-improper-inventory-management-en-v1.webp)](/assets/compliance/owasp-api-improper-inventory-management-en-v1.webp)

**API9:2023 Improper Inventory Management**

You cannot protect an API you do not know exists.

- **Attack entry** — An attacker locates an old API version.
- **Security failure** — Hosts, versions, and owners are unknown.
- **Impact** — A shadow endpoint retains outdated controls.
- **Stop/control** — Maintain an owned API inventory.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

An old or shadow endpoint can remain internet-accessible with outdated controls or undocumented sensitive data.

### Risk-reduction focus

- Maintain an owned inventory of API versions and hosts.
- Retire endpoints deliberately and remove stale DNS/routes.
- Document data classification and consumer contracts.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

API10:2023

## Unsafe Consumption of APIs

Unsafe Consumption of APIs occurs when a service trusts third-party API responses more than user input, then renders, queries, redirects, or updates records without validating schema and authorization. A compromised or faulty provider can turn the integrating service into a path that harms its own users.

**Risk at a glance**

| What can go wrong | An application trusts data, availability, authentication, or behavior from an upstream API more than it should. |
| --- | --- |
| Business effect | A compromised or unreliable provider can inject bad data, trigger unsafe actions, or degrade a dependent service. |
| First control to verify | Validate and constrain upstream responses. |

[![API10:2023 Unsafe Consumption of APIs: Attack entry, Security failure, Impact, Stop/control](/assets/compliance/owasp-api-unsafe-consumption-of-apis-en-v2.webp)](/assets/compliance/owasp-api-unsafe-consumption-of-apis-en-v2.webp)

**API10:2023 Unsafe Consumption of APIs**

An external API remains a trust boundary.

- **Attack entry** — An upstream API returns malicious data.
- **Security failure** — The application overtrusts upstream behavior.
- **Impact** — Bad data triggers unsafe downstream action.
- **Stop/control** — Validate and constrain responses.

The diagram contrasts the unsafe route with the control that interrupts it. Select the image to inspect it at full size.

### Why it matters

A compromised or unreliable provider can inject bad data, trigger unsafe actions, or degrade a dependent service.

### Risk-reduction focus

- Validate and constrain upstream responses.
- Use timeouts, authentication, and least privilege for integrations.
- Plan for provider failure and monitor dependency health.

**Go code example for a web application using Fiber v3**

```go
// Vulnerable pattern: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// Fixed pattern: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }
```

### Compliance Readiness Self-Assessment

Select items your organization has completed to evaluate your readiness score.

0%

API1:2023 - Validate Object Level Authorization (BOLA) on every user data request
          
          
            
            API2:2023 - Enforce strong authentication across all public and internal API endpoints
          
          
            
            API3:2023 - Restrict exposed object properties to prevent mass assignment and data exposure
          
          
            
            API4:2023 - Apply rate limits, request payload size limits, and resource quotas
          
          
            
            API5:2023 - Validate Function Level Authorization (BFLA) for admin and privileged actions
          
          
            
            API6:2023 - Protect high-value business flows against automated abuse and bot traffic
          
          
            
            API7:2023 - Sanitize user-supplied URLs to prevent Server-Side Request Forgery (SSRF)
          
          
            
            API8:2023 - Harden API gateway configurations and mask detailed internal stack traces
          
          
            
            API9:2023 - Maintain an updated inventory of API versions and decommission stale endpoints
          
          
            
            API10:2023 - Validate and sanitize data received from third-party API services

Assessment Status

Check items above to view assessment result.

[Request Pentest Quote](/en/#contact)

## Related Compliance Frameworks and Security Standards

- [
                OWASP Top 10:2025 for web applications
                
              ](/en/compliance/owasp-top-10/web/)
- [
                Thai SEC penetration testing requirements
                
              ](/en/compliance/sec/)
- [
                NDID member penetration testing requirements
                
              ](/en/compliance/ndid/)
- [
                PCI DSS v4.0.1: VA, ASV Scan, Pentest, Segmentation
                
              ](/en/compliance/pci-dss/)

## Official OWASP reference

[Open the official OWASP edition ](https://owasp.org/API-Security/editions/2023/en/0x00-header/)

Open full-size image to zoom

## Need a pentest that satisfies these requirements?

Tell us about your systems and the requirements you must meet. The STH team will assess the approach and prepare a quotation.

[Request a Pentest quote](/en/#contact)

Last updated 16 October 2026