OWASP API Security Top 10 2023 and GraphQL

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

The OWASP API Security Top 10 2023 RC has been released. The first thing interesting is that most of the Top 10 Vulnerabilities descriptions provided by the OWASP Foundation now include GraphQL examples, which once again proves this technology’s rise among APIs.

It’s time to dive into the changes and what they mean for developers working with GraphQL APIs. Throughout this blog post, we will 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), 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 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” and broadens its scope to include microservices and service principals. This change highlights the importance of testing the 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-limited at two attempts per minute.

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 brute-force 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)

It is crucial to verify that a user has the authorization to access the specific fields of a GraphQL object they are attempting to reach via the API. BOPLA is a new addition that combines the 2019 list’s Excess Data Exposure and Mass Assignment. This change reflects the growing trend of frameworks (de)serializing objects without proper checks.

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 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 middleware or GraphQL directives to enforce access control on specific fields.

API04: Unrestricted Resource Consumption

The title change from Lack of Resources & Rate Limiting highlights that malicious activity passes unnoticed with improper monitoring.

Developers should know 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 on 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.

Good practice:

Limit query complexity and depth using tools like GraphQL 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, emphasizing the importance of proper logging and monitoring. It refers to a permission IDOR, whereby a regular user can perform an administrator-level task. This is a critical reminder for developers to ensure proper logging mechanisms for their APIs.

GraphQL example

The Social Network 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.

Good practice:
Implement proper authorization checks in your GraphQL resolvers to ensure users can only perform authorized actions.

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 know 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 Request Catcher server or restricted resources. When controlling the destination of a particular request the server makes, 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. The customer’s API often tries to fetch our Request Catcher server using private tokens normally used to connect to private internal resources.

Good practice:

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, emphasizing 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 configurations is to keep the DEBUG mode enabled in production, which can easily lead to the leak of stack traces. For instance, in the following query, we send a payload with an inconsistent type:

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

and since the DEBUG mode is still on, the GraphQL server 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 ()"
          ]
        }
      }
    }
  ]
}

Good practice:

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 know this risk and implement measures to prevent excessive automated access to their business-sensitive API endpoints.

GraphQL example

The Social Network offers Premium features like 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 use free Premium benefits or sell the accounts with surplus credits.

Good practice:

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

API09: Improper Inventory Management

The change from “Assets” to “Inventory” reinforces the importance of versioned endpoints and proper documentation. Developers should ensure they clearly understand 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 environment to prevent users from discovering its GraphQL Schema, but he keeps it open on the public staging environment 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.

Good practice:

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

API10: Unsafe Consumption of APIs

This new category replaces “Insufficient Logging & Monitoring” and focuses on the risks of 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 uses a third-party API to enhance user-provided business addresses. When a user submits an address to the API, it is transmitted to the third-party service. 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 its “malicious business” from the third-party service. As a result, the database executes the SQLi payload, causing data to be exfiltrated to a server under the attacker’s control.

Good practice:

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.

Conclusion

The OWASP API Security Top 10 2023 RC list brings significant changes and additions that reflect the evolving API security landscape. Developers working on 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.