In-context decoy APIs consist of decoy paths within existing APIs supporting legitimate traffic to backend servers.
Any traffic accessing a decoy path receives a preconfigured response. For example, in the
shopping
API, /root
and /admin
are decoy APIs;
and /shoes
is a legitimate API path.
Traffic accessing /shoes
is redirected to the backend API server, while
the traffic that accesses /root
or /admin
receives a
preconfigured response.
The following snippet of an API JSON file shows an in-context decoy API:
{
"api_metadata": {
"protocol": "http",
"url": "/shop",
"hostname": "*",
"cookie": "",
"cookie_idle_timeout": "200m",
"logout_api_enabled": false,
"cookie_persistence_enabled": false,
"login_url": "",
"api_mapping": {
"internal_url": ""
},
;
; Note – other configuration parameters removed
;
"decoy_config":
{
"decoy_enabled": true,
"response_code" : 200, decoy API Configuration
"response_def" : "OK",
"response_message" : "OK",
"decoy_subpaths": [
"/shop/root",
"/shop/admin"
]
}
}
}
The API JSON file defines normal API paths consisting of the path /shop
.
The decoy configuration is enabled for /shop/root
and
/shop/admin
with the following parameters:
- decoy_enabled parameter is set to true. If set to false, no decoy paths are configured.
-
response_code is set to 200. When a decoy
sub-path is accessed, return a
200
response. -
response_def is set to OK. When a decoy
sub-path is accessed, return
OK
as the response.
An in-context decoy API can have a maximum of 32 sub-paths configured for an API.
When configuring in-context decoy APIs, do not leave empty sub-paths which makes your business API into an out-of-context API. No traffic will be forwarded to backend application servers.