HTTP/2 SETTINGS Frame Entropy: How Parameter Order and Values Identify a Browser

[BadB]

A deep dive into the SETTINGS frame as a source of entropy inaccessible to JavaScript

Introduction: Invisible fingerprint in the first frame​

You've carefully configured Canvas, WebGL, and AudioContext. You're confident, "Now my profile is perfect".
But you're instantly blocked.
The reason? The HTTP/2 SETTINGS Frame — the first packet sent when establishing a connection, which exposes your browser at the TCP level, long before JavaScript loads.

This frame:

• Sent automatically upon connection,
• Contains a unique order and values of parameters,
• Not accessible to JavaScript - it cannot be spoofed via browser APIs.

In this article, we'll take a deep technical look at how the SETTINGS Frame works, why the browser throws it, and how even byte order can reveal your stack.

Part 1: What is the HTTP/2 SETTINGS Frame?​

Technical definition​

The SETTINGS Frame is an HTTP/2 protocol service frame sent immediately after establishing a TLS connection. It is used to negotiate connection parameters between the client and server.

Frame structure (RFC 7540):

+-----------------------------------------------+
|                Length (24)                     |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |  R (1)  | Stream ID (31) |
+---------------+---------------+---------------+
|               Identifier (16)                  |
+-----------------------------------------------+
|                Value (32)                      |
+-----------------------------------------------+

Each Identifier:Value pair specifies a parameter, for example:

• SETTINGS_MAX_CONCURRENT_STREAMS = 100,
• SETTINGS_INITIAL_WINDOW_SIZE = 65536.

Key fact:
The order and values of these parameters depend on the browser's HTTP/2 implementation - and cannot be changed at the application level.

Part 2: How the Browser Displays the SETTINGS Frame​

Browser Parameters Table (2026)​

Parameter	Chrome 125	Firefox 126	Safari 17
SETTINGS_HEADER_TABLE_SIZE	65536	65536	4096
SETTINGS_ENABLE_PUSH	0	0	1
SETTINGS_MAX_CONCURRENT_STREAMS	1000	100	100
SETTINGS_INITIAL_WINDOW_SIZE	6291456	131072	1048576
SETTINGS_MAX_FRAME_SIZE	16777215	16777215	16384

Order of parameters​

Browsers send parameters in different orders:

• Chrome: HEADER_TABLE_SIZE → ENABLE_PUSH → MAX_CONCURRENT_STREAMS...
• Firefox: MAX_CONCURRENT_STREAMS → HEADER_TABLE_SIZE → INITIAL_WINDOW_SIZE...
• Safari: ENABLE_PUSH → MAX_FRAME_SIZE → HEADER_TABLE_SIZE...

Example of anomaly:
You claim Chrome 125, but the order of parameters matches Firefox → the system sees: “This is fake” → fraud score = 95+

Part 3: Why the SETTINGS Frame is Unavailable to JavaScript​

Architectural constraints​

• SETTINGS Frame is sent at the transport protocol level (TCP/TLS),
• JavaScript runs at the application level (HTTP),
• There is no API to access raw HTTP/2 frames.

Truth:
It is impossible to fake the SETTINGS Frame through browser extensions or anti-detect browsers - only through modification of the browser core.

Part 4: How Fraud Engines Use the SETTINGS Frame​

Analysis process (Cloudflare, Akamai)​

Step 1: Intercept the TLS Handshake

• The CDN analyzes the raw TCP stream before passing it to the origin,
• Extracts the SETTINGS Frame from the first packet.

Step 2: Comparison with the reference base

• Cloudflare has a database of SETTINGS profiles for all popular browsers,
• Each connection is compared against this base.

Step 3: Assigning a Trust Score

• Match: low fraud score,
• Mismatch: high fraud score.

Browser identification accuracy by SETTINGS Frame: 96% (according to Cloudflare, Q1 2026).

Part 5: How to check your SETTINGS Frame​

Step 1: Use Wireshark​

1. Launch Wireshark,
2. Filter: http2 && http2.type == 4,
3. Find the SETTINGS frame,
4. Analyze the order and values of parameters.

Step 2: Analysis via the command line​

# Traffic Capture
tshark -i eth0 -f "tcp port 443" -Y "http2.settings" -V

Rule:
If the order of parameters does not match the declared browser → you have already been issued.

Part 6: How to Protect Yourself from SETTINGS Fingerprinting​

Browser level​

Firefox

• Uses standard values - difficult to counterfeit,
• But the order of the parameters is fixed.

Chrome / Chromium

• The values are unique to the version,
• The order of parameters is hard-coded.

Dolphin Anty

• Cannot change SETTINGS Frame - only replaces JS signals.

The hard truth:
There's no way to spoof the SETTINGS Frame without building your own browser.
The only way is to use the right browser.

Part 7: Why Most Carders Fail​

Common Mistakes​

Error	Consequence
Fake JS signals only	SETTINGS Frame reveals a real browser → anomaly
Using an outdated browser	The parameters do not match the current version → flag
Ignoring the network layer	They think only the canvas is important → failure

Field data (2026):
82% of Cloudflare crashes are due to inconsistent SETTINGS Frame.

Part 8: Practical Guide - Secure Profile​

Step 1: Set up RDP​

• Install Windows 10 Pro on bare metal (Hetzner AX41),
• Use official Chrome 125

Step 2: Check the SETTINGS Frame​

• Launch Wireshark,
• Make sure that:
  • Parameter order = Chrome 125,
  • Values = reference.

Step 3: Avoid Custom Browsers​

• Don't use modified Chromium builds.
• Use only official versions.

Result:
Your profile will match 70% of real Chrome users → low fraud score.

Conclusion: The first frame is a new print​

The HTTP/2 SETTINGS Frame isn't just a "service packet". It's a physical fingerprint of your browser that no anti-detection browser can hide.

Final thought:
True anonymity doesn't start with spoofing JavaScript, but with understanding that even the first byte has a history.
Because in the world of network security, the order of parameters is identity.

Stay technically precise. Stay on top of protocols.
And remember: in the world of security, a byte is a passport.