This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Custom Mapping Configuration

Using a mapping file to tell the browser protector exactly which html elements to unprotect automatically or to automatically select a data element when trying to unprotect.

Custom Mapping Configuration

Custom mappings allow administrators to explicitly tell the Browser Protector which HTML elements on a specific site need to be protected or unprotected.

Custom mappings are defined under the optional customMappings key in the extension configuration JSON.


Structure Overview

customMappings
└── domains[]
    ├── domain                          — hostname to scope the rules to
    ├── page[]
    │   ├── path[]                      — URL path segments to scope rules to (empty = all paths on the domain)
    │   └── mappings[]                  — groups of attribute-based rules
    │       ├── attributeName           — HTML attribute to inspect (e.g. id, class, aria-label)
    │       ├── value                   — expected attribute value; omit to match on attribute presence alone
    │       └── entries[]
    │           ├── dataElement         — Protegrity data element name to use for the operation
    │           ├── operation           — "protect" or "unprotect"
    │           ├── splitSegments       — (optional) split text content into individual tokens before processing
    │           └── parentConditions[]  — (optional) ancestor element constraints for narrowing matches
    └── title[]
        ├── path[]                      — URL path segments to scope title rules to (empty = all paths on the domain)
        └── algo                        — identifier for the page title unprotection algorithm to use

Domain Matching

PatternBehavior
example.comMatches example.com and www.example.com only
*.example.comMatches all subdomains (app.example.com, crm.example.com, etc.)

Exact domain entries take precedence over wildcard entries.

To read more about domain rules, go here.


Path Matching

  • An empty path array applies the mapping rules to every page on the matched domain.
  • When paths are provided, they are matched as substrings of the current URL path (e.g. "/accounts" matches /accounts/list).

Parent Conditions

parentConditions can optionally restrict a mapping so it only fires when the target element has a specific ancestor within a certain number of DOM levels. Each condition can check the ancestor’s tag name, an attribute name, and/or an attribute value.


Example

The following configuration unprotects any element on crm.example.com that has aria-label="customer-ssn", using the SSN data element:

"customMappings": {
    "domains": [
        {
        "domain": "crm.example.com",
        "page": [
            {
            "path": [],
            "mappings": [
                {
                "attributeName": "aria-label",
                "value": "customer-ssn",
                "entries": [
                    {
                    "dataElement": "SSN",
                    "operation": "unprotect"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

When the extension detects an element such as:

<span aria-label="customer-ssn">***-**-1234</span>

This example html element will match the custom mapping rule above, allowing the Protegrity browser protector to know this is an element that when selected, will use the SSN data element for unprotection.


Page Title Unprotection

The title array within a domain entry enables unprotection of protected values embedded in the browser’s page <title>. This is useful for single-page applications (such as Salesforce) that reflect record data in the tab title after navigation.

Each title entry specifies:

  • path — URL path scope (empty array = applies to all pages on the domain)
  • algo — the name of the page title extraction algorithm to use

The extension monitors the <title> element for changes and re-runs unprotection on navigation or if the title changes.


Example

"customMappings": {
  "domains": [
    {
      "domain": "myorg.example.com",
      "title": [
        {
          "path": ["/example/r/User"],
          "algo": "Example_Algo"
        }
      ]
    }
  ]
}

For a title such as example Title, the extension will unprotect and rewrite the title with the plaintext result.


Notes

  • Attribute matching is case-insensitive.
  • Class attribute matching supports partial class list matching (i.e. the configured value only needs to appear as one class in a multi-class attribute).

1 - Domain Matching Rules

Domain matching rules for custom mapping matching customization.

Exact Match Rules (config does NOT start with *)

Config: example.com

Hostname (from URL)Matches?Reason
example.com✅Exact
www.example.com✅www. stripped → example.com
example.com/about✅Path ignored; hostname = example.com
example.com/login?next=/✅Query ignored; hostname = example.com
hr.example.com❌Only www. is stripped; hr. is not
sub.example.com❌Subdomain not stripped
app.hr.example.com❌Multi-level subdomain, no match
notexample.com❌Different hostname
example.com.evil.com❌Normalized to example.com.evil.com

Config: www.example.com

HostnameMatches?Reason
example.com✅Config strips www. → example.com
www.example.com✅Both strip www.
hr.example.com❌hr.example.com !== example.com
www.hr.example.com❌Strips to hr.example.com !== example.com

Config: hr.example.com

HostnameMatches?Reason
hr.example.com✅Exact
www.hr.example.com✅www. stripped → hr.example.com
example.com❌Parent domain, not matched
other.example.com❌Sibling subdomain
app.hr.example.com❌Child subdomain; only www. is stripped

Wildcard Rules (config starts with *)

Both *example.com and *.example.com normalize to base example.com.

Config: *example.com or *.example.com

HostnameMatches?Reason
example.com✅=== base
www.example.com✅Strips www. → === base
hr.example.com✅Ends with .example.com
app.hr.example.com✅Ends with .example.com
a.b.c.example.com✅Ends with .example.com
notexample.com❌Does not equal or end with .example.com
other.com❌Unrelated
example.com.evil.com❌Ends with .com, not .example.com

Exact vs. Wildcard Priority

When both example.com (exact) and *.example.com (wildcard) are in config, exact entries are evaluated first. Wildcard is only used as a fallback.

HostnameRule used
example.comExact example.com wins
www.example.comExact example.com wins
hr.example.comNo exact match → wildcard used
app.hr.example.comNo exact match → wildcard used

Things That NEVER Affect Matching

ComponentExampleEffect
Path/about, /loginIgnored
Query string?id=123&next=/homeIgnored
Hash#section-2Ignored
Port:8080, :443Ignored
Protocolhttps://, http://Ignored