The functionality allows you to save information about the anomaly in the database, depersonalizing sensitive data (for example, passwords, bank card data, etc.) to ensure their security in case of leakage or unauthorized access to them. Activation of the functionality writes the changed data to the database without the possibility of getting the original value back. Data masking does not apply to displaying information about the attack returned in the response of the correction functionality of the behavioral model.
Changing or removing the settings writes a backup of the previous state. The backup stores active together with the rules and is managed by the rollback methods for the masking entity.
Settings are managed using specially designed queries. The general conventions (authorization, response codes, the *_hash methods and paginated selection) are described in the relevant section.
Request example:
curl http://api.example.com:8080/masking/v1/get_masking --header 'Content-type: application/json' --data '{"key": "%PRODUCT KEY%"}'
Response format:
{
"status": "success",
"active": boolean,
"timestamp": integer,
"masking": object
}
or (in the case where data is missing)
{"status": "none"}
Response example:
{
"status": "success",
"active": true,
"timestamp": 1719335019,
"masking": {
"example.com/index.php": {
"body": {
"login=\\w+": "login=*masked*",
"password=\\w+": "password=*masked*"
},
...
},
...
}
}
active (top level) - if the value is false, masking is switched off for the whole CID. The rules are still returned;timestamp - the date of the last configuration change in the Unix Timestamp format;example.com/index.php - the URL for which the data will be masked;active (inside a URL) - optional boolean. Missing or true means this URL is masked. false keeps the rules of this URL and does not mask it. It is not a zone;body - the zone where the data will be masked. The following data masking zones are available: path, query, body, cookie, user-agent, referer, other_headers (other headers except cookie, user-agent and referer);login=\w+ - a regular expression that defines the data to be masked (in JSON, the backslash must be escaped: login=\\w+);login=*masked* - the string that the masked data will be converted to. The data matching the regular expression login=\w+ will be replaced with login=*masked*.The method allows you to check whether the data has changed without downloading it in full. More detailed information is available in the relevant section.
Request example:
curl http://api.example.com:8080/masking/v1/get_masking_hash --header 'Content-type: application/json' --data '{"key": "%PRODUCT KEY%"}'
Response example:
{"status": "success", "hash": "8ddd2b342d3190a866ee35afb249919a"}
or (in the case where data is missing)
{"status": "none"}
Request example:
curl http://api.example.com:8080/masking/v1/set_masking --header 'Content-type: application/json' --data '{
"key": "%PRODUCT KEY%",
"set": {
"active": true,
"masking": {
"example.com/index.php": {
"active": true,
"body": {
"login=\\w+": "login=*masked*",
"password=\\w+": "password=*masked*"
}
},
"example.com/users/payments.html": {
"active": false,
"body": {
"card=\\w+-\\w+-\\w+-\\w+": "card=***-***-**-**"
}
}
}
}
}'
active (top level) - if the value is false, masking is switched off for the whole CID. The rules are kept;example.com/index.php - the URL for which the data will be masked;active (inside a URL) - optional boolean. Missing or true means this URL is masked. false keeps the rules of this URL and does not mask it. In the example, example.com/users/payments.html is stored and not applied. It is not a zone;body - the zone where the data will be masked. The following data masking zones are available: path, query, body, cookie, user-agent, referer, other_headers (other headers except cookie, user-agent and referer);login=\w+ - a regular expression that defines the data to be masked (in JSON, the backslash must be escaped: login=\\w+);login=*masked* - the string that the masked data will be converted to. The data matching the regular expression login=\w+ will be replaced with login=*masked*.URL format:
The general rules for writing the value of a URL apply to the first-level key of the masking option. The port can be used: example.com:80/abc.
Response example:
{"status": "success"}
or (in case of an error)
{"status": "fail", "description": "%DESCRIPTION%"}
Request example:
curl http://api.example.com:8080/masking/v1/set_masking --header 'Content-type: application/json' --data '{
"key": "%PRODUCT KEY%",
"del": ""
}'
Response example:
{"status": "success"}
or (in case of an error)
{"status": "fail", "description": "%DESCRIPTION%"}