Staring long enough at honeypot logs, I am sure you will come across one or the other "oddity." Something that at first does not make any sense, but then, in some way, does make sense. After looking at the Next.js issue yesterday, I looked through our logs for other odd headers I may spot. I came across a header that is somewhat normal, but not usually used by bot:

Sec-GPC: 1
Sec-Fetch-Dest: script
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

First, let's talk about what these headers are used for.

The browser creates any header with the "Sec-" prefix, and JavaScript cannot modify the header. This special prefix is supposed to solve the patchwork of "forbidden" headers, which are constantly expanded and never implemented consistently across browsers.  The main reason for "Sec-" headers, which JavaScript may not modify, is to prevent CSRF (Cross Site Request Forgery). You will likely see these headers across different browsers as "Client hints". For example, the "Sec-CH-UA-Model" header.

The four headers listed above are for a different purpose.

Sec-GPC: 1

This header implements a new, experimental privacy feature. Like the failed "Do-Not-Track" header, it signals that you do not wish to be tracked. Unlike "Do-Not-Track," GPC's intent is to prevent the selling of the information. It is sometimes described as a "Do-Not-Sell" feature. It does attempt to align with common privacy regulations like Europe's GDPR and California's CCPA [1].

The "Sec-GPC" header is currently only supported by Firefox. I don't expect much from it in the future, but maybe its alignment with common compliance schemes will give it some teeth.

The remaining headers are more CSRF-focused and available in all major current browsers.

Sec-Fetch-Dest: script

The destination of the request is a script. The request was likely triggered by the "src" attribute of a <script> tag, and expects a script in return. The server may refuse to process the request if a different resource is requested. This prevents a CSRF attack from abusing a "script" tag to send requests for unrelated resources.

Sec-Fetch-Mode: no-cors

The request is same-origin. Again, the server may refuse the request if it expects something else or if there is an indication that this is not a same-origin request.

Sec-Fetch-Site: cross-site

This header indicates how the request was initiated. "cross-site" indicates that the request was initiated by a different site ("cross origin"). The header can also indicate if a request was initiated by a user or was initiated by a different site or origin.

So why is a bot sending it? Does the bot not want me to sell its information? Unlikely an issue. I suspect that some botnet added these headers to evade simple browser fingerprinting. The headers, as used in this request, do not align with the User-Agent. It is not very good at evading browser fingerprinting. But maybe it's good enough.

Looking at today's data, I find 31 source IPs sending requests like this. They are scanning for common credential leakage URLs. Interestingly, they are all located in baremetal.scw.cloud and poneytelecom.eu. As European bots, maybe they are indeed more privacy aware.

[1] https://globalprivacycontrol.org/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|