LogEntryEventBuilder: Apply Data Masking to HttpRequestEndpoint__c, possibly provide "requestEndpointMasked" flag

[dturkel]

New Feature Summary

Some APIs require keys and other sensitive information in the GET endpoint; Data Masking rules should be applied to protect this information:

In LogEntryEventBuilder.setHttpRequestDetails:

Instead of this.logEntryEvent.HttpRequestEndpoint__c = request.getEndpoint();

Do: this.logEntryEvent.HttpRequestEndpoint__c = applyDataMaskRules(this.userSettings.IsDataMaskingEnabled__c, request.getEndpoint());

[jongpie]

@dturkel this is a great idea, thanks for the suggestion! Any chance you have an example you could provide of a (fake) endpoint + data masking rule that you'd want to apply to the endpoint? If so, I can use that info as a test to ensure this works.

And I could also see extending data masking to be applied to a few other fields:

• Browser Context fields:
  • BrowserAddress__c: this could maaaaybe contain some sensitive parameters?
• HTTP Request fields:
  • HttpRequestEndpoint__c (your suggestion) and HttpRequestEndpointAddress__c (small note here, HttpRequestEndpointAddress__c is the new/preferred field, HttpRequestEndpoint__c is now deprecated but still populated/supported)
• HTTP Response fields:
  • HttpRequestHeaders__c: when populated, this contains header keys and values, which could be sensitive
  • HttpResponseHeaders__c: same as the previous, when populated, this contains key keys and values
• REST Request fields:
  • RestRequestUri__c: similar to HttpRequestEndpoint__c, the URI could contain some sensitive parameters

I think these are all of the fields that could have sensitive data (and don't currently have data masking applied) - if I find others (or you have any other suggestions), I'll add them to this list.

As far as a timeline, I'm currently working on wrapping up Nebula Logger's Winter '25 release over the next few weeks. Once I'm done with that release, I'll have a better sense of when I'll be able to work on this item.

[dturkel]

Hi there @jongpie, thanks for the detailed writeup. In a recent case, the Google Places/Maps APIs has a parameter, "key" (the API service key), that must be included.

My initial rule is probably oversimplistic, since it could apply to far too many other pieces of content. I would/could extend my SenstiveDataRegEx into better capture groups. This is what I used, with the output screenshotted further below:

<CustomMetadata xmlns="http://soap.sforce.com/2006/04/metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <label>Mask &quot;key&quot; values</label> <protected>false</protected> <values> <field>ApplyToMessage__c</field> <value xsi:type="xsd:boolean">true</value> </values> <values> <field>ApplyToRecordJson__c</field> <value xsi:type="xsd:boolean">true</value> </values> <values> <field>IsEnabled__c</field> <value xsi:type="xsd:boolean">true</value> </values> <values> <field>ReplacementRegEx__c</field> <value xsi:type="xsd:string">key=****</value> </values> <values> <field>SensitiveDataRegEx__c</field> <value xsi:type="xsd:string">key=[a-zA-Z0-9]+</value> </values> </CustomMetadata>

[jongpie]

@dturkel awesome, this is very helpful, thanks for sharing this info & screenshot! As soon as I have some time to work on this, I'll let you know if I need anything else.