Fix timing attack length leak in examples#28135
Merged
elithrar merged 2 commits intoproductionfrom Feb 11, 2026
Merged
Conversation
Co-authored-by: elithrar <elithrar@users.noreply.github.com>
ask-bonk
bot
requested review from
a team,
GregBrimble,
MattieTK,
WalshyDev,
irvinebroque,
korinne and
mikenomitch
as code owners
github-actions
bot
assigned
GregBrimble,
irvinebroque,
korinne,
MattieTK,
mikenomitch and
WalshyDev
Contributor
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
Collaborator
|
/bonk fix |
Contributor
Replace early 'return false' on length mismatch with 'return !timingSafeEqual(aBytes, aBytes)' so a constant-time comparison always runs, preventing an attacker from deducing the secret length through response timing.
Contributor
Author
|
Done. Changed both the JavaScript and TypeScript
The Rust and Hono examples in that file don't use this wrapper pattern, so they weren't affected. |
elithrar
approved these changes
Feb 6, 2026
elithrar
approved these changes
Feb 6, 2026
irvinebroque
approved these changes
Feb 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
All tasks complete. Here's a summary of the changes:
Changes made to
src/content/docs/workers/examples/protect-against-timing-attacks.mdxProblem: All three code examples (TypeScript, Python, Hono) returned early when the user input and secret had different lengths. This defeats the purpose of timing-safe comparison — an attacker could determine the exact length of the secret by measuring response times (early return vs. full comparison).
Fix applied across all three examples (TypeScript, Python, Hono):
userValueagainstsecretValuedirectly viatimingSafeEqualuserValueagainst itself (alwaystrue) and negate it (becomesfalse), ensuring a constant-time comparison always runs regardless of length mismatchProse changes:
:::cautionadmonition block explicitly warning users not to return early on length mismatch and explaining the correct patternReview results: All three code snippets pass correctness review — the timing-safe logic is sound, edge cases (empty Authorization header producing zero-length buffers) are handled correctly, and the
timingSafeEqualAPI usage matches the Cloudflare Workers runtime.Note: The
basic-auth.mdxexample has the same early-return vulnerability in itstimingSafeEqualwrapper function. That's a separate issue worth a follow-up fix.Closes #23623
github run