APIsec Documentation

Table of Contents

  1. Introduction to APIsec
  2. Basic Initial Procedures
  3. Creating Projects
  4. Activating Security Coverage
  5. Running Scans
  6. Managing a Project: A Detailed Look at All Options
  7. Writing Playbook for APISecTM: An In-Depth Look
  8. Frequently Asked Questions (FAQs)

1. Introduction to APISec

Welcome to APIsec! The team is excited that you are here to learn more about us and APIsec! If you have already purchased APIsec services, the documentation below will certainly of be of help to you. In any case, we are confident that by reading this guide, you’ll gain a greater insight into what the APIsec user experience is like. Let’s continue!

1.1 The Development Landscape Today

In the world of today, web technologies are as important as ever. Nearly every aspect of the modern world relies on communications networks which see no reason in receding, and increasingly, the language which all of us use to interface with each other through the wires belongs to the realm of RESTful APIs. REST, or REpresentational State Transfer, is a computer communications design philosophy that has proven to be so popular and practical that companies and individuals from everywhere continue to use it for more applications than anyone could ever conceive.

Just as the internet is commonly understood to have opened the door mass amounts of information to become accessible to anyone, the widespread availability of REST APIs in the present day has made the exchange of immensely powerful information services which no individual author could ever create accessible to anyone. Ever notice that in Uber’s ridesharing app that their live map is noted as being powered by Google Maps in the bottom corner? Have you seen bundles of websites that all feature recognizable plugins and embeds from Facebook, Twitter, YouTube, and the like? These examples are but a few of how REST APIs are used to efficiently create a user experience that is more than the sum of its parts which would not otherwise be possible.

In essence, REST APIs are important to contemporary web development because it is the simple, common medium of abstraction through which we can build on each other’s works.

However, with great interoperability and intercommunication comes increased security risks and dangers of reliance. When the security and continued operation of your product depends on REST API services of others, and yet even more possibly depend on your services through your own REST API, the age-old perils of software development are ever as important. The creation, addition, and maintenance of software should always be vetted through testing. Testing can be an intensely laborious process, and even if done efficiently, faults and errors can still slip past every human mind. That is part of the reason why automated testing software has been created whenever the need for one has been perceived, and we here at APIsec see that need for verification of REST APIs.

1.2. What APIsec Can Do

APIsec delivers the only enterprise-class API security platform that provides instant and continuous API security coverage and compliance to protect applications from attacks targeting the API layer. The platform specializes in automatically identifying privilege escalation vulnerabilities (RBAC) and unauthorized access to resources (ABAC) – which are impossible to find otherwise. Such vulnerabilities have contributed to the most prominent API attacks (including Google+, Facebook and T-Mobile) and could cost companies extremely high fines for breaching GDPR and other guidelines.

1.3. Understanding This Guide

In this documentation, you will find extensive information detailing the use of APIsec from start-to-finish written. We aim for these words to act as a guide of sorts, a handbook for APIsec. Visual aids are provided as often as deemed important.

If you are ever at a loss as to what to do next, it may help to know that the chapters in this guide are likewise arranged in a roughly start-to- finish manner:

  1. Introduction to APIsec: What is APIsec all about? What can we help people with? Do we suit your needs?
  2. Basic Initial Procedures and Information: Now that you’ve chosen us, allow us to give you a tour of the place. Learn the fundamentals of how to use APIsec.
  3. Register Your Application: Register your application by simply providing an OpenAPI Spec (Swagger file) that can be used for introspecting your APIs.
  4. Creating Security Coverage for a Registered Application: The platform will automatically generate security tests spanning critical categories like Unsecured Endpoints, RBAC, ABAC, SQL Injection, DDoS, and many others. You can activate all categories at once or simply generate security tests one category at a time.
  5. Running Security Scans on a Project: Now that we’re ready to begin together, it’s time to get down to business and let APIsec help you in testing your REST API.
  6. Managing a Project – A Detailed Look at All Options: APISecTM offers much more utility than a generalized, one- size-fits-all approach ever can. Discover how you can customize your testing procedures, adjust environment configurations, and view test results.
  7. Writing Playbooks for APIsec – An In-Depth Look: Know what to look out for with your REST API, but do not want to expend impractical amounts of effort in doing so? Write custom tests.
  8. Frequently Asked Questions (FAQs)

