Secure Your API.
With Metlo you can:
Metlo does this by scanning your API traffic using one of our connectors and then analyzing trace data.
There are three ways to get started with Metlo. Metlo Cloud, Metlo Self Hosted, and our Open Source product. We recommend Metlo Cloud for almost all users as it scales to 100s of millions of requests per month and all upgrades and migrations are managed for you.
You can get started with Melto Cloud right away without a credit card. Just make an account on https://app.metlo.com and follow the instructions in our docs here.
Although we highly recommend Metlo Cloud, if you're a large company or need an air-gapped system you can self host Metlo as well! Create an account on https://my.metlo.com and follow the instructions on our docs here to setup Metlo in your own Cloud environment.
If you want to deploy our Open Source product we have instructions for AWS, GCP, Azure and Docker.
You can also join our Discord community if you need help or just want to chat!
For tests that we can't autogenerate, our built in testing framework helps you get to 100% Security Coverage on your highest risk APIs. You can build tests in a yaml format to make sure your API is working as intendend.
For example the following test checks for broken authentication:
id: test-payment-processor-metlo.com-user-billing
meta:
name: test-payment-processor.metlo.com/user/billing Test Auth
severity: CRITICAL
tags:
- BROKEN_AUTHENTICATION
test:
- request:
method: POST
url: https://test-payment-processor.metlo.com/user/billing
headers:
- name: Content-Type
value: application/json
- name: Authorization
value: ...
data: |-
{ "ccn": "...", "cc_exp": "...", "cc_code": "..." }
assert:
- key: resp.status
value: 200
- request:
method: POST
url: https://test-payment-processor.metlo.com/user/billing
headers:
- name: Content-Type
value: application/json
data: |-
{ "ccn": "...", "cc_exp": "...", "cc_code": "..." }
assert:
- key: resp.s tatus
value: [ 401, 403 ]
You can see more information on our docs.
Most businesses have adopted public facing APIs to power their websites and apps. This has dramatically increased the attack surface for your business. Thereβs been a 200% increase in API security breaches in just the last year with the APIs of companies like Uber, Meta, Experian and Just Dial leaking millions of records. It's obvious that tools are needed to help security teams make APIs more secure but there's no great solution on the market.
Some solutions require you to go through sales calls to even try the product while others have you to send all your API traffic to their own cloud. Metlo is the first Open Source API security platform that you can self host, and get started for free right away!
We would love for you to come help us make Metlo better. Come join us at Metlo!
This repo is entirely MIT licensed. Features like user management, user roles and attack protection require an enterprise license. Contact us for more information.
Checkout our development guide for more info on how to develop Metlo locally.
WAF bypass Tool is an open source tool to analyze the security of any WAF for False Positives and False Negatives using predefined and customizable payloads. Check your WAF before an attacker does. WAF Bypass Tool is developed by Nemesida WAF team with the participation of community.
It is forbidden to use for illegal and illegal purposes. Don't break the law. We are not responsible for possible risks associated with the use of this software.
The latest waf-bypass always available via the Docker Hub. It can be easily pulled via the following command:
# docker pull nemesida/waf-bypass
# docker run nemesida/waf-bypass --host='example.com'
# git clone https://github.com/nemesida-waf/waf_bypass.git /opt/waf-bypass/
# python3 -m pip install -r /opt/waf-bypass/requirements.txt
# python3 /opt/waf-bypass/main.py --host='example.com'
'--proxy'
(--proxy='http://proxy.example.com:3128'
) - option allows to specify where to connect to instead of the host.
'--header'
(--header 'Authorization: Basic YWRtaW46YWRtaW4=' --header 'X-TOKEN: ABCDEF'
) - option allows to specify the HTTP header to send with all requests (e.g. for authentication). Multiple use is allowed.
'--user-agent'
(--user-agent 'MyUserAgent 1/1'
) - option allows to specify the HTTP User-Agent to send with all requests, except when the User-Agent is set by the payload ("USER-AGENT"
).
'--block-code'
(--block-code='403' --block-code='222'
) - option allows you to specify the HTTP status code to expect when the WAF is blocked. (default is 403
). Multiple use is allowed.
'--threads'
(--threads=15
) - option allows to specify the number of parallel scan threads (default is 10
).
'--timeout'
(--timeout=10
) - option allows to specify a request processing timeout in sec. (default is 30
).
'--json-format'
- an option that allows you to display the result of the work in JSON format (useful for integrating the tool with security platforms).
'--details'
- display the False Positive and False Negative payloads. Not available in JSON
format.
'--exclude-dir'
- exclude the payload's directory (--exclude-dir='SQLi' --exclude-dir='XSS'
). Multiple use is allowed.
Depending on the purpose, payloads are located in the appropriate folders:
When compiling a payload, the following zones, method and options are used:
Base64
, HTML-ENTITY
, UTF-16
) in addition to the encoding for the payload. Multiple values are indicated with a space (e.g. Base64 UTF-16
). Applicable only to for ARGS
, BODY
, COOKIE
and HEADER
zone. Not applicable to payloads in API and MFD directories. Not compatible with option JSON
.Except for some cases described below, the zones are independent of each other and are tested separately (those if 2 zones are specified - the script will send 2 requests - alternately checking one and the second zone).
For the zones you can use %RND%
suffix, which allows you to generate an arbitrary string of 6 letters and numbers. (e.g.: param%RND=my_payload
or param=%RND%
OR A%RND%B
)
You can create your own payloads, to do this, create your own folder on the '/payload/' folder, or place the payload in an existing one (e.g.: '/payload/XSS'). Allowed data format is JSON.
API testing payloads located in this directory are automatically appended with a header 'Content-Type: application/json'
.
For MFD (multipart/form-data) payloads located in this directory, you must specify the BODY
(required) and BOUNDARY
(optional). If BOUNDARY
is not set, it will be generated automatically (in this case, only the payload must be specified for the BODY, without additional data ('... Content-Disposition: form-data; ...'
).
If a BOUNDARY
is specified, then the content of the BODY
must be formatted in accordance with the RFC, but this allows for multiple payloads in BODY
a separated by BOUNDARY
.
Other zones are allowed in this directory (e.g.: URL
, ARGS
etc.). Regardless of the zone, header 'Content-Type: multipart/form-data; boundary=...'
will be added to all requests.