Mock sample for your project: Probely Developers API

Speed up your application development by using "Probely Developers API" ready-to-use mock sample. Mocking this API will allow you to start working in no time. No more accounts to create, API keys to provision, accesses to configure, unplanned downtime, just work.
It also improves your integration tests' quality and reliability by accounting for random failures, slow response time, etc.

Description

Probely is a Web Vulnerability Scanning suite for Agile Teams. It provides
continuous scanning of your Web Applications and lets you efficiently
manage the lifecycle of the vulnerabilities found, in a sleek and
intuitive web interface API.
Quick-Start
Authentication
To use the API, you first need to create a token (API Key).
To create a token, select a target from the drop-down list, go to the
"Settings" page, and click on the "Integrations" tab.
Write a name for the API Key. For example, if you want to use the API Key
for travis,
you could name it "travis". In this example, we chose "example.com_key"
Creating API key
[1]: assets/qs/createapikey_1.png
The API key was created successfully:
API key created
[2]: assets/qs/createapikey_2.png
On every request, you need to pass this token in the authorization header,
like this:
Concepts
The short version is that you run scans on targets, and findings are
created for any issue that is found.
However, there are a few more concepts that must be explained in order to
get a complete picture of how Probely works.
We will spend the next few sections detailing the most important concepts.
Target
A target defines the scope of a scan, what will and won't be included
in the scan plan.
This is done by filling a target's site and assets.
The entry point for the web application (and authentication) is setup
in the target's site.
In modern web applications, you are probably loading resources from
multiple domains.
A single page app, for example, will usualy load the page from one domain
and make AJAX requests to another.
This is what assets are for: they specify what domains our scanner should
follow and create requests for.
Site
A URL is probably not the only thing you will need to setup when scannning your application.
Does the application have an authenticated area? Does it use basic auth?
Does it expect a certain cookie or header?
These parameters are all configured in the target's site.
We need to ensure that only allowed web applications are scanned.
Therefore, we must verify that you have control of any site you wish to include.
This can be done by:
Placing a file on a well-known location, on the site's server;
Creating specific DNS records.
Asset
An asset is very similar to a site. The difference is that it is a domain instead
of a URL. Additionally, an asset has no login or basic auth support.
You can still have custom cookies and headers per asset.
As with the site, you will need to prove an asset's ownership. We have added some
rules to make your life easier, if you already have verified
a site and the domains match, the validation is fast-tracked.
Scans
This is what you're here for.
After configuring your target, you will want to run scans against it.
You can either start a one off scan, or schedule one for later - recurring
or not.
During the scan, we will spider and run several modules to check for
security issues, which we call findings.
You can check the findings even before a scan ends.
If everything goes well, the scan will complete and that is it.
With some findings, our automated processes may have difficulties
determining if it is a false positive or a legitimate issue.
In these instances, a scan will be marked as under review, and we will
further analyze the finding before making a decision.
We will only show findings that, for some degree of confidence, are true
positives.
A finding that we are not sure of will never be displayed.
As much as we try to prevent it, a scan (or a sub-module) can malfunction.
If this happens, a scan is marked as:
"failed": the problem was irrecoverable;
"completed with errors": some module failed but the scan itself completed.
During a scan, we try to determine what frameworks you are using
and add this information to the site and asset objects discussed
previously.
Findings
The last core concept is the finding, this is a security issue that
we have found during our scans.
If the same issue is found in a new scan it will not open a new finding but
update the previous.
A finding will have a lot of information about the issue.
Namely, where it was found, URL, insertion point (e.g. cookie), parameter,
and method.
Evidence we gathered, and the full request and response that we used.
Sugestions of how to go about fixing it.
A full description of the vulnerability is also present in the
definition property.
We also assign a severity and calculate the CVSS score for each.
Besides all this, there are also actions that you can perform on a finding.
You can assign it to one user, leave comments for your team or add labels,
and reduce or increase the severity.
If you don't plan on fixing the finding and accept the risk, or you think
we reported a false positive, you can mark the finding to reflect that.