In this post: http://technotes.iangreenleaf.com/posts/closing-another-nasty-security-hole-in-oauth.html

Enter your full callback URL(s) in this field. This means you should be providing the entire path, such as https://mysite.com/oauth/callback. Do not use wildcards, and do not use only the domain.

The post calls out that wildcards aren't safe.

Later, the post offers an example that only shows a vulnerability of an arbitrary callback URL.

I wonder why a callback like https://*.mysite.com/oauth/callback would be unsafe. It seems none of the OAuth provider supports it (e.g. Google and Facebook).

Thank you.

2 Answers 2


There are more reasons why this is unsafe:

  • OAuth can be redirected to any subdomain under the wildcard, potentially leaking the token and so on. Example: If you have just part of a subdomain and don't own the entire set of domains in your wildcard then an attacker can register another subdomain and set up a very convincing phishing attack like fake login pages or serving malicious webpages.

  • Each token issued to a wildcard URI will work for all clients inside the wildcard If you have multiple services sharing a wildcard oauth URI then these services are effectively sharing security tokens.

For example, the following is a safe way to specify subdomain URIs for oauth redirection. In this example, mail and foo are not sharing security tokens from the oauth provider.

- mail.example.com/some/path
- foo.example.com/another/path

The following is not a safe way to handle subdomain URIs. In this example mail and foo are sharing oauth tokens.

- *.example.com/a/path

In that example if someone came and made a service at a new domain, malicious_actor.example.com, and a user authenticated with malicious_actor then malicious_actor could take that token and use it to login as the user to other services in the wildcard (in this example, mail and foo.)

  • If you have ssl for just a portion of the subdomains in the wildcard then the MitM attack is easy as I can redirect traffic to non a HTTPS web service inside the wildcard and obtain the token and login as that user.

  • Depending on OAuths provider's implementation and yours if you have SSL for *.example.com the attacker can still use ..example.com to MitM attack the enduser as the DNS takes this but the. Sure if the OAuth doesn't validate if subdomain of subdomain

Related question: Can someone explain the "Covert Redirect" vulnerability in OAuth and OpenID?


First thing that comes to mind is that subdomain takeover attacks become more powerful. This can also potentially let, say, your hosted helpdesk software at support.example.com generate valid oauth tokens for admin.example.com for privilege escalation.

And, for bonuses, there are folks running on hosting providers that give a subdomain out for free. Thus, if I can generate an oauth token from one, then I can get a token good for anyone else.

  • Thank you for your answer. I understand it now. Most users, I guess, won't be using oauth on multiple subdomains anyway. The one who uses it needs to implement themselves. It's a fair judgement call.
    – Tanin
    Commented Sep 25, 2018 at 16:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .