In-context decoy API
In-context decoy application programming interface (API)s 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 JavaScript Object Notation (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 totrue
. If set tofalse
, no decoy paths are configured. -
response_code
is set to200
. When a decoy sub-path is accessed, return a200
response. -
response_def
is set toOK
. When a decoy sub-path is accessed, returnOK
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. |