# OWASP Top Ten API 2023 and GraphQL: A Deep Dive with Concrete Examples

*This is a guest post written by Antoine Carossio, ex-Apple, cofounder & CTO at Escape – GraphQL Security.*

The [OWASP TOP 10 API 2023 RC](https://github.com/OWASP/API-Security/tree/master/2023/en/src) has been released. The first thing interesting to notice is that most of the Top 10 Vulnerabilities descriptions provided by the OWASP Foundation now include GraphQL examples, which proves once again the rise of this technology among APIs.

It's time to dive into the changes and what they mean for developers working with GraphQL APIs. Throughout this article, we are going to explore these risks in more detail, focusing on a **concrete example: the GraphQL API of a simple Social Network**, inspired by the official RC.

## API01: Broken Object Level Authorization (BOLA)

Broken Object Level Authorization, formerly [Insecure Direct Object Reference (IDOR)](https://docs.escape.tech/vulnerabilities/access_control/idor), remains the most significant risk for APIs, as it did in 2019. Developers should focus on proper authentication, authorization, and session management. GraphQL developers must be cautious about access control and potential vulnerabilities when implementing their GraphQL API.

**GraphQL Example:**

On our social network, consider a GraphQL query to fetch a user's profile data:

query {
  user(id: 12) {
    id
    name
    email
    address
    recentLocation
  }
}

Since a user ID can be queried without any further permission checks, an attacker could iterate over the `id` (`13`, `14`, `42`, `128`…) parameter to access any other user's data.

**Good practice:**

Implement proper authorization checks in your GraphQL resolvers to ensure that users can only access data they're authorized to view.

## API02: Broken Authentication

While still focused on authentication, the Top Ten 2023 drops the word "[User](https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa2-broken-user-authentication.md)" and broadens its scope to include microservices and service principals. This change highlights the importance of testing logic of authentication mechanisms and looking for ways to abuse or bypass them.

**GraphQL Example:**

To obtain its authentication token, the user must send the credential request in the `login` mutation. This mutation is rate-limted at 2 attempts per minutes.

mutation {
  login(username: "johndoe", password: "test1") {
    token
  }
}

Using GraphQL, you can easily use aliasing or batching to send multiple queries in one single HTTP request and get around the limitations to perform a bruteforce attack:

mutation {
  attempt1: login(username: "johndoe", password: "test1") {
    token
  }
  attempt2: login(username: "johndoe", password: "test2") {
    token
  }
  attempt3: login(username: "johndoe", password: "test3") {
    token
  }
  attempt4: login(username: "johndoe", password: "test4") {
    token
  }
  ...
}

**Good practice:**

Secure your GraphQL authentication mutations by implementing batching and aliasing rate limits.

## API03: Broken Object Property Level Authorization (BOPLA)

BOPLA is a new addition that combines the 2019 list's [Excess Data Exposure](https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa3-excessive-data-exposure.md) and [Mass Assignment](https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa6-mass-assignment.md). This change reflects the growing trend of frameworks (de)serializing objects without proper checks. GraphQL developers should be aware of this risk and test for both excessive data exposure and mass assignment vulnerabilities.

**GraphQL Example:**

Our social network exposes a mutation for reporting another user's profile:

mutation {
  reportUser(id: "123", reason: "Fake profile") {
    status
    message
    reportedUser {
      id
      fullName
      recentLocation
      }
  }
}

An attacker could exploit a BOPLA vulnerability to access the to sensitive properties of the reported user (such as its `recentLocation`), that are not supposed to be accessed by other users.

**Mitigation:**

Implement field-level authorization checks in your GraphQL schema and resolvers. This can be done using custom middlewares or GraphQL directives to enforce access control on specific fields.

## API04: Unrestricted Resource Consumption

The title change from [Lack of Resources & Rate Limiting](https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md) highlights the fact that with improper monitoring, malicious activity passes unnoticed.

Developers should be aware of these new concerns and ensure they limit and monitor resource consumption in their APIs, especially when using GraphQL.

**GraphQL Example:**

Our social network allows users to request deeply nested data and consult in depth all the posts of all users that commented the post with the id `1337`:

query {
  post (id: 1337) {
    id
    title
    comments {
      id
      text
      user {
        id
        name
        posts {
          id
          title
          comments {
            ...
          }
        }
      }
    }
  }
}

This query leads to a potentially infinite cycle and can cause excessive resource consumption on the server.

**Mitigation:**

Limit query complexity and depth using tools like [GraphQL Armor](https://escape.tech/gaphql-armor). Implement rate limiting and proper monitoring to prevent abuse, especially on expensive operations.

## API05: Broken Function Level Authorization (BFLA)

BFLA remains in the middle of the list, with an added emphasis on the importance of proper logging and monitoring. It refers to a permission IDOR, whereby a regular user can carry out an administrator-level task. This is a critical reminder for developers to ensure they have proper logging mechanisms in place for their APIs.

**GraphQL Example:**

The social networks proposes a GraphQL mutation so that moderators can ban a user:

mutation {
  banUser(id: "123") {
    id
    success
  }
}

An attacker could exploit a BFLA vulnerability to ban other users whereas normally only a moderator can.

**Mitigation:**

Implement proper authorization checks in your GraphQL resolvers to ensure users can only perform actions they're authorized for.

## API06: Server Side Request Forgery (SSRF)

The addition of SSRF to the 2023 list highlights the growing concern about this vulnerability in APIs. Developers should be aware of this risk and test for SSRF vulnerabilities in their APIs.

**GraphQL Example:**

The social network allows users to prefill their profile info from another profile found on the Internet, and the API fetches this info directly from this remote URL based on user input:

query{
  fetchInfo(otherSocialUrl: "https://example.com/in/johndoe"){
    name
    surname
    title
  }
}

An attacker could exploit an SSRF vulnerability by replacing the URL parameter with its [own Request Catcher server or restricted resources](https://escape.tech/blog/pentest103/). When controlling the destination of a particular request made by the server, this is the basic framework for an SSRF vulnerability.

At Escape, this is the critical vulnerability we see the most often in the GraphQL applications of our customers.

Most of the time, the customer's API tries to fetch our Request Catcher server using internal private tokens that are normally used to connect to private internal resources.

**Mitigation:**

Validate and sanitize user input used in server-side requests. Implement network-level protections to prevent unauthorized access to internal resources.

## API07: Security Misconfiguration

Security Misconfiguration remains on the list, with added emphasis on API gateways and WAFs. Developers should ensure their servers are properly configured and consider the role of API gateways and WAFs in their security strategy.

**GraphQL Example:**

In GraphQL, one of the most common security configuration is to keep the `DEBUG` mode enabled in production, which can easily leads to the leak of stacktraces. For instance, in the following query we send a wrong payload:

query {
  user(id: "1.0") { //
    id
  }
}

and since the `DEBUG` mode is still on, the GraphQL servers discloses important info about the application in its response with a Stacktrace:

{
  "errors": [
    {
      "message": "String cannot represent non-integer value: 1.0",
      "locations": [
        {
          "line": 1,
          "column": 312
        }
      ],
      "extensions": {
        "code": "GRAPHQL_VALIDATION_FAILED",
        "exception": {
          "stacktrace": [
            "GraphQLError: String cannot represent non-integer value: 1.0",
            "    at GraphQLScalarType.parseLiteral (/var/www/app/node_modules/graphql/type/scalars.js:98:13)",
            "    at isValidValueNode (/var/www/app/node_modules/graphql/validation/rules/ValuesOfCorrectTypeRule.js:154:30)",
            "    at Object.FloatValue (/var/www/app/node_modules/graphql/validation/rules/ValuesOfCorrectTypeRule.js:117:27)",
            "    at Object.enter (/var/www/app/node_modules/graphql/language/visitor.js:301:32)",
            "    at Object.enter (/var/www/app/node_modules/graphql/utilities/TypeInfo.js:391:27)",
            "    at visit (/var/www/app/node_modules/graphql/language/visitor.js:197:21)",
            "    at validate (/var/www/app/node_modules/graphql/validation/validate.js:91:24)",
            "    at validate (/var/www/app/node_modules/apollo-server-core/dist/requestPipeline.js:186:39)",
            "    at processGraphQLRequest (/var/www/app/node_modules/apollo-server-core/dist/requestPipeline.js:98:34)",
            "    at runMicrotasks (<anonymous>)"
          ]
        }
      }
    }
  ]
}

**Mitigation:**

Regularly review and update server configurations, security headers, environment variables, and CORS policies to maintain a secure API environment.

## API08: Lack of Protection from Automated Threats

This new addition replaces the 2019 "Injection" category and highlights the need to protect APIs from automated attacks. Developers should be aware of this risk and implement measures to prevent excessive automated access to their business-sensitive API endpoints.

**GraphQL Example:**

The **Social Network** offers Premium features, such as a "verified" badge. Additionally, it has a referral program where users can invite friends and earn credit for each friend who joins the app. This credit can be utilized to purchase Premium features.

A malicious individual manipulates this process by crafting a script that automates the sign-up procedure, with every new user contributing credit to the attacker's account. The attacker can then take advantage of free Premium benefits or sell the accounts with surplus credits.

**Mitigation:**

Implement rate limiting, user behavior analysis, and CAPTCHAs to protect your API from excessive automated access.

## API09: Improper Inventory Management

The change from "[Assets](https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa9-improper-assets-management.md)" to "Inventory" reinforces the importance of versioned endpoints and proper documentation. Developers should ensure they have a clear understanding of their API inventory and maintain thorough documentation.

**GraphQL Example:**

Although at Escape we don't trust security by obscurity, a DevSecOps decides to close introspection from the production environmnent (https://thesocialnetwork.com) to prevent users from discovering its GraphQL Schema, but he keeps it open on the public staging environmement (https://staging.thesocialnetwork.com) because it's a great feature for his frontend developers.

An attacker can easily find its staging environment that runs (almost) the same API and obtain the Introspection.

**Mitigation:**

Maintain a clear inventory of your different API versions, environments, and deprecated fields.

## API10: Unsafe Consumption of APIs

This new category replaces "[Insufficient Logging & Monitoring](https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xaa-insufficient-logging-monitoring.md)" and focuses on the risks associated with trusting third-party APIs. Developers should be cautious about blindly trusting data from external systems and ensure proper input validation and sanitization.

**GraphQL Example:**

The social network depends on a third-party service's API to enhance user-provided business addresses. When a user submits an address to the API, it is transmitted to the third-party service, and the returned information is subsequently saved in a locally accessible SQL-enabled database.

Malicious actors exploit the third-party service by storing an SQL injection payload related to a business they have created. They then target the susceptible API by supplying particular input that prompts it to retrieve their "malicious business" from the third-party service. As a result, the SQLi payload is executed by the database, causing data to be exfiltrated to a server under the attacker's control.

**Mitigation:**

Treat data from third-party APIs as untrusted input. Implement proper input validation, sanitization, and error handling to prevent security issues when consuming external APIs. You can easily check the reputation of third party APIs on [APIRank.dev](APIRank.dev).

## Conclusion

The OWASP TOP 10 API 2023 list brings some significant changes and new additions that reflect the evolving API security landscape. Developers working GraphQL APIs should familiarize themselves with these updates and take the necessary steps to ensure their APIs are secure and well-protected against these risks.