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

Information Security Asked by Acsor on December 24, 2020

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 address
  • The Web app contacts an service for REST interactions

but I was immediately faced with rejection. I was told that the Web app, residing at, should contact the REST server via something like 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 and servers represent a security issue? I was vaguely told about Cross-site scripting but even then the reasoning wasn’t perfectly clear to me.

6 Answers

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 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 as well.

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

Correct answer by Sachin S Kamath on December 24, 2020

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" 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.

Answered by Lukman on December 24, 2020

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.

Answered by h22 on December 24, 2020

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.

Answered by l0b0 on December 24, 2020

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.

Answered by Jacob Raihle on December 24, 2020

It would be more accurate to say that "using two servers e.g. and 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

Answered by MarkHu on December 24, 2020

Add your own answers!

Related Questions

Jenkins malicious process identification

2  Asked on October 28, 2021 by nemanja-martinovic


Does encrypted content in a database need to be signed?

1  Asked on October 28, 2021 by ian-warburton


WhatsApp account got “hacked”/hijacked?

1  Asked on October 28, 2021 by d-a-vorm


iCloud deletion

1  Asked on October 28, 2021 by mp115


Difference between Zeek (Bro) and Snort 3

2  Asked on October 28, 2021 by ustavsaat


Help Understanding PHP Reverse Shells

1  Asked on October 28, 2021 by pdawg


Refresh token using a separate auth server?

0  Asked on October 28, 2021


Is the perfect MITM attack possible?

1  Asked on October 28, 2021 by user238715


What attack vectors does arbitrary JS on a user profile allow?

2  Asked on October 28, 2021 by sellarafaeli


Processing Exceptionally High Volume Singular Flows

1  Asked on March 9, 2021 by reedghost


Ask a Question

Get help from others!

© 2023 All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP