Information Security Asked by Acsor on December 24, 2020
api.myservice.orgservice 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
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
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.
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
api.myservice.org 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:
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.
/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):
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. 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
Answered by MarkHu on December 24, 2020
2 Asked on October 28, 2021 by stone-true
8 Asked on October 28, 2021
2 Asked on October 28, 2021 by kepotx
2 Asked on October 28, 2021 by nemanja-martinovic
2 Asked on October 28, 2021 by tomi-begher
1 Asked on October 28, 2021 by ian-warburton
2 Asked on October 28, 2021 by alehandro
man in the middle session management vpn vulnerability assessment
1 Asked on October 28, 2021 by d-a-vorm
1 Asked on October 28, 2021 by mp115
2 Asked on October 28, 2021 by ustavsaat
1 Asked on October 28, 2021 by pdawg
0 Asked on October 28, 2021
0 Asked on October 28, 2021
1 Asked on October 28, 2021 by user238715
4 Asked on October 28, 2021 by m-vencel
2 Asked on October 28, 2021 by sellarafaeli
3 Asked on October 28, 2021 by nkl
account security data leakage encryption passwords web browser
1 Asked on March 9, 2021 by reedghost
1 Asked on March 3, 2021
Get help from others!
© 2023 AnswerBun.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP