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.

  • 41
    It sounds like people are throwing around the phrase "... because security." without providing any reasoning or justification. You don't get to do that! Using the word "security" does not free you from needing to explain yourself! I would try to further the discussion about why this is a security issue. Commented Oct 19, 2020 at 14:15
  • 7
    +1 to Mike's comment. From a generic standpoint, their position is utter nonsense. If they have specific concerns they need to articulate them and describe exactly how their proposed alternative solves them.
    – Xander
    Commented Oct 19, 2020 at 17:47
  • 18
    They're trying to work around CORS.
    – identigral
    Commented Oct 19, 2020 at 18:13
  • 15
    Those things aren't mutually exclusive, you can have the SPA at the root of the domain, while the api responds to a directory like /api. The API can still be on a different server, and traffic is directed to either the SPA or the API by a load balancer/reverse proxy. Commented Oct 19, 2020 at 19:38
  • 6
    Who is stating it's a problem for security? Have you asked them why? Being "right" is irrelevant if you don't know what concern you're addressing. While I can't think of one now, there's still a chance there's a valid practical reason for their rejection, if not a valid technical reason (ease of implementing proper security as a factor?).
    – TCooper
    Commented Oct 19, 2020 at 20:59

6 Answers 6


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.


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

  • 5
    Debugging CORS is a gigantic PITA. This is primarily enforced at the browser level and you better make sure to test every platform (all browser types, on desktop and mobile). The way it is implemented should be the same, but not all browsers tell you what is wrong. Heaven forbid your company has its own intranet portal, and you need internal systems to connect to internal systems while dealing with CORS, and the errors don't even go to the users.
    – Nelson
    Commented Oct 21, 2020 at 3:16
  • 1
    I would also add that using the same domain means you are always using first-party cookies, which is a good thing, because you can put harsher restrictions on them.
    – Marandil
    Commented Oct 21, 2020 at 8:14

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.
  • Excellent list. In addition to these, I would ask the person behind the rejection to explain how the OP's proposed design creates a vulnerability, and how an attacker would exploit that vulnerability.
    – mti2935
    Commented Oct 21, 2020 at 21:01

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.


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.

  • I concur. I do not see any need to make the API server public.
    – Acsor
    Commented Oct 21, 2020 at 21:19
  • The header in fact does not “Turn it off” but adds it to the same list as the original domain that served the page came from is on.
    – LvB
    Commented Oct 21, 2020 at 21:49

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.

  • Excellent answer, sir! I was revisiting this after 4 whole years and found this very helpful to build something. Take a virtual cookie 🍪 Commented Mar 12, 2023 at 8:01

You must log in to answer this question.

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