Is splitting a REST API server from a Web server considered a security threat?

Question

I am participating in a project that involves a JavaScript SPA that provides a service and is intended to interact via REST APIs with one of our servers. Initially, I proposed to work on the two entities as two separate projects; specifically I put forth the following

• The user accesses the Web app through a www.myservice.org address
• The Web app contacts an api.myservice.org service for REST interactions

but I was immediately faced with rejection. I was told that the Web app, residing at www.myservice.org, should contact the REST server via something like www.myservice.org/api because doing otherwise would entail a security threat. I didn't say this was a bad idea, but I insisted on splitting the API server from the SPA-serving one for the following reasons

• Scaling
• Separation of concerns
• Easier code management

I'm much more of a developer than a system admin and security expert, so I couldn't promptly reply their rejection. Why would having two api.myservice.org and www.myservice.org servers represent a security issue? I was vaguely told about Cross-site scripting but even then the reasoning wasn't perfectly clear to me.

Answer 1

From the information provided, it is definitely not a security risk. As long as proper controls are set on the API endpoint (HTTPS, HSTS, etc.), you should be good to go.

One thing to note here is that the myservice.org may be running on a hardened system and with additional protections (such as a WAF). In that case, those controls will have to be applied to api.myservice.org as well.

Edit: The argument of XSS is irrelevant here and it cannot happen just because myservice.org and api.myservice.org are decoupled.

Answer 2

It would be more accurate to say that "using two servers e.g. api.myservice.org and www.myservice.org has security implications " --in other words, would normally be blocked by default server CORS config. But there are safe and secure methods to allow this by adjusting those settings.

The alternative of configuring URL paths to point to different hosts also has security implications. Arguably in favor of your proposed method, due to SEO considerations (i.e. you don't want a search engine indexing your JS lib files).

Read more details about "Cross-Origin Resource Sharing (CORS)" at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Answer 3

Only the person behind the rejection could answer definitely why they consider it a security issue. I've found the following questions helpful for such a discussion (not necessarily all of them, since it's likely several of them would be answered by a single question):

1. Which type of security issue is this? “XSS” is not enough of an answer, since it's not obvious why that would be the case.
2. Is this mandated by someone or something such as regulations or a stakeholder? If all the other services the organisation maintains work the same way it could be considered unnecessary complexity.
3. Do you have a reference? Security-related articles are often written by people who have worked a lifetime with security, compared to someone who may have read and agreed with the article but can't necessarily justify their position as clearly. Of course, just because someone at some point considered it a problem, someone still has to verify whether it's actually relevant for you and whether the trade-offs are worth it. As a quick counterpoint (although of course absence of evidence is not evidence of absence), the OWASP Top Ten doesn't seem to explicitly mention subdomains as being a problem in their XSS or CSP articles.

Answer 4

You could have issues if, for example, the API and SPA rely on the same cookie credentials and you don't fully control the closest common higher-level domain. You would have to set cookies on that higher-level domain, which could let attackers steal them if they gain access to a different sub-domain. Not a great situation in the first place, but one that would make me consider using a single (sub-)domain.

This is just an example (and a fairly easy problem to avoid), but you should ask the person crying "security" to come up with a justification, because it might be justified. The devil is in the details, and there aren't enough of them here for a confident "no problem" IMHO.

You can use different servers and code-bases for the API even if it is simply under a different path on the same domain.

Answer 5

A server needs to provide the special header to allow requests like you describe, as they violate the same origin policy (Access-Control-Allow-Origin). This header turns off some security checks and may be seen as unwanted when used without the real need. Assuming they know that they are talking about, this is probably what do they want to say.

It is still possible to do this securely but may be tempting just to put the star ("allow any") as the value for this header, so that always works and does not need any maintenance later.

Instead, I would recommend to isolate the API server from the public internet and use something like NGINX proxy pass to forward API requests to your dedicated API server box or Docker image. This brings up all your listed benefits and should also keep your reviewer happy.

Answer 6

Since other answers have elaborated on the security impacts if the Web app and API service use separate domain/subdomain, I am just going to elaborate on the comment PhilippNagel has posted on your answer, which I would like to paraphrase as separate subdomains and separate servers are two different matters!

The Web and the API can have multiple permutations:

1. same server and same subdomain
2. same server but separate subdomains
3. separate servers and separate subdomains
4. separate servers but same subdomains

Your security team is just concerned on the Web and API having separate subdomains and insist on them sharing the same subdomain as quoted "should contact the REST server via something like www.myservice.org/api" while you are insisting on having them on separate servers, so why don't you fulfill both requirements by choosing the 4th permutation above? It would be then be a win-win situation.

Regarding on how to do that, since your Web app is just a Javascript SPA, its server is just running a web server application (e.g. Apache, NGINX etc) that serves the app files. You can configure that web server application to have /api path proxied to your API server that you don't even have to directly exposed to the public (like you mentioned in one of your comments on other answers) as long as it can be reachable by the server for the Web app.