Wildcard urls for allowed_origins

[randikabanura]

Can the gem config allowed_origins use wildcard origin url such as https://*.example.com to match against the request origins? If not is there any reason why we should not implement a such a feature?

[santiagorodriguez96]

Hi @randikabanura !

Thank you for creating the issue and bringing up conversation for your issue 🙂

What you are saying is interesting... I guess we could allow users of the gem to set up wildcard origins, although the specification discourages the use of subdomains:

Note: See § 13.4.8 Code injection attacks for a discussion of the risks of allowing any subdomain of the RP ID.

[source]

Malicious code could, by the credential scope rules, be hosted on a subdomain of the RP ID. For example, user-submitted code hosted on usercontent.example.org could exercise any credentials scoped to the RP ID example.org. If the Relying Party allows a subdomain origin when verifying the assertion, malicious users could use this to launch a man-in-the-middle attack to obtain valid authentication assertions and impersonate the victims of the attack.
Therefore, the Relying Party by default SHOULD NOT allow a subdomain origin when verifying the assertion. If the Relying Party needs to allow a subdomain origin, then the Relying Party MUST NOT serve untrusted code on any allowed subdomain of origins within the scope of its public key credentials.

[source]

(See also: w3c/webauthn#1731)

I guess we could give users of the gem the option to decide if they want to open up to that or not 🤔

Probably out of scope but perhaps we could throw some sort of warning?

[halo]

I just happened to stumble upon https://passkeys.dev/docs/advanced/related-origins/ maybe that could solve the problem for someone, so I thought I'd throw it in here.