In this article we learn about some opportunities to shield the SXA search endpoints from traffic that can produce noisy log messages.
Background
Our team frequently reviews the reports generated by a web application scanning software, an activity I highly recommend you incorporate into your process. In addition, we leverage aggregated log messages in another system (i.e. Elastic, Splunk) to better reveal what IIS and Sitecore experiences during the scans.
Research
One issue that seemed particularly interesting is related to the SXA search requests at the relative path //sxa/search/results and //sxa/search/facets. When the query string is invalid such as ?abc123 and ?l=abc123 the Sitecore logs will reveal exception messages due to the fact the query strings can't be properly bound or converted. It's not particular interesting until you see hundreds or thousands of the messages in a short window. I opened a support ticket with Sitecore and they acknowledged this as a bug (at least an issue up to SXA 10.3). Use reference number 589620 to track the progress of this issue.
Resolution
One solution provided by Sitecore support (during the interim period) is to apply a logging filter to exclude the messages.
An alternative solution is to globally prevent all of the abusive traffic from reaching your servers. If you are leveraging a CDN/Proxy product such as Cloudflare/Akamai you can deploy web application firewall rules to block the undesired traffic.
The following screenshot provides an example of rules you could put in place to reduce the noise.
The rules perform the following:
- For each check we ensure that only the /sxa/search/ endpoints are evaluated.
- Reject query string parameters that contain an "L" parameter with anything other than a possible language (e.g. en-US).
- Reject query string parameters that do not reasonably match the values SXA is expecting.
- Reject POST method.
- Reject query string parameters with commands like "ping".