It is important to note at this time that APIsec is undergoing a significant rate of revision and refinement as we forge on to bring about the best version of the product that we can. Therefore, some elements of this guide may fall out of date from time to time, but the fundamental messages should almost always stand. We hope to alleviate any confusion that may arise from this, and are happy to help if you directly contact us.

1.4. Other Related Resources

APIsec also offers two other resources to supplement your usage of APIsec: FX CLI (Command Line Interface), and FX API, our own REST API for APIsec. Take a look at the following links for more information.

FX CLI: https://github.com/fxlabsinc/F...

FX API: https://cloud.fxlabs.io/swagge...

These links are also visible at the bottom of the window in any APIsec page.

2. Basic Initial Procedures and Information

2.1. Logging In

In order to log into APIsec, you can go directly to the login page by typing “cloud.fxlabs.io” directly into the address bar of your web browser. Enter your email address and password you specified when you registered for APIsec.

2.2. The User Home Page

After logging in, you will be greeted by your own User Home Page. There are four primary areas of interest: the API Projects Menu, Services Menu, User Options Menu and Task Menu.

2.2.1. API Projects Menu

The API Projects Menu will display any API projects you may already have registered, and a button (+ New API Project) to register more. You can click on a project to activate security coverage, run security scans, view vulnerabilities and historical analytics and configure API environments and scan profiles.

2.2.2. Services Menu

The Services Menu is a central location for you to access key services like storing credentials and key/value pairs securely in the Vault, provisioning Scanners across private and public clouds, and accessing reusable datasets in the Marketplace.

2.2.3. User Options Menu (Top Right Dropdown)

The User Options Menu is a drop-down that can be seen in the upper right hand corner when you click on your username.

Here, you will be able to find a short list of options that you will find valuable in adding to or editing when managing your projects.

2.2.4. The Task Menu

The Task Menu (found in the lower right corner of your browser window) displays any recent changes in the settings of your Project as well as any Active Jobs that may be running in a project. Clicking on the the blue text of each “task” will direct you to the page where any project changes were made, or to view the details of an active job (whichever may be the case depending on the item).

This menu is present on nearly every page in APIsec. It can also be minimized if desired.

3. Creating a Project

In order to get instant security coverage for your APIs, you first need to create a project to activate security categories and run the scan profiles. On the User Home Page, click + New API Project to begin.

Creating a project involves two main steps:

4. Activating Security Coverage

Once a project is registered, APISecTM can automatically create security tests based on the API endpoints discovered in the OpenAPI Spec provided. To activate security coverage, navigate to the AutoCoverage page. You can activate all security categories at once or simply activate one at a time. The page will indicate the number of API endpoints discovered and the predicted number of unique security validations that can be created accordingly.

The security categories are tagged with the respective PCI 6.5 and OWASP standards that they are associated with.

The platform specializes in automatically identifying privilege escalation vulnerabilities (RBAC) and unauthorized access to resources (ABAC) – which are impossible to find otherwise. Such vulnerabilities have contributed to the most prominent API attacks (including Google+ and Facebook) and could cost companies extremely high fines for breaching GDPR and other regulatory guidelines.

The security categories are constantly updated - but include Unsecured Endpoints, Authentication Weakness, Role-Based Access Controls (RBAC), Attribute-Based Access Controls (ABAC), SQL Injection, Distributed Denial of Service, and many others.

4.1 Activating Security Categories

