Skip to content

fix(auth): handle malformed base64 without Buffer - #110

Closed
awais-ur-rehman wants to merge 1 commit into
jshttp:masterfrom
awais-ur-rehman:feat/reject-malformed-browser-auth
Closed

awais-ur-rehman wants to merge 1 commit into
jshttp:masterfrom
awais-ur-rehman:feat/reject-malformed-browser-auth

Conversation

@awais-ur-rehman

Copy link
Copy Markdown

Summary

When Buffer is unavailable, malformed base64 credentials such as Basic Y or Basic . make the native Uint8Array.fromBase64 decoder throw instead of returning the documented undefined result. Catch decode failures in parse(), with regression tests covering invalid characters, incomplete base64, and valid credentials through the browser decoder.

Breaking Changes

None.

Testing

  • npm exec --yes --package=node@latest -- npm test on Node 26.12.1 — 35 tests passed, none skipped, with native Uint8Array.fromBase64; 100% statement, branch, function, and line coverage.
  • npm test on Node 24.13.0 — 30 passed; five browser-decoder tests skipped because this runtime does not expose the Uint8Array base64 APIs.
  • The complete test command includes build, formatting, type checking, and bundle-size checks (530 B against a 1 kB limit).
  • git diff --check
  • To reproduce manually in a runtime with Uint8Array.fromBase64, set globalThis.Buffer = undefined before importing basic-auth, then call parse('Basic Y'); it now returns undefined.

@blakeembrey blakeembrey left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great fix, but the approach isn't what I'd recommend. Can you instead align the implementation within base64.ts? It should return an empty string to align with node behavior, and keep the catch out of the main code path for node.

There's also already a test file you can update to cover both cases.

@awais-ur-rehman

Copy link
Copy Markdown
Author

I put the catch too high up. Handling decode failures in the browser branch of base64.ts and returning '' keeps the Node path untouched; parse() already rejects that result. The existing base64.spec.ts also has both implementations covered, so the regression cases belong there.

@blakeembrey

Copy link
Copy Markdown
Member

I opted to go with #112 and take it further. There were a few additional issues once I looked into it more, including BOM handling the non-base64 char handling being different in browser vs node paths. I chose to align them instead of hiding differences behind a catch by validating input before decoding.

Another issue with using a catch is that a browser which doesn't support these APIs would always return '' (instead of erroring). That would make for a potentially confusing DX.

@blakeembrey blakeembrey closed this Nov 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants