Introducing Escape rules – Rules that adapt for you

Introducing Escape rules - Rules that adapt for you

Today, we’re launching customization improvements to Escape’s automated testing capabilities. With Escape Rules, you can now write custom security tests that do not require any maintenance and adapt to each newly discovered API and each new version of your existing APIs.

What is an Escape Rule?

Escape Rule is a custom security test that can be created to address unique security concerns or scenarios relevant to your particular organization or application.

It is a YAML file where you need to define the following blocks:

Alerting is used to define the alert format and its severity.
Detectors are used to detect if an alert must be raised by inspecting queries.
Transformations are used to mutate the requests (optional).
Mutators are used inside the transformations.
Seeders are used to seed the scan with requests (optional).

You can check our documentation on how to set all parts up.

What makes Escape Rules different?

Zero maintenance

Escape rules adapt to the evolution of your existing APIs and to your new APIs without the need to maintain them. This includes adapting to database fixtures in the development environment.

You can use Escape Rules with both – GraphQL and REST APIs.

💡

You might be asking yourself – how are Escape Rules different than Nuclei?

One of the core pain points in custom test implementation with Nuclei is the maintenance of each test to follow along the attack surface changes, whether they are pure API specification changes or new APIs that extend your organization’s attack surface.

With Escape rules, you build generic API security tests, and Escape adapts them to each newly discovered API and each new version of your existing APIs.

Easy to write

Escape rules are based on the YAML syntax. They are designed to be easy to write by security engineers, developers and site reliability engineers.

💡

How are Escape Rules different from BChecks?

While BChecks and Escape custom tests are pretty similar on the surface, BChecks uses a more verbose language, less structured like the YAML operators (detectors/transformations) that Escape uses.

The biggest difference is also in the feedback-driven exploration engine and the scalar inference system that is built into Escape, helping you cover all the routes with confidence and abstractions of data manipulated, and easily available through custom tests.

You can capitalize on your pentests

Escape rules are powerful. Most of what an API pentest or a bug bounty program can find can be quickly implemented as an Escape rule for easy detection at scale, including the detection of business logic flaws.

Fast

Scanning an API with Escape rules takes minutes using the Escape platform.

Collaborative

At Escape we value open collaboration (just check all our open-source projects). If you're like us, consider sharing your templates with others to help them in running custom API security tests.

How can you contribute?

We've created a dedicated GitHub repository. We'll send Escape's swag to the top contributors each month and celebrate them in our community! Don't forget to join!

Usable in all environments

Escape rules can be run in production, preproduction, development environments as well as directly in the CI/CD to shift security left.

Our upcoming workshop

New to custom security tests and don't understand why you need to write them?

Join us for our upcoming workshop and gain the insights you need to start writing custom security tests for your APIs. Our experts will guide you through advanced techniques and offer practical insights to improve your security protocols.

You'll learn:

The importance of custom security tests and how to write them
Setting up rules for various API vulnerabilities
Creating rules based on bug bounty or pentesting reports
Fine-tuning Escape rules to catch issues specific to your APIs
Ensuring your rules adapt to each API update and newly discovered APIs

What kind of tests can you build?

Let's say an order processing feature has accepted an unreasonable amount. You might want to check that! Here is an example of a test you can build:

alert:
  name: An order processing feature has accepted an unreasonable amount
  context: You might wanna check that.
  severity: HIGH
detect:
  - if: response.status_code
    is: 200
transform:
  mutate:
    - key: request.object
      mutate:
        value: "65535"
      select:
        name:
          is: quantity
        type:
          is: amount
  trigger:
    - if: request.object
      name:
        is: quantity
      type:
        is: amount
    - if: schema.path_ref
      contains: order

Need more help and inspiration to get started? Join our upcoming workshop.

How can you set custom rules up in Escape?

Go to the tab "Custom Rules"
Click on "New" and create a new rule! It's that easy.

You can activate or deactivate your test and set it up to run on the specific label(s).

Want to give it a try?

If you're not using Escape (yet), you can give it a try during your free trial period:

*** This is a Security Bloggers Network syndicated blog from Escape - The API Security Blog authored by Alexandra Charikova. Read the original post at: https://escape.tech/blog/introducing-escape-rules/