To activate individual security categories, you can simply select one of the categories, uncheck the box labelled “Inactive” and finally click on Save Configuration.

Optionally, you can edit the “Assertions” section with your own Status Codes (e.g. for unauthorized requests, your application may return a web page with embedded errors. So you can add @Response.errors == true).

You can also add “Skip Paths” for endpoints you would like to exclude from the security scan.

5. Running Security Scans

Once a project has been registered, running security scans and viewing their results can be done with ease. It is also possible to configure scan profiles and API environments.

5.1. Starting a Security Scan - Quick Guide

APIsec offers a significant amount of control over your security scan, scan profile configuration, and project settings in general. However, it is also possible to quickly run a security scan with minimal tinkering involved on a newly created project. When a new project is registered, a default profile config available as seen below:

In order to quickly scan a test on demand, click the Scan Button.

Clicking the scan button should lead to a popup dialog similar to the one below which presents a few last-minute configuration options. Should you be interested in using it, Categories provide a way to quickly include or exclude security categories in your scan. Scanner allows you to select the scanner that will be used to execute the security scans. Either way, click Scan to continue once you are ready.

5.2. Viewing Security Scan Results

After running a security scan, you will be redirected to the screen shown below. Near the top are roughly a dozen general statistics, and below those is a list of every individual test suite with analytics and wire log files that are viewable when the blue icons on the right hand side of each suite is selected.

Security vulnerabilities are highlighted allowing users to quickly identify security issues with detailed wire logging that highlights all failed assertions.

By navigating back to the project home page and then clicking on Vulnerabilities, you can view a list of open vulnerabilities across all security scans executed within this project.

The vulnerability menu provides a wide range of options for vulnerability management – including sample code snippets to fix a discovered vulnerability as well as the ability to mark a vulnerability as a false positive.

6. Managing a Project: A Detailed Look at All Options

6.1. Scan Profile Configuration: Editing a Config or Adding a New One

To create a new Scan Profile Configuration, click + New Profile. To edit the settings of an existing profile config, click the Name of the profile config instead. You can have as many profile configs as you like.

The process for setup or editing of a profile config is very similar; the exact same dialog shows up for both. The only difference is that the latter will already have fields that you’ve completed in the past still filled out. The example slides below shows such a case (the editing of an existing profile config).

Step 1: Profile Details, presents five criterion:

To move on to other profile config settings, click Next in the lower right hand corner as needed.

Step 2: Reports similarly offers the ability for you to link this profile config and any of its potential scan profiles to an email or Slack for the purpose of sending test profiles statuses and results. These is also optional, but if either are wanted, fill out the appropriate fields.

Step 3: Auto Bug Management presents you with the option to set up automatic bug filing and closing with an issue tracker of your choice (GitHub Issues or Jira) every time a vulnerability is detected or closed as part of security scanning.

6.2. Security Scans History

In order to view the security scan profile history, click the History link highlighted in blue.

Doing so will redirect you to the overview page below. It is possible to click on the activity numbers on the right highlighted in blue for further details about an individual test profile.

6.3. The Environments Page

The Environments Page of a project allows you to create or edit existing Environment Configurations, arrangements that allow you to run security scan profiles in different API environments when set accordingly in a Profile Configuration.

6.3.1. Environment Configuration: Editing an Environment or Adding a New One

To create a new Environment Configuration, click + New Environment. To edit an existing one, click the blue name of one in the list below.

Creating or editing an environment configuration is a very process to a similar step that you may have done when setting up your project in the first place. Simply choose a recognizable Env Name, specify
the Base URL that your API can be accessed through, and supply the appropriate Authentication Credentials if any are needed to make API calls.

APIsec supports all major authentication protocols – including Basic, OAuth and Token-based authentication.

6.4. The Playbooks Page

The Playbooks Page is a location for you to view the yaml files of each individual security test automatically generated in your project. It is also possible for you to manually write new playbooks of your own here, and when pushing your changes to your project, it is possible for you to preserve previous versions of testing (yaml) files stored in your GitHub repository instead of overwriting them.

6.4.1. Playbook Config Editing

Playbooks in APIsec are written in yaml. In order to view the yaml files of a particular test through APIsec on the Playbooks Page, simply click on the desired test in the text shown in bold blue.

The file should show up in an interface similar to the one below, and it is capable of being edited here directly. You may also notice numerous options scattered across the screen:

6.4.2. Adding a New Custom Playbook

In order to create a new Playbook, click + New Playbook.

The window below showing a skeleton playbook will open up. In order to learn more about how to write tests for APIsec, see Chapter 7. Writing Playbooks for APIsec – An In-Depth Look.

7. Writing Playbook for APISecTM: An In-Depth Look

7.1. Getting Started

APIsec will automatically generate security tests for all critical API security categories. There is no need to create any additional security tests – but if needed, you can follow this chapter to learn about creating playbooks that support API chaining and end-to-end API flows.

Please refer to this GitHub project for detailed examples: https: //github.com/intesar/Fx-Test-Data

7.1.1. Sample Playbook

endpoint: /users


type: SUITE

- data_init1

auth: default

method: POST

- 'Content-Type: application/json' 
- 'Accept: application/json'

- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
# optional name
- id: 1
body: '{"name": "", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": " ", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
# optional company
- id: 1
body: '{"name": "", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": " ", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"} 
# optional jobTitle
- id: 1
body: '{"name": "", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": " ", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- "@StatusCode == 200"
- "@Response.errors == false"
- "@Response.data.name == @Request.name"
- "@Response.data.username ==IgnoreCase @Request.username" 
- "@Response.data.email == @Request.email"
- "@Response.data.company == @Request.company"
- "@Response.data.jobTitle == @Request.jobTitle"
- user_delete

- V1
- DEV3

logger: DEBUG 
repeatOnFailure: 0 
repeat: 0 
repeatDelay: 3000
timeoutSeconds: 5 
initExec: Request 
cleanupExec: Request Explanation of Playbooks
# Note - Order is not important.
# endpoint - represents the API Endpoint. The base-url value comes from the Fxfile 
endpoint: /users


# Suite type - SUITE or ABSTRACT
# ABSTRACT - is not directly excuted but can be injected into other suites 'init' & 'cleanup' sections. 
type: SUITE

- data_init1 
- data_init2

# auth - refers to auth defined in the Fxfile 
# If not defined defaults to 'Default' auth.
# If auth is set to 'NONE' then no auth is used when executing requests 
auth: default

# method - represents the API http method (GET, PUT, POST, DELETE etc) 
method: POST

# headers - represents request headers - when missing these two headers are auto set('Content-Type: application-json', 'Accept:application/json')
- 'Content-Type: application/json'
- 'Accept: application/json'

# testCases - group one or more api requests.
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"} 
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
# optional name
- id: 1
body: '{"name": "", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"} 
- id: 1
body: '{"name": " ", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"} 
# optional company
- id: 1
body: '{"name": "", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": " ", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"} 
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
# optional jobTitle
- id: 1
body: '{"name": "", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}
- id: 1
body: '{"name": " ", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"} 
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"} 
- id: 1
body: '{"name": "fn1 ln", "username": "u1", "email": "e1@fx.local", "company": "fx", "jobTitle": "Engineer"}

# assertions - One or more assertions.
# All needs to be true for the test-case to pass.
- "@StatusCode == 200"
- "@Response.errors == false"
- "@Response.data.name == @Request.name"
- "@Response.data.username ==IgnoreCase @Request.username" 
- "@Response.data.email == @Request.email"
- "@Response.data.company == @Request.company"
- "@Response.data.jobTitle == @Request.jobTitle"

# cleanup - excutes one or more abstract suites per request or per suite. 
- user_delete
- org_delete

