Overview
What is its Purpose?
- Conditionally modifies or deletes header, parameter, or body fields or values in messages returned from backend API.
- Eliminates the need to create separate APIs for each user type by providing response customization according to different user types.
- Ensures data privacy by masking or removing sensitive information in message content.
- Performs flexible data manipulation with condition-based actions, using various operators for numeric, text, and time data types.
Working Principle
- Response Reception: Message returned from backend API reaches the API Gateway.
- Policy Check: If the Data Redaction policy is active, the system checks in the following order:
- Is a Condition defined? If so, is the condition met?
- Is the policy active (active=true)?
- Are rule sets defined?
- Rule Evaluation: For each rule set:
- Variable existence or variable value check is performed.
- If the condition is met, defined actions are applied in order.
- Action Application:
- Modify: The value of the selected field is modified using an operator according to the data type.
- Delete: The selected field or value is removed from the message.
- Result: Customized response is transmitted to the client.
Differences from Business Rule Policy
Features and Capabilities
Basic Features
- Conditional Data Manipulation: Dynamically modifies or deletes message content based on variable existence or variable value.
- Multiple Data Type Support: Performs operations with various operators on numeric, text, and time data types.
- Flexible Action Definition: Multiple actions can be added to a rule, actions are applied in order.
- Variable-Based Access: Provides access to header, parameter, or body fields of the message with variables.
- Active/Passive Status Control: Easily change the active or passive status of the policy (active/passive toggle). In passive state, the policy is not applied but its configuration is preserved.
- Condition-Based Application: Determine when the policy will be applied by creating complex conditions with Query Builder (e.g., only for specific endpoints or header values).
Advanced Features
- Advanced Text Operations: Text manipulation operators such as Base64 encode/decode, mask, format, substring, replace, transform.
- Mathematical Operations: Addition, subtraction, multiplication, division, modulo, exponentiation operations on numeric values.
- Time Manipulation: Addition or subtraction operations on time values.
- XSLT and JOLT Transformations: Can perform XML and JSON transformations with Transform operator.
- Export/Import Feature: Export policy configuration as a ZIP file. Import to different environments (Development, Test, Production). Version control and backup capability.
- Policy Group and Proxy Group Support: Manage multiple policies within Policy Group. Bulk policy assignment to Proxy Groups. Centralized update and deployment operations.
- Deploy and Versioning: Deploy policy changes to live environment. See which API Proxies use it (Policy Usage). Proxy Group and Policy Group usage reports.
Usage Scenarios
| Scenario | Situation | Solution (Policy Application) | Expected Behavior / Result |
|---|---|---|---|
| Sensitive Information Masking | Sensitive information such as credit card number, phone number in API response needs to be hidden | Specific characters are replaced with * using Mask operator. | Sensitive information is transmitted to client in masked form. |
| Data Filtering by User Type | Different data sets need to be shown to different user types | Condition is defined according to user type, relevant fields are deleted or modified. | Each user type sees data within their authorization. |
| Price Information Customization | Different pricing needs to be shown to different customer segments | Price field is modified according to variable value, discount rates are applied. | Customized prices are shown according to customer segment. |
| Header Clearing | Some headers from backend should not be transmitted to client | Relevant header fields are removed with delete action. | Specified headers are removed from response. |
| Data Transformation | Format of data from backend needs to be changed | XSLT or JOLT transformation is applied with Transform operator. | Data is transformed to desired format and transmitted. |
| Base64 Encoding/Decoding | Base64 encoded data in message content needs to be processed | Encode Base64 or Decode Base64 operator is used. | Data is encoded or decoded. |
| Time Information Manipulation | Time information in response needs to be adjusted according to different time zones | Addition or subtraction operation is performed on time type. | Time information is adjusted according to desired time zone. |
| Standardization in API Proxy Group (optional) | Apply the same data manipulation rule on multiple API Proxies | Policy is added to Policy Group, linked to Proxy Group, centralized deployment is performed. | All linked API Proxy instances use the same Data Redaction rule. |
Configuring Policy Parameters
At this step, users can create a new policy or configure existing policy parameters to define data manipulation rules. The defined parameters directly affect how the policy works (e.g., which fields will be modified, under which conditions actions will be performed, conditional activations, etc.). This way, the policy can be customized according to organization-specific requirements and managed centrally.Creating a New Data Redaction Policy
Configuration Steps
| Step | Description / Operation |
|---|---|
| Step 1: Going to Creation Page | - Go to Development → Global Settings → Global Policies → Redaction section from the left menu. - Click the [+ Create] button at the top right. |
| Step 2: Entering Basic Information | Policy Status: Shows Active/Passive status. New policies are active by default. Name (Required): Example: Production_DataRedaction- Enter a unique name, it cannot start with a space. - System automatically checks. Green checkmark: available. Red cross: existing name. Description: Example: “Sensitive information masking rule for production service” - Max. 1000 characters. - Explain the purpose of the policy. |
| Step 3: Creating Rule Set | Rule Sets: - Click the [+ Add Rule Set] button to add a new rule. - Follow the steps below for each rule set. |
| Step 4: Rule Configuration | Redact By: - Existence of a variable: Specifies which element (header, parameter, body) of the message to check. - Value of a variable: Specifies what values the element should have. Variable for rule set: Select a variable to access the element in the message. Values: If variable value is selected, enter comma-separated values. |
| Step 5: Defining Action | Action Definitions: - Click the [+ Add Action] button to add an action. - Select one of Modify or Delete actions. - Actions are applied in order, you can change the order. |
| Step 6: Configuring Modify Action | Modify Variable: Select a variable to specify which element to modify. Variable Data Type: Select Numeric, Text, or Time. Operator: Select the appropriate operator according to data type (e.g., Replace, Mask, Addition, etc.). Target Value Source Type: - Specify the Value: Enter value manually. - Use a Variable: Get value from variable. Value or Variable for target value source: Fill in the relevant field. |
| Step 7: Configuring Delete Action | Delete: Select a variable to specify which element to delete. This action does not error if not found, continues with other operations. |
| Step 8: Defining Condition (Optional) | - Go to the Condition tab. - Conditions determine when the policy will be active. Examples: - Environment-based: Header = X-Environment, Operator = Equals, Value = production- Endpoint-based: Path = /api/admin/*- User type-based: Header = X-User-Type, Operator = Equals, Value = premiumIf no condition is defined, the policy is always active. |
| Step 9: Customizing Error Message (Optional) | - Go to the Error Message Customization tab. - Customize the message to be returned when action fails. Default: { "statusCode": 500, "message": "[Default error message]" }Custom: { "statusCode": 500, "errorCode": "[CUSTOM_ERROR_CODE]", "message": "[Custom message]" } |
| Step 10: Saving | - Click the [Save] button at the top right. Checklist: Unique name. Required fields filled. At least one rule set defined. Result: - Policy is added to the list. - Can be linked to APIs. - If it’s a global policy, it is automatically applied. |
Rule and Action Details
Creating a Rule
A rule is a criterion that specifies what the response will be redacted by. An action is the editing operation to be performed on the message when this criterion is encountered. Multiple actions can be added to a rule. Message customization is performed according to the given action order. Additionally, there can be multiple rules in the policy. The fields used for rule configuration are shown in the table below.| Field | Description |
|---|---|
| Redact By | The redaction operation can be performed according to different values selected from within the sent message. Existence of a variable: Specifies which element (header, parameter, body) of the message to check when applying the rule. Value of a variable: Specifies what values the element in the message should have when applying the rule. |
| Variable for rule set | A variable is selected to access the element in the message. |
| Values | If redaction management is selected as Variable value, this field becomes active. The values that should be in the field selected with the variable should be written separated by commas. |
| Action Definitions | Actions that can be applied are listed in order of execution in this table, or new ones can be defined. |
Creating an Action
2 types of actions can be selected:- Modify: The value of an existing field in the header, parameter, or body of the request/response is modified.
- Delete: The value of an existing field or the entire field in the header, parameter, or body of the request/response is deleted.
Modify Action
Used to modify the value in the header, parameter, or body of the message. When this action is selected, it is assumed that the value to be added exists in the message, and if it is not found, the policy errors. This should be considered in the condition part of the rule. The fields used for modify action configuration are shown in the table below.| Field | Description |
|---|---|
| Modify Variable | A variable is selected to specify which element of the message to modify. |
| Variable Data Type | Specifies what data type the variable value is. Details are in the table below. |
| Operator | Selects which operation will be applied in the data type. Details are in the table below. |
| Target Value Source Type | Selects where the value source will be taken from. Specify the Value: When this option is selected, the value of the source is entered manually. Use a Variable: With this option, the value is created from a variable. |
| Value | The value of the element to be modified is written. |
| Variable for target value source | The value of the element to be modified is selected from a variable. |
Data Type and Operators
The data type (Variable Data Type) and operations (Operator) for these data types can be:| Data Type | Action | Description |
|---|---|---|
| Numeric | Addition | Modifies by adding the target value to the value to be modified. |
| Subtraction | Modifies by subtracting the target value from the value to be modified. | |
| Multiplication | Modifies by multiplying the value to be modified with the target value. | |
| Division | Modifies by dividing the value to be modified by the target value. | |
| Modulo | Modifies by taking the modulo of the value to be modified with respect to the target value. | |
| Exponentiation | Modifies by taking the exponentiation of the value to be modified to the power of the target value. | |
| Text | Concat | Modifies by appending the target value to the end of the value to be modified. |
| Decode Base64 | Modifies by subjecting the value to be modified to Base64 decryption operation. | |
| Encode Base64 | Modifies by subjecting the value to be modified to Base64 encryption operation. | |
| Format | Modifies by masking the value with the properties specified in the javax.swing.text.MaskFormatter class. | |
| Insert | Modifies by writing the target value starting from the specified text index of the value to be modified. | |
| Mask | Modifies by masking the entire value to be modified or the range specified with text indices. | |
| Replace First | Modifies by replacing the first match of the specified replacement data in the value to be modified with the target value. | |
| Replace | Modifies by replacing all matches of the specified replacement data in the value to be modified with the target value. | |
| Replace With | Modifies by completely replacing the value to be modified with the target value. | |
| Substring | Modifies by deleting fields outside the specified text indices part of the value to be modified. | |
| Transform | Modifies by subjecting the value to be modified to XSLT or JOLT operation. | |
| Trim | Removes leading and trailing spaces of the value to be modified. | |
| Time | Addition | Adds the specified time unit and amount to the value to be modified. |
| Subtraction | Subtracts the specified time unit and amount from the value to be modified. |
Delete Action
Used to delete the value in the header, parameter, or body of the message. When this action is selected, it is assumed that the value to be deleted exists in the message, and if it is not found, the policy does not error, continues with other operations. Where in the message will be deleted is specified with a variable. For the description of Conditions and Error Message Customization panels, you can review the Conditions and Error Message Customization sections on the What is Policy? page.Deleting the Policy
For the deletion steps of this policy and the operations to be applied when it is in use, you can refer to the Removing Policy from Flow section on the Policy Management page.Exporting/Importing the Policy
For the export and import steps of this policy, you can refer to the Export/Import page.Linking the Policy to API
For the process of how this policy will be linked to APIs, you can refer to the Linking Policy to API section on the Policy Management page.Advanced Features
| Feature | Description and Steps |
|---|---|
| XSLT and JOLT Transformations | - You can transform XML and JSON data with Transform operator. - You can perform complex transformations using XSLT templates or JOLT spec files. - Transformation templates can be entered from variables or manually. |
| Conditional Masking | - You can mask specific parts of sensitive information with Mask operator. - You can specify the masking range using text indices. - You can mask formatted data such as phone numbers, credit cards with Format operator. |
| Multiple Rule Management | - You can create separate rules for different scenarios by defining multiple rule sets. - Each rule set works independently and applies its own actions. - There is no priority order between rule sets, all rules are evaluated. |
| Variable-Based Dynamic Values | - You can make dynamic value assignments by using variables as value source. - You can perform operations by taking values from other fields in the request or response. - You can provide centralized value management by using project variables. |
Best Practices
Things to Do and Best Practices
| Category | Description / Recommendations |
|---|---|
| Rule Design | Bad: Trying to modify all fields in a single rule. Good: Creating separate rule sets by grouping related fields logically. Best: Defining special rule sets for each user type or scenario, clearly determining conditions. |
| Action Ordering | Bad: Ordering actions randomly. Good: Organizing actions according to logical order (modify first, then delete). Best: Ensuring actions do not affect each other, verifying with test scenarios. |
| Variable Management | Bad: Using different variables in each rule, creating inconsistency. Good: Using standard variable sets, keeping variable naming consistent. Best: Managing project variables centrally, documenting. |
| Condition Usage | Bad: Applying policy to all requests without defining conditions. Good: Avoiding unnecessary processing load by defining basic conditions. Best: Optimizing complex conditions with Query Builder, performing performance tests. |
| Error Management | Bad: Leaving error messages as default, not providing meaningful information to users. Good: Defining custom error messages, adding error codes. Best: Thinking about error scenarios in advance, testing, determining logging strategy. |
| Policy Lifecycle | Bad: Making production changes directly in live. Good: Localizing and testing the same policy in test environment. Best: Creating versions with Export/Import and monitoring usage reports after Deploy. |
Security Best Practices
| Security Area | Description / Warnings |
|---|---|
| Sensitive Information Masking | Always mask sensitive information such as credit card numbers, phone numbers, emails; preserve data integrity by using mask instead of complete deletion. |
| Variable Validation | Do not apply actions without variable existence check; add error management for values that cannot be found. |
| Action Security | Use delete actions carefully; clearly determine conditions before deleting critical fields, test. |
| Performance Optimization | Minimize complex Transform operations; optimize XSLT/JOLT templates, avoid unnecessary processing load. |
| Logging Strategy | Log masking or deletion operations but do not write sensitive information to logs; perform secure logging for audit trail. |
Things to Avoid
| Category | Description / Warnings |
|---|---|
| Wrong Data Type Selection | Why avoid: Applying numeric operator to text value produces errors or unexpected results. Alternative: Verify the data type of the variable value in advance, select appropriate operator. |
| Missing Condition Definition | Why avoid: Applying policy to all responses without defining conditions leads to performance problems. Alternative: Always define conditions, policy should be active only in necessary situations. |
| Variable Access Errors | Why avoid: Trying to access non-existent variables causes policy errors. Alternative: Perform variable existence check, add error management. |
| Deploying Global Changes Directly | Why avoid: Multiple API Proxies are affected at the same time, service interruption may occur. Alternative: First localize and test, then update the global policy. |
Performance Tips
| Criterion | Recommendation / Impact |
|---|---|
| Number of Rules | Recommendation: Reduce unnecessary rule sets, combine similar rules. Impact: Policy evaluation time shortens, CPU load decreases. |
| Action Complexity | Recommendation: Minimize complex Transform operations, prefer simple operators. Impact: Processing time shortens, memory usage decreases. |
| Condition Optimization | Recommendation: Keep conditions simple, break complex conditions into parts. Impact: Condition evaluation speeds up, early exit is provided. |
| Variable Access | Recommendation: Cache frequently used variables, avoid unnecessary variable access. Impact: Variable resolution time shortens, performance increases. |
Frequently Asked Questions (FAQ)
| Category | Question | Answer |
|---|---|---|
| General | In which scenarios should Data Redaction policy be preferred? | It can be used in all situations where the content of messages returned from backend API needs to be modified or filtered according to user type, condition, or security requirements. |
| General | What is the difference between Business Rule policy and Data Redaction policy? | Business Rule policy works on both request and response pipelines and direct actions can be defined. Data Redaction policy only works on the response pipeline and conditional actions are defined. |
| Technical | What happens if Modify action is applied to a value that cannot be found? | Policy errors and response is not transmitted. Variable existence check should be performed in the rule condition to prevent this situation. |
| Technical | What happens if Delete action is applied to a value that cannot be found? | Policy does not error, continues with other operations. This behavior ensures safe operation of delete action. |
| Usage | Can multiple actions be added to a rule? | Yes, multiple actions can be added to a rule. Actions are applied in the order they are defined. |
| Usage | What transformations can be performed with Transform operator? | XML transformations with XSLT templates or JSON transformations with JOLT spec files can be performed. |
| Usage | How is Mask operator used? | With Mask operator, the entire text value or the specified index range is replaced with masking character (usually *). |