Through reverse-engineering Cloudflare's obfuscated JavaScript payload, Buchodi demonstrates that the Turnstile script reads React's internal fiber tree via __reactFiber$ and __reactProps$ properties — implementation details React explicitly marks as unstable. The analysis reveals this happens before the user can even type, suggesting the depth of framework-internal access is neither documented nor necessary for simple bot detection.
By surfacing this research to Hacker News where it gained 611 points, alberto-m amplified the core transparency concern: neither OpenAI nor Cloudflare have publicly documented this level of DOM and React-internal access, leaving users and developers unaware of the data collection happening before they can even interact with ChatGPT.
The editorial synthesis notes that standard browser fingerprinting (canvas, WebGL, fonts, screen dimensions) is baseline for every bot-detection service. Accessing React's fiber tree and component hierarchy represents an escalation in the arms race — automated scrapers can spoof DOM properties but are unlikely to replicate authentic React internal state, making this a pragmatically effective detection vector even if controversial.
A security researcher known as Buchodi published a detailed reverse-engineering analysis of the obfuscated JavaScript that Cloudflare injects into ChatGPT's frontend. The finding: before a user can type a single character into ChatGPT's input field, Cloudflare's bot-detection script reads React's internal state, traverses the component fiber tree, and fingerprints the DOM environment. The script isn't just checking whether you're human — it's deeply integrated with the application's framework internals in ways that neither OpenAI nor Cloudflare have publicly documented.
The post hit 611 points on Hacker News, resonating with developers who have long suspected that "bot detection" scripts do more than advertised. The researcher decrypted the obfuscated program — no small feat given Cloudflare's multi-layer obfuscation — and walked through exactly what data it collects and when.
Cloudflare's Turnstile system (the successor to their legacy CAPTCHA challenge) runs a JavaScript payload on every page load. On ChatGPT, this script executes before the React application becomes interactive. The key technical revelation is the depth of DOM and React-internal access the script performs.
React applications maintain an internal data structure called a "fiber tree" — it's the framework's internal representation of your component hierarchy, including props, state, hooks, and effects. The Cloudflare script doesn't just read standard DOM properties; it accesses React's `__reactFiber$` and `__reactProps$` prefixed properties that React attaches to DOM nodes. These are implementation details that React explicitly marks as internal and unstable.
What does it collect? The analysis reveals several categories:
Browser fingerprinting: Standard fare — canvas rendering, WebGL parameters, installed fonts, screen dimensions, timezone, language settings. This is the baseline that every bot-detection service uses.
DOM structure analysis: The script walks the DOM tree and examines element properties, event listeners, and mutation patterns. It's looking for signs that the page was rendered by a headless browser or that the DOM was constructed programmatically rather than by a real React render cycle.
React internal state inspection: This is the novel part. By reading the fiber tree properties attached to DOM nodes, the script can verify that the page was actually rendered by React (not a fake DOM constructed to mimic ChatGPT's markup), that the component hierarchy matches expected patterns, and potentially that specific state values exist. This turns React's internal bookkeeping into an authentication signal — if your fiber tree doesn't look right, you're flagged as a bot.
Interaction gating: The script blocks the input field from receiving focus or keystrokes until the fingerprinting and verification process completes. This isn't a passive background check — it's a synchronous gate on user interaction.
The immediate reaction from the developer community splits into two camps.
The security camp argues this is sophisticated and necessary. ChatGPT faces extraordinary bot traffic — automated scraping, credential stuffing, API abuse through the web interface, and prompt injection attacks at scale. If reading React internals helps distinguish real users from sophisticated bots that can fake standard browser fingerprints, that's a reasonable escalation. Headless Chrome can spoof user agents and canvas fingerprints, but accurately replicating React's internal fiber tree with correct state transitions is orders of magnitude harder.
The privacy camp sees this as a surveillance overreach hiding behind security theater. When a third-party script from your CDN vendor reads your application's internal framework state, the boundary between "bot detection" and "application telemetry" dissolves. What stops the next version from reading the content of your chat messages stored in React state? The answer is: only Cloudflare's self-restraint, since the technical capability is already deployed.
There's a third angle that's more pragmatic: this is what happens when you treat framework internals as a stable API. React's fiber properties are prefixed with `$` suffixes specifically because they're meant to be unstable and private. Cloudflare is building a security product on implementation details that could change with any React release. If React 20 changes its fiber attachment scheme, Cloudflare's bot detection breaks — and ChatGPT users get locked out until a patch ships.
This also raises questions about the supply chain trust model. OpenAI presumably consented to Cloudflare running this script, but did they audit exactly what it does? The script is obfuscated. The fact that a third-party researcher had to decrypt it to understand its behavior suggests that even the customer deploying Cloudflare may not fully know what's running in their users' browsers.
If you're running a React application behind Cloudflare with Turnstile or Bot Management enabled, your React fiber tree is likely being read by Cloudflare's scripts. This has several implications:
For security-sensitive applications: Any data stored in React state on DOM-attached components is potentially readable by Cloudflare's bot-detection scripts. If you're building healthcare, financial, or otherwise regulated applications, you need to understand this data flow and whether it fits within your compliance model. The data goes to Cloudflare's servers as part of the bot-detection telemetry.
For performance budgets: The synchronous gating behavior means your Time to Interactive (TTI) metric now includes Cloudflare's fingerprinting time. If the script takes 200ms to complete its analysis (and on slower devices or connections, it could take longer), that's 200ms where your user is staring at an unresponsive input field. For applications where input latency is critical, this is a measurable UX tax that doesn't show up in your Lighthouse scores.
For bot-detection architecture: If you're building your own bot detection, this research is a roadmap. Framework-internal verification is a genuinely clever signal — it's hard to fake and cheap to check. But building on unstable internals is a maintenance liability. A middle ground: check for the *existence* of framework artifacts without depending on their specific structure.
For the broader ecosystem: This sets a precedent. If Cloudflare reads React internals, other security vendors will follow. CDN-injected scripts that understand your framework's internal state are a new category of third-party risk that existing Content Security Policies and Subresource Integrity checks don't address, because the script is served from a domain you've already trusted.
The cat-and-mouse game between bot operators and detection services has escalated to the framework layer. React internals are now a battlefield. Expect other major frameworks — Vue's `__vue_app__` properties, Angular's `ng` debug references, Svelte's compiled output patterns — to become targets for similar fingerprinting. The question isn't whether this is technically clever (it is) but whether the industry will develop transparency standards for what bot-detection scripts are permitted to read. Right now, the answer is: whatever they can access, and you'll find out when someone bothers to deobfuscate the code.
It's absurd how unusable Cloudflare is making the web when using a browser or IP address they consider "suspicious". I've lately been drowning in captchas for the crime of using Firefox. All in the interest of "bot protection", of course.
Presumably this is all because OpenAI offers free ChatGPT to logged out users and don't want that being abused as a free API endpoint.
> These properties only exist if the ChatGPT React application has fully rendered and hydrated. A headless browser that loads the HTML but doesn't execute the JavaScript bundle won't have them. A bot framework that stubs out browser APIs but doesn't actually run React won't ha
Perhaps the author should have made it clearer why we should care about any of this. OpenAI want you to use their real react app. That’s… ok? I skimmed the article looking for the punchline and there doesn’t seem to be one.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Hey! I'm Nick, and I work on Integrity at OpenAI. These checks are part of how we protect our first-party products from abuse like bots, scraping, fraud, and other attempts to misuse the platform.A big reason we invest in this is because we want to keep free and logged-out access available for