> For the complete documentation index, see [llms.txt](https://docs.flopsar.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flopsar.com/7/user-guide/setting-up-monitoring/data-masking.md).

# 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.

<figure><img src="/files/rjQ1te32BQYHqhdTIiHR" alt=""><figcaption></figcaption></figure>

## 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)&#x20;

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.

<figure><img src="/files/5qZHsGkjXqgJy27Fg5Qw" alt="" width="563"><figcaption></figcaption></figure>

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.

<figure><img src="/files/xKLn1WBCFE0Yrhwnsczr" alt="" width="563"><figcaption></figcaption></figure>

## 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.&#x20;

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