Sensitive data masking is typically left to application teams in most organizations. In modern architectures, however, dozens of microservices, different teams, different release cycles and legacy applications all run simultaneously. A card number, identity field, email list or session token forgotten in one service can end up in a production response or in the logs.
This risk is not limited to external user screens. Debug logs, access logs, SIEM records, error-tracking systems and records accessed by support teams can all carry sensitive data. Once data enters a log system, cleaning it becomes difficult due to retention policies, backups and access controls.
Some security solutions only detect sensitive data or only mask at the log level. But if the data returned to the user inside the response body is left untouched, the real leakage continues. Simple replace-only approaches are also not sufficient for every scenario — sometimes only the last four digits should be visible, sometimes full masking is required, and sometimes certain characters need to be excluded.
The right approach is to turn sensitive data protection into an edge policy that does not depend on application code. Response body, log IP information and cookie content must each be handled separately with flexible masking controls such as regex, string match, mask character, offset and minimum occurrence.
TR7 Sensitive Data Masking delivers this model: it masks sensitive data at platform level before it reaches users and logs, reducing the risk of data leakage.
TR7 applies sensitive data protection through response body masking, log IP anonymization, cookie encryption and detection signals together.
TR7 can mask or replace sensitive fields in the response body using string or regex matching. The backend service remains unchanged while the content returned to the user is controlled at the edge.
The ipMask rule enables masking of client IP information in logs. This approach helps reduce personal data visibility in data retention and compliance processes.
The cookieEncryption rule can encrypt selected cookie values with AES-256-GCM. Cookie content becomes unreadable on the user side while the platform can manage those values where needed in the request flow.
Known sensitive data patterns such as test card numbers can be captured as security signals. These detections make the possibility of data leakage visible in scoring, logging and incident review workflows.
Sensitive Data Masking delivers different data protection strategies across response body, log and cookie layers together.
The modifyResponse rule runs during the response phase and can process matched data in the response body. The modifyType value can be set to mask, replace or htmlTag. Mask mode hides characters, replace mode substitutes the entire value, and htmlTag mode adds controlled HTML or script to the response. This flexibility covers not only data hiding but also scenarios that require response transformation.
TR7 can match using a literal string or regex through the matcher and matcherType fields. Operators can define their own patterns for national identity numbers, IBANs, card numbers, phone numbers, email addresses or organization-specific data formats. There is no pre-built PII catalog; control depends on the pattern the operator defines. This approach supports different country and industry formats with equal flexibility.
maskChar lets you choose the masking character and is validated as a single character. maskOffset controls how many characters remain visible from the start or end; setting it to 0 masks the entire match. maskFrom prevents masking from applying until a minimum number of occurrences is reached. These settings make both user experience and false-positive risk more controllable.
For data such as card numbers or account references, it is sometimes preferable to show only the last few characters rather than hiding everything. TR7 can configure this behavior with maskOffset. For example, it is possible to leave the last four digits visible while masking the remaining characters. This preserves usability in support and customer verification flows while reducing data leakage risk.
In replace mode, the matched data is fully substituted with the configured replacement value. This suits teams who prefer to replace a sensitive value with a fixed label, an empty value or an organization-standard placeholder instead of starring it out. The replace approach should be used carefully, especially when the response format must remain intact. The operator can choose the masking or replacement strategy independently for each pattern.
TR7 can include chunked or streaming responses in the masking pipeline during response body processing. This provides data protection in modern applications without assuming a single-chunk body. Body processing must be planned alongside buffer limits. For very large responses, performance, memory and masking scope should be adjusted to the needs of the service.
Response body masking can be planned to work within a default limit of 16 KB. The limit can be raised through the interface when needed, but masking decisions at hundreds of megabytes must be weighed against the performance impact. This limit helps balance edge-level data protection with traffic performance. Operators set the scope deliberately on critical services.
The cookieEncryption rule is used to prevent cookie content from remaining readable on the client side. Selected cookie values can be encrypted with AES-256-GCM. The rule is designed to be used once per pool to prevent repeated conflicts. Session or sticky cookie data therefore becomes invisible to the user as meaningful content.
The ipMask rule helps mask client IP information in log fields. This feature reduces log retention risk in environments with data protection requirements similar to GDPR or local privacy regulations. Personal data visibility on the record side can be restricted while application traffic continues to run. Security and compliance teams manage log detail level and privacy requirements together.
TR7 can capture known test credit card number patterns as security signals. This detection does not need to act as a masking rule; it can be used as a scoring, logging and incident review signal. Test or development data leaking into production responses becomes visible more quickly this way. Operations teams can review this signal from a data leakage or wrong environment usage perspective.
Sensitive data masking is operated together with response filter behavior, regex handling, mask parameters, cookie encryption, IP masking and body limits.
Each modifyResponse rule can run as a separate filter on the response body. Matched content is passed through masking or replacement and the response is written back. Because this processing happens in the response phase, it must be evaluated separately from request-side rules.
When matcherType is set to regex, pattern-based matching is used; when set to string, literal matching applies. Regex rules are powerful but must be written carefully. Overly broad or expensive patterns can introduce performance and false-positive risk.
maskChar is validated as a single character. The default value is the asterisk. The single-character requirement helps keep masking output predictable and consistent.
When maskOffset is 0, the entire match can be masked; at higher values, a set number of characters can remain visible. The maskFrom value sets the minimum number of occurrences before masking is applied. These settings are especially important for balancing false-positive reduction and readability.
cookieEncryption, ipMask and modifyResponse are not variants of the same pipeline — they operate as different rule types. Response body, log and cookie layers are each protected with distinct behaviors. This separation makes it possible to choose the appropriate control for each data leakage channel.
Response body masking is evaluated within buffer limits. The default 16 KB limit is sufficient for many API responses; larger responses can be accommodated by raising the limit through the interface. Performance impact and memory usage at large values must be planned separately.
Banking teams can capture card-number-like values with regex and mask them so only the last four digits are visible. The response body is protected at the edge without modifying the backend service.
Health portals can write operator-defined regex patterns for national identity numbers or patient reference numbers. Matched data is fully masked, reducing the chance that sensitive information reaches the user screen or intermediate systems.
Compliance teams can use ipMask to mask client IP information in logs. This reduces personal data visibility during log retention while preserving the operational record stream.
E-commerce and financial services can use cookieEncryption to encrypt selected session or sticky cookie values. Cookie content becomes invisible as meaningful data on the user side, reducing the risk of tampering.
Data leak prevention across response body, log and cookie layers. Let's walk through a live setup on your own services.