Data Masking

Data masking redacts sensitive values out of the data Flopsar captures from your applications before it is stored. It is applied on the server, at the moment data is recorded, to method-call parameters and to OpenTelemetry attributes. Masking is irreversible: the original value is never written to storage, so masked data cannot be recovered later — by anyone.

Use it to keep secrets and regulated data — passwords, payment card numbers, national identifiers, e-mail addresses, and similar — out of your monitoring data in the first place.

How It Works

A masking rule is a named regular expression (a pattern). When a captured value contains a substring that matches any configured pattern, that substring is replaced with a run of asterisks of the same length; the rest of the value is kept as-is. Values that match nothing are stored unchanged.

A few important details:

• Patterns are matched against the values Flopsar captures, not against parameter names. Only the matching portion of a value is starred — for example, the password=... segment of a connection string is masked while the rest of the string remains readable.

• All configured patterns are combined, so several rules can apply to the same data set at once.

• An individual pattern that is not a valid regular expression is skipped without affecting the others, so one bad entry cannot disable masking everywhere.

Built-in Patterns

Flopsar ships with a set of ready-to-use patterns covering common sensitive data formats, so basic protection is in place out of the box:

• Polish national identifiers — PESEL, NIP, REGON

• Phone numbers (including the +48 prefix)

• E-mail addresses

• Payment card numbers

• Bank account / IBAN numbers

• ID card numbers

• Postal codes

• IPv4 and IPv6 addresses

• MAC addresses

• Passwords in password=/pwd= form (case-insensitive)

You can edit or remove any of these, and add your own.

Managing Patterns

The Data Masking page lists every configured pattern and lets you maintain the set. Managing patterns requires the Edit Data Masks permission, and every change is recorded in the security audit trail.

• Add Pattern — create a new rule by giving it a name and a regular expression. The expression is validated when you save it.

• Edit — change an existing rule's name or expression.

• Delete — remove a rule.

• Search — filter the list by name.

Changes take effect for data recorded after the change; data already stored is not retroactively masked (and, because masking is irreversible, already-masked data stays masked).

Testing a Pattern

Use Test Pattern to check a regular expression against sample text before you rely on it, so you can confirm it matches what you intend — and nothing more — without putting an untested rule into production.

Scope and Limitations

Masking is pattern-based, which has direct consequences you should plan around:

• It reliably catches well-formatted identifiers (the kinds covered by the built-in patterns). Free-form personal data — names, company names, street addresses — does not follow a fixed format and is therefore not masked by the default patterns. Add custom rules where you can, but treat free text as potentially containing unmasked data.

• Masking applies to captured parameter values and OTLP attributes. Plan your instrumentation and filters so that highly sensitive fields are either masked or not captured at all (see Filters & Services).

• The strongest control is to not capture sensitive data you do not need; masking is a second line of defense, not a substitute for scoping what you collect.

For the broader data-protection picture, see Privacy & Data Handling and Known Risks & Limitations.