Skip to content

Fix case-insensitive matching of sensitive headers - #379

Draft
ffittschen wants to merge 1 commit into
kean:mainfrom
ffittschen:fix/sensitive-headers-case-insensitive
Draft

ffittschen wants to merge 1 commit into
kean:mainfrom
ffittschen:fix/sensitive-headers-case-insensitive

Conversation

@ffittschen

Copy link
Copy Markdown

This PR fixes NetworkLogger.Configuration.sensitiveHeaders matching header names case-sensitively. The root cause was processPatterns() passing [.caseInsensitive] to process(_:options:), which never forwarded the options to Regex. Because URLRequest canonicalizes well-known names (authorization becomes Authorization), a lowercase configuration left bearer tokens unredacted in the store. The fix passes the options through: Regex(pattern, Regex.Options(options)).

Found while working on #378, where HTTP/2 metadata keys are always lowercase.

How to test

  • Configure sensitiveHeaders = ["authorization"] and send a request with an Authorization header. Assert that the stored request header reads <private>.
  • Assert that an uppercase pattern (["X-API-KEY"]) redacts a lowercase x-api-key header, and that wildcard patterns match regardless of case.
  • Assert that response headers are redacted the same way.

processPatterns() builds the sensitiveHeaders regexes with
process(_:options: [.caseInsensitive]), but process(_:options:) never
passed the options on to Regex, so header names were matched
case-sensitively. A configuration with "authorization" didn't redact
"Authorization", which is how URLRequest spells the header.
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.

1 participant