# tags - jobs can filter test-suites based on the tags. 
- V1
- DEV3

# Optional policies
logger: DEBUG # DEBUG | ERROR 
repeatOnFailure: 0
repeat: 0
repeatDelay: 3000
timeoutSeconds: 5
initExec: Request # Request | Suite 
cleanupExec: Request # Request | Suite

7.2. Entity - Keywords

## 1. Entity - Keywords 
- @Request
- @StatusCode
- @ResponseHeaders
- @Response
- @ResponseTime 
- @ResponseSize

7.2.1. Entity Injection Examples in Assertions

## Entity Injection examples in assertions ## 
# - @NULL
@Request.name == @NULL
# - @EMPTY 
@Request.name == @EMPTY
# - @ResponseTime (milliseconds) 
@ResponseTime <= 1000
# - @ResponseSize (bytes) 
@ResponseSize <= 1024

7.3. Data-Injection - Keywords

## 2. Data-Injection - Keywords 
- @Random
- @RandomAlphabetic
- @RandomAlphanumeric
- @RandomNumeric 
- @Date
- @RandomUUID

7.3.1. Data-Injection Examples

## Data-Injection examples
# Injects random 6 chars.
{"name": "fn1 ln", "username": "{{@Random}}"}

# Injects random 4 chars as prefix.
{"name": "fn1 ln", "email": "{{@Random | 4}}@fx.local"}

# Injects random 6 alphabet chars.
{"name": "fn1 ln", "email": "{{@RandomAlphabetic}}@fx.local"}

# Injects random 24 alphabet chars.
{"name": "fn1 ln", "email": "{{@RandomAlphabetic | 24}}@fx.local"}

# Injects random 6 numeric chars.
{"name": "fn1 ln", "email": "{{@RandomAlphanumeric}}@fx.local"}

# Injects random 8 numeric chars.
{"name": "fn1 ln", "email": "{{@RandomAlphanumeric | 8}}@fx.local"}

# Injects date.
{"name": "fn1 ln", "dob": "{{@Date}}"}

# Inject date in the format
{"name": "fn1 ln", "dob": "{{@Date | yyMMddHHmmssZ}}"}

# Injects UUID.
{"name": "fn1 ln", "id": "{{@RandomUUID}}"}

7.3.2. Data Injection Examples Across Suites

## Data Injection examples across suites support 

# In assertions
# Org_Create_Init - refers to the Init script item.
# Org_Create_Init_Request - refers to the Request json of the init script. 
# Org_Create_Init_Request.name - JsonPath of name attribute on the request. 
# @Response - refers to the Suite test-case response.
# @Response.org.name - refers to the JsonPath of response.
- "@Org_Create_Init_Request.name == @Response.org.name"

# Injection in endpoint attribute of the Suite.
# With transformations
# Org_Create_Init - refers to the Init script item.
# Org_Create_Init_Headers - refers to the response Headers of init script. 
# Org_Create_Init_Headers.location - refers to the location attribute in Headers.
# substringAfterLast / - extracts the value after the last '/' in location attribute.
endpoint: /hotels/{{@Org_Create_Init_Headers.location | substringAfterLast /}}

7.4. Comparison - Keywords

## 3. Comparison - Keywords 
- ==
- ==IgnoreCase
- !=
- >
- < 
- >=
- <=
- =~
- !=~
- startsWith
- startsWithIgnoreCase 
- endsWith
- endsWithIgnoreCase

7.4.1. Comparison Keywords Examples in Assertions

