Search code examples
httpsecurityhttp-headerswhitelist

How are white-listed domains actually enforced by some of the big API providers?


I've worked with a lot of big APIs, such as Google Maps, Facebook login, Font Awesome Pro etc. In many of these, you would get a section where you white-list a domain. Basically if the request coming in is from this white-listed domain, it is accepted. Otherwise, it is discarded. This makes sense to me, but how is this actually enforced? Seems like an HTTP request would be really easy to fake if you already know the white-listed domain.

A great example would be loading in a Font Awesome Pro package on your HTML. You get a JS script tag that you put in, but on their dashboard, you get to white-list your domains. But if a malicious visitor to my site wants, they already know my domain and can fake the request and use my Font Awesome Pro package. So how does this actually work?


Solution

  • They use the Referer and/or Origin request headers in the http request to the API. Sure, this can be forged. From a suitable client you can set whatever headers with whatever values you want.

    But not in a browser.

    In a modern, unmodified browser, there is no way for an attacker to embed the same Javascript in their page on their origin (~domain), and still send yours in the request, you can't modify the referer and origin headers. So they can send requests from their own clients or apps, but they can't make their own website with your access for other users (of them) to use, and that's the point. It also is the only thing this is intended to protect against. These Javascripts usually do not really make sense outside the context of a browser, so it's usually just fine.

    As a further argument, you could say that as an attacker, you can just proxy these requests. What if the attacker sets up their website, and implement a proxy on their server side, their clients make requests to their backend, and their backend makes requests to the real API with your credentials and your origin in the request (because the backend could ofc do this). In the rare cases where this would actually make sense (ie. why would they do this, what would be the benefit?), the API owner would quickly blacklist such a server if they have any monitoring in place, for example because normal requests come from all the various home IP addresses of users, but all of these requests would come from the same server. This would be fairly easy to filter. So even this is an acceptable threat for many APIs.