docs: anchor regex origin examples to avoid lookalike matches (#408)#412
Open
SAY-5 wants to merge 1 commit intoexpressjs:masterfrom
Open
docs: anchor regex origin examples to avoid lookalike matches (#408)#412SAY-5 wants to merge 1 commit intoexpressjs:masterfrom
SAY-5 wants to merge 1 commit intoexpressjs:masterfrom
Conversation
…sjs#408) Closes expressjs#408. The README's regex example for the `origin` option was /example\\.com$/, which matches any origin whose string ends with example.com. Because the browser's Origin header includes the scheme (https://example.com), that pattern also matches attacker-controlled lookalikes like https://evil-example.com and https://notexample.com — the attacker registers evil-example.com and immediately gets CORS access to any app that copied the example verbatim, which is a CORS bypass especially when credentials: true is set. The fix is to teach an anchored form that matches only origins that actually start with the scheme and end at example.com: /^https?:\\/\\/(.+\\.)?example\\.com$/ That is the pattern the repo's own test suite already uses (test/test.js:184) to verify regex origins, so callers copying the README example now match the behavior the library itself is tested against. Also anchored the array-form example for consistency and added a short note explaining why a trailing-only anchor is unsafe. Docs only — no code changes.
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
1 participant
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.
Closes #408.
The README's documented regex example for the `origin` option was `/example.com$/` with the explanation:
The problem is that the `Origin` header sent by browsers includes the scheme (e.g. `https://example.com\`), so that pattern matches any origin whose string ends with `example.com`. That includes attacker-controlled lookalikes:
An attacker only has to register `evil-example.com` to get CORS access to any app that copied the example verbatim — this is a full CORS bypass, and on any app using `credentials: true` it lets the attacker's origin read authenticated responses.
The repo's own test suite already uses the right pattern (`test/test.js:184`):
```js
{ origin: /:\/\/(.+\.)?example.com$/ }
```
This PR updates the README to teach a scheme-anchored form:
```js
/^https?:\/\/(.+\.)?example.com$/
```
which matches `https://example.com\` and its subdomains but rejects `evil-example.com` / `notexample.com`. Also anchored the array-form example for consistency and added a short note explaining why a trailing-only anchor is unsafe so future readers don't regress to the original pattern.
Docs only — no code changes.