I have seen a trend of applications moving their APIs to other domains (from api.application.com to api.applicationapi.com).
Two examples: 3.basecampapi.com and api.dropboxapi.com
Is there a security benefit to host the API in a different domain than the dashboard or marketing website? Why does a subdomain is not enough?
Is there a security benefit to host the API in a different domain than the dashboard or marketing website?
In a word, resilience.
One benefit is that any security blocks which are put in place due to content on the dashboard or marketing website will not impact the API, if the API is on a completely different domain.
(If "marketing" means Wordpress or Drupal, for example, such blocks can be a very real threat!)
I've had direct experience with blocks triggered by the Google Blacklist, and they can impact the domain name and subdomains thereof. If example.com ends up with malware on it, then api.example.com (and api.api.example.com) will get blocked as well.
Moving to api.exampleapi.com cleanly segregates the API so it won't be impacted if example.com is blacklisted.
Why does a subdomain is not enough?
Again, with Google at least, blocks may extend into subdomains as well. Also, DNS-based filters like OpenDNS wildcards will block all subdomains as well.
Under the assumption that the Dropbox web app would e.g. set a session cookie for *.dropbox.com, then this cookie would also be sent to api.dropbox.com.
Since a session cookie is very much security-relevant, it is better to limit its distribution radius. Using a separate domain api.dropboxapi.com ensures that browsers will never send the session cookie there.
Then Dropbox could even allow CORS with credentials on api.dropboxapi.com without the risk that someone could hijack the session cookie of a Dropbox web app user. API requests would be made with a token instead of a session.
