Repository navigation
fix: require every Origin to be allowed on a CORS request (#1262) (1.4.x) - #1337
Merged
Merged
Conversation
Motivation: `validateOrigins` accepted a request as soon as *one* of the origins in the `Origin` header matched the allowed matcher, but the response echoes back *every* origin it was given (`CorsSettingsImpl.accessControlAllowOrigin` renders the whole list). A request carrying an allowed origin next to a disallowed one therefore passed validation and echoed the disallowed origin back in `Access-Control-Allow-Origin`. The pre-flight path is not affected because it already only accepts a single origin, so this was limited to simple/actual requests. Modification: Require all origins to match rather than any, keeping the existing `allowed-origins = *` short-circuit. The extra `nonEmpty` guard preserves today's handling of a `null` origin (an empty origin list), which must still be rejected when the allowed origins are restricted - `forall` alone would accept it. Result: An actual request is accepted only when every origin it lists is allowed, so no origin that failed validation is echoed back. A request whose origins are all disallowed is still rejected with `InvalidOrigin` listing them, as before. Tests: - sbt http-cors/test - pass (47 tests); a new test asserts that an actual request listing a disallowed origin next to an allowed one is rejected with `InvalidOrigin`. Verified it fails with the fix stashed (the request is accepted and both origins are echoed). The existing "there are two origins" rejection test and the restricted-`null`-origin test both still pass. - sbt http-cors/mimaReportBinaryIssues - pass References: None - requires all origins of a CORS request to be allowed (cherry picked from commit 28def88)
pjfanning
requested review from
He-Pin,
Philippus,
nvollmar,
raboof and
samueleresca
October 10, 2026 11:29
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
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.
cherry pick 28def88 #1262
Motivation:
CorsDirectives.validateOriginsaccepted a CORS request when any of the origins in itsOriginheader matchedallowedOrigins. The response echoes back every origin given, so a request listing a permitted origin alongside a disallowed one was accepted, and the disallowed origin was echoed inAccess-Control-Allow-Origin.Modification:
Require every origin to match (
origins.nonEmpty && origins.forall(allowedOrigins.matches)); theHttpOriginMatcher.*shortcut is unchanged. The only conflict was in the comment abovevalidateOrigins(1.4.x still had the old one-line scaladoc), so the code change is identical to main.Result:
A CORS request is accepted only when all of its origins are allowed; otherwise it is rejected with
CorsRejection.InvalidOrigin.Tests:
CorsDirectiveschange reverted, the new "reject an actual request listing a disallowed origin next to an allowed one" test fails.References:
Backport of #1262