fix(common): use cryptographically secure SHA-256 for transfer cache key generation#69153
Open
alan-agius4 wants to merge 4 commits into
Open
fix(common): use cryptographically secure SHA-256 for transfer cache key generation#69153alan-agius4 wants to merge 4 commits into
alan-agius4 wants to merge 4 commits into
Conversation
…key generation Replace the custom 64-bit non-cryptographic combined DJB2 hashing implementation in HttpTransferCache with a robust, pure JavaScript, synchronous SHA-256 algorithm. Using DJB2 is vulnerable to pre-image and second-preimage attacks due to its small 64-bit keyspace and mathematical simplicity. An attacker could craft colliding request inputs to poison the cache, potentially causing a CDN or the application to serve the wrong cached response to legitimate users. SHA-256 provides strong cryptographic collision resistance, preventing cache key collision attacks. A custom synchronous implementation is required because the Web Crypto API (`crypto.subtle.digest`) is asynchronous, whereas the transfer cache state lookup and interceptor flow must operate synchronously. Also, update the unit tests to dynamically verify the custom SHA-256 output against the native Web Crypto API.
JeanMeche
reviewed
Jun 4, 2026
Member
JeanMeche
left a comment
There was a problem hiding this comment.
AGENT: I have left a few inline suggestions regarding performance optimization for the synchronous SHA-256 implementation. Please consider moving the constants and TextEncoder out of the generateHash function to avoid unnecessary allocations on every request.
… cache key generation
… cache key generation
JeanMeche
reviewed
Jun 4, 2026
JeanMeche
reviewed
Jun 4, 2026
Member
JeanMeche
left a comment
There was a problem hiding this comment.
AGENT: The updates look great! Thank you for addressing the performance feedback. Moving the constants and TextEncoder out of the function, along with the other optimizations, looks perfectly implemented.
JeanMeche
approved these changes
Jun 4, 2026
… cache key generation
Member
|
Looks like we'll need a patch backport. |
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
2 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.
Replace the custom 64-bit non-cryptographic combined DJB2 hashing implementation in HttpTransferCache with a robust, pure JavaScript, synchronous SHA-256 algorithm.
Using DJB2 is vulnerable to pre-image and second-preimage attacks due to its small 64-bit keyspace and mathematical simplicity. An attacker could craft colliding request inputs to poison the cache, potentially causing a CDN or the application to serve the wrong cached response to legitimate users.
SHA-256 provides strong cryptographic collision resistance, preventing cache key collision attacks. A custom synchronous implementation is required because the Web Crypto API (
crypto.subtle.digest) is asynchronous, whereas the transfer cache state lookup and interceptor flow must operate synchronously.Also, update the unit tests to dynamically verify the custom SHA-256 output against the native Web Crypto API.