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.comExact
www.example.comwww. stripped → example.com
example.com/aboutPath ignored; hostname = example.com
example.com/login?next=/Query ignored; hostname = example.com
hr.example.comOnly www. is stripped; hr. is not
sub.example.comSubdomain not stripped
app.hr.example.comMulti-level subdomain, no match
notexample.comDifferent hostname
example.com.evil.comNormalized to example.com.evil.com

Config: www.example.com

HostnameMatches?Reason
example.comConfig strips www.example.com
www.example.comBoth strip www.
hr.example.comhr.example.com !== example.com
www.hr.example.comStrips to hr.example.com !== example.com

Config: hr.example.com

HostnameMatches?Reason
hr.example.comExact
www.hr.example.comwww. stripped → hr.example.com
example.comParent domain, not matched
other.example.comSibling subdomain
app.hr.example.comChild 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.comStrips www.=== base
hr.example.comEnds with .example.com
app.hr.example.comEnds with .example.com
a.b.c.example.comEnds with .example.com
notexample.comDoes not equal or end with .example.com
other.comUnrelated
example.com.evil.comEnds 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