Introducing Test Editor: Your playground for writing custom API security tests

Six months ago, we began our journey with security testing. Since then, we have worked with hundreds of security teams across the world. Our focus has been on automating the testing of APIs to make it as easy as possible for security teams to test them before each release. We covered hundreds of test cases and automated them from end to end, trying to cover all possible scenarios. However, we encountered a massive hurdle in doing so. We realized that every developer has a unique way of writing APIs, and the problem becomes even more complicated with multiple developers contributing to code at a massive speed. For example, for one API, the error status code may be 200 OK, for another, it may be 4xx, and for a third one, it could be 200 OK with a status of "error". Finally, we came to the following conclusion:

Every API is unique. Your API testing should be too.

This changed the way we thought about testing at Akto. It's not easy to cover all test cases with all possible logics for your unique APIs. We realized the need for personalized and scalable API security testing.

Today, we are going beyond automated testing with Akto’s new test editor.

Introducing World’s first personalized security testing

Security teams often find themselves performing manual grunt work before every release. Traditional API security testing products are becoming increasingly restrictive for three reasons.

Firstly, these products only cover a fraction of critical vulnerability tests. As more new vulnerabilities are found, it becomes harder for users to find tests for new vulnerabilities in these traditional tools. Secondly, users have no ability to customize tests based on their business requirements. They manually test for critical and business logic vulnerabilities that traditional tools do not cover. This painful process slows down users and negatively impacts the complete and deep security of the application. Thirdly, users want to understand how their APIs are being tested. Today's testing tools lack visibility completely.

Akto's test editor is the world's first personalized API security testing tool. It is a simple, fast and scalable way to test APIs for security vulnerabilities. It allows user to write easy YAML templates in under 10 mins, test them on sample APIs and add to their API Security test library for continuous testing. Test Editor supports tests for both JSON and graphQL APIs. It comes with built in 100 templates for users to play around with and edit as per business need. The best part is, since you already have your API inventory in Akto, you can automate all your custom tests on all your APIs after writing them in the test editor.

We chose YAML as the test language because it is the easiest language for security teams to write tests in.

Our beta customers have been able to write 10 or more custom tests for their unique API behaviors in just a few hours, compared to the weeks it would take for each test previously. Here is an example of a YAML template written in Akto.

id: ADD_USER_ID
info:
  name: "IDOR by adding user id in query params"
  description: "Attacker can access resources of any user by adding user_id in URL."
  details: >
    "The endpoint appears to be vulnerable to broken object level authorization attack. The original request was replayed by adding other user's user id in query params.
    The server responded with 2XX success codes and less than <b>{{percentageMatch}}%</b> of the response body matched with original response body. <br>"
    "<b>Background:</b> Object level authorization is an access control mechanism that is usually implemented at the code level to validate that one user can only access objects that they should have access to."
  impact: "Unauthorized access can result in data disclosure to unauthorized parties, data loss, or data manipulation. Unauthorized access to objects can also lead to full account takeover."
  category:
    name: BOLA
    shortName: BOLA
    displayName: Broken Object Level Authorization (BOLA)
  subCategory: ADD_USER_ID
  severity: HIGH
  tags:
    - Business logic
    - OWASP top 10
    - HackerOne top 10
  references:
    - "https://www.akto.io/blog/bola-exploitation-using-unauthorized-uuid-on-api-endpoint"
    - "https://www.akto.io/blog/what-is-broken-object-level-authorization-bola"
    - "https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa1-broken-object-level-authorization.md"
    - "https://cwe.mitre.org/data/definitions/284.html"
    - "https://cwe.mitre.org/data/definitions/285.html"
    - "https://cwe.mitre.org/data/definitions/639.html"
auth:
  authenticated: true
api_selection_filters:
  response_code:
    gte: 200
    lt: 300
  param_context:
    param: user|customer
    extract: user_context
execute:
  type: single
  requests:
    - req:
        - add_query_param:
            user_context.key: ${user_context.value}