## Comparison Keywords examples in assertions ## 
# == (equals)
"@StatusCode == 200"
"@Response.data.name == @Request.name"
# ==IgnoreCase (equals ignore case) 
"@Response.data.email ==IgnoreCase @Request.email"
# != (not equals)
"@Response.data.password != @Request.password" 
"@StatusCode != 500"
# > (greater than) 
"@Response.age > 21"
# < (less than)
"@Response.age < 21" # >= (greater than or equal) 
"@Response.age >= 21"
# <= (less than or equal) 
"@Response.age <= 21"
# =~ (regex)
# Tells whether or not this string matches the given
# Regex doc - https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#sum 
"@Request.email =~ *@gmail.com"
# !=~ (negate of regex) 
"@Request.email !=~ *@gmail.com"
# startsWith (starts with) 
"@Request.email startsWith Bob"
# startsWithIgnoreCase (starts with ignore case) 
"@Request.email startsWithIgnoreCase Bob"
# endsWith (ends with) 
"@Request.email endsWith gmail.com"
# endsWithIgnoreCase (ends with ignore case)
"@Request.email endsWith Gmail.com"

7.5. Transformation - Keywords

## 4. Transformation - Keywords 
- trim
- trimToNull
- trimToEmpty
- truncate
- strip
- indexOf
- indexOfIgnoreCase 
- lastIndexOf
- left
- right
- substringBefore
- substringAfter
- substringBeforeLast
- substringAfterLast
- substringBetween
- removeStart
- removeStartIgnoreCase 
- removeEnd
- removeEndIgnoreCase - remove
- removeIgnoreCase
- removeAll
- removeFirst
- removePattern - chomp
- chop
- repeat
- rightPad
- leftPad
- upperCase
- lowerCase
- capitalize
- uncapitalize
- reverse

7.5.1. Transformation Support Examples

## Transformation support examples ##

# - trim - removes leading and trailing whitespace 
{{@Request.username | trim}}

# - trimToNull - removes leading and trailing whitespace and may return null 
{{@Request.username | trimToNull}}

# - trimToEmpty - removes leading and trailing whitespace and may return ''
{{@Request.username | trimToEmpty}}

# - truncate - Truncates '1234567890' to '12345' 
{{@Request.username | truncate 5}}

# - strip
# - indexOf - Returns the index within seq of the first occurrence 
{{@Request.email | indexOf @}}

# - indexOfIgnoreCase
# - lastIndexOf - Returns the index within seq of the last occurrence 
{{@Request.email | lastIndexOf @}}

# - left - Gets the leftmost len characters of a String. 
{{@Request.email | left 5}}

# - right - Gets the rightmost len characters of a String. 
{{@Request.email | right 5}}

# - substringBefore - Gets the substring before the first occurrence of a separator
{{@Request.email | substringBefore @}}

# - substringAfter - Gets the substring after the first occurrence of a separator
{{@Request.email | substringBefore @}} 
# - substringBeforeLast
# - substringAfterLast
# - substringBetween
# - removeStart - Removes a substring only if it is at the beginning of a source string 
# - removeStartIgnoreCase
# - removeEnd
# - removeEndIgnoreCase
# - remove - Removes all occurrences of a substring from within the source string 
{{@Request.username | remove @}}
# - removeIgnoreCase 
# - removeAll
# - removeFirst
# - removePattern
# - chomp
# - chop
# - repeat - Repeat a String repeat times to form a new String 
{{@Request.username | repeat 2}}
# - rightPad - Right pad a String with spaces 
{{@Request.username | rightPad 10}}
# - leftPad - Left pad a String with spaces 
{{@Request.username | leftPad 10}}
# - upperCase - Converts a String to upper case 
{{@Request.username | upperCase}}
# - lowerCase - Converts a String to lower case 
{{@Request.username | lowerCase}}
# - capitalize
# - uncapitalize
# - reverse - Reverses a String 
{{@Request.username | reverse}}

7.6. JsonPath Supported Entities

## 5. JsonPath supported entities 
- @Request
- @Response

7.6.1. JsonPath Examples in Assertions

## JsonPath examples in assertions ## 
"@Response.data.name == @Request.name" 
"@Response.data.email == @Request.email"

8. Frequently Asked Questions (FAQs)

Coming soon.