Choose: Simple Style

Fingerprinting Header Signature

║▌║▌│█║▌║│█│█║║║▌│║▌║

/Tracking/Fingerprinting/passive/header_signature/

  • $ fingerprint@info:~ echo $HEADER-SIGNATURE

  • Name:

    Header Signature

    Original feature purpose:


    The specification of Hypertext Transfer Protocol -- HTTP/1.1 states in Section 4.2 of RFC 2616:

    'The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields.'


    FP-Explanation:

    In consequence of this specification, different vendors, i.e. applications, e.g., browsers, send request headers in a different order because there was no agreement on a specific order. As a result of this arbitrariness in defining a request Header order by each vendor which was then used in different applications, there are different Header Signatures. The header order cannot be changed in the browser settings, which means a signature cannot be spoofed by the user.

    The following six headers are considered for the Header Signature:
    • accept (1)
    • accept-encoding (2)
    • accept-language (3)
    • connection (4)
    • host (5)
    • user-agent (6)

    FP-Type:

    passive

    FP-Categories:

    software-dependent, consistent

    Counter-measures:

    • The header order of each browser is fixed and cannot be changed in the browser settings.
      This means the browser user cannot spoof its browser signature.

    Publications/References:


  • $ fingerprint@info:~ run header-signature-demo

    • Demo:

    >> Jump to Header Signature Demo <<


Well-known browser and their Header Signatures
Browser Name
Header Signature
Header Ordering (with Header Names)
Firefox Engine based 561324 host;user-agent;accept;accept-language;accept-encoding;connection
Chrome Engine based 546123 host;connection;user-agent;accept;accept-encoding;accept-language
Internet Explorer 136254 accept;accept-language;user-agent;accept-encoding;host;connection
Mobile browser and their Header Signatures
Samsung/Dolphin Browser 541623 host;connection;accept;user-agent;accept-encoding;accept-language
Safari Mobile 516324 host;accept;user-agent;accept-language;accept-encoding;connection
Your browser and your Header Signature
Your Browser 5261 host;accept-encoding;user-agent;accept


Header Signature: Results

Browser Name: Your Browser
Browser Signature: 5261
Header Ordering: host;accept-encoding;user-agent;accept

Refresh page.





Main HTTP Request Headers with Explanations and Your Header Values
Header Name
Your Header Value
Explanation
Accept */* The Accept request HTTP header advertises which content types, expressed as MIME types, the client is able to understand. For more details see, e.g., MDN web docs
Accept Encoding gzip, br, zstd, deflate The Accept-Encoding request HTTP header advertises which content encoding, usually a compression algorithm, the client is able to understand. For more details see, e.g., MDN web docs
Accept Language Your browser did not send this request header The Accept-Language request HTTP header advertises which languages the client is able to understand, and which locale variant is preferred. For more details see, e.g., MDN web docs
Connection Your browser did not send this request header The Connection general header controls whether or not the network connection stays open after the current transaction finishes. If the value sent is keep-alive, the connection is persistent and not closed, allowing for subsequent requests to the same server to be done. For more details see, e.g., MDN web docs
DNT Your browser did not send this request header The DNT (Do Not Track) request header indicates the user's tracking preference. It lets users indicate whether they would prefer privacy rather than personalized content. For more details see, e.g., MDN web docs
Host privacycheck.sec.lrz.de The Host request header specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening. For more details see, e.g., MDN web docs
Request Method GET HTTP defines a set of request methods to indicate the desired action to be performed for a given resource. Most common ones are GET, POST, PUT or HEAD. For more details see, e.g., MDN web docs
Referer Your browser did not send this request header The Referer request header contains the address of the previous web page from which a link to the currently requested page was followed. For more details see, e.g., MDN web docs
User Agent Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com) The User-Agent request header contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent. For more details see, e.g., MDN web docs
Other HTTP Request Headers with Explanations
Accept Charset Your browser did not send this request header The Accept-Charset request HTTP header advertises which character set the client is able to understand. For more details see, e.g., MDN web docs
Cache Control Your browser did not send this request header The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. For more details see, e.g., MDN web docs
Cookie Your browser did not send this request header The Cookie HTTP request header contains stored HTTP cookies previously sent by the server with the Set-Cookie header. For more details see, e.g., MDN web docs
Upgrade Insecure Requests Your browser did not send this request header The HTTP Upgrade-Insecure-Requests request header sends a signal to the server expressing the client’s preference for an encrypted and authenticated response. For more details see, e.g., MDN web docs