Custom Data Types

The AppSentinels API Security Platform supports predefined Sensitive and PII Data Types out-of-the-box. However, in many applications, there are parameters that may be unique to the organization or application but still require the same level of protection as standard sensitive information. To address this, the platform allows the creation and management of Custom Data Types.

While predefined types such as email, phone number, SSN, etc., cover a broad range of common sensitive data, custom data types provide flexibility to:

• Extend detection for application-specific sensitive parameters (e.g., customerAccountID, internalToken).
• Ensure complete data protection aligned with business logic and compliance requirements.
• Empower teams to proactively define and track non-standard sensitive fields.

Creating a New Custom Data Type

Custom Data Types can be configured from the platform by navigating to Settings → Data Types → Custom

1. Click on "Add Custom Data Type"
   This opens the form to define the properties of the custom type.
2. Enter a Name
   This should be a descriptive label for the sensitive parameter (e.g., BankAccountToken).
3. Specify Matching Criteria
   You can define how this data type should be identified in the traffic:
   • Regex Pattern: A regular expression that matches the expected value format.
   • Field Name Match: Keywords or parameter names such as bank_token, acctId.
4. Choose Scope (Location)
   • Request Body
   • Query Parameter
   • Response
   • Header
   This tells AppSentinels where to look for the custom data.
5. Save the Configuration
   Once saved, the custom data type becomes part of the sensitive data detection mechanism.

Managing Custom Data Types

• View List: All created custom data types are listed in the Custom tab with their name, scope, and pattern.
• Edit or Delete: You can modify or remove a custom data type at any time.

Use Cases for Custom Data Types

• Applications that use unique identifiers not considered sensitive by default (e.g., loyalty codes).
• Regulatory requirements that consider certain application-specific fields as PII.
• Enhancing threat detection and minimizing exposure to custom internal tokens or identifiers.

Example

Visibility and Reporting

• Included in the Parameter Catalogue.
• Highlighted in Sensitive Data Discovery.
• Available in Security Events and Reports.

Notes

• Avoid overly broad patterns that might cause high false positives.
• Test regex and field matches using sample API traffic.
• Ensure naming is intuitive for easy mapping and alert understanding.