As of July 2024, the majority of http request headers have been removed from being displayed in the performance console and GLR. The LB can still create rules to act on any header but engineers have no way to view logs in or from XC to determine if their rules are working properly based on live traffic. In many cases, my team is going to the upstream (origin server) http logs to perform this analysis. This gap stops XC or the GLR destination from being a one stop shop for analysis.

It would be ideal if the customer could configure which http headers they want included in XC/GLR even if it means checking a box to assume legal liability of potentially sensitive data being shipped over GLR or stored and displayed in XC. This puts the risk and responsibility on the customer. One way to accomplish this would be to use roles to only allow specific user roles access to those headers in XC for searches in the Performance area. Going further, XC could only store the encrypted version of the headers, and only display real time in the clients browser device the decrypted version only if the user role allows for it. In this way, XC is never storing the plain text value, just the decryption key. That should help with the security and legal aspects of it. This would allow security engineers to see what attackers are sending in sensitive headers such as the Authorization header or API Key headers which is often very useful to help determine the attackers technique.

Likewise for the payload. For security analytics it would be ideal if XC and GLR gave the customer the ability to configure which end points they want payload logging on. XC can protect itself from both legal liability and storage space issues by only allowing up to a certain maximum number of characters and by only storing the encrypted value. in the XC console if the user was in the correct role, the could click a button to see the decrypted payload value. Likewise GLR would ship the encrypted value of the payload and XC would provide engineers in the correct role access to the key so that in their systems they could write automation to review those payloads such as during security events. Again, here the XC console could present a page for the customer to agreed to assume legal liability & risk with shipping payloads.

To help with the additional storage space consumed and maintained XC due to adding more headers and some payloads, XC could start to charge for GLR based on space/storage consumption such as a certain amount with the base package and then some $ amount per month for buckets of additional space.