securities concerns about calling REST API from multiple servers

Question

There is a master web application that needs to call REST APIs from servers of other applications. I can think of two ways to achieve it:

a). call APIs on the front-end of the master application(javascript)

// javascript code of master application
$.ajax(api_server1_url,{
  ...
})

b). call APIs on the server of the master application

// backend code of master application
call_api(api_server1_url)

Both a and b return json result for further user in master application.

If I have the access to the code and servers of all the applications mentioned above, is option a or option b a better practice security-wise?

very new to the security, but I'll list what I know(not much..): a has cross-site-scripting vulnerability. I think it's possible to eliminate or limit it by changing code on API applications, but it will take effort.

That's why I prefer option b. Though code on API servers still need to updated to prevent attack, but it should be easier than option a. Only allow the ip of master application to access the API servers should be sufficient.

So my question is:

Is my assumption about b is better a right? If not, what security measurement do I need to implement on API servers?

Thanks for any input.

Answer 1

Question Restatement:

In application architecture, what is the most secure way way to delegate calls between Javascript APIs:

1. To allow the end-client to call the hosting API directly; or
2. To delegate the end-client's call through a front end-server.

Possible Context: This concern could be most applicable to Node.js where application logic is implemented via Javascript -- otherwise, I am still not certain I understand the question correctly ... :

Quick Answers:

Here are some links about securing REST APIs, hopefully to help focus the question a little -- but I am not certain if this is the question:

• OWASP Security Cheat Sheet
• https://stackoverflow.com/questions/7238094/securing-rest-api-without-reinventing-the-wheel
• https://securityledger.com/2015/08/the-challenge-of-securing-rest-apis/

Answers - Multi-Tiered Architecture is Not Security:

Application Architecture is very different from "Secure Application Development".

No matter how you architect / structure / partition the functionality -- it will not secure the application -- but only allow the basic framework so you CAN secure it.

In your question, you are actually discussing "Multi-Tiered Architecture".

And, if not architected correctly -- you do preclude yourself from being able to secure the application.

These are the main principles of Multi-Tiered Application Architecture, that I think you are referring to:

1. Loosely Couple the Client and Presentation Logic to underlying Business and Integration Logic -- Decoupling completely from all Data Logic.
2. Loosely couple the Integration Logic, (B2B interfaces, etc), to Business Logic -- completely decoupled from Data Logic.
3. Loosely Couple the Business to Data Logic.
4. Never allow access from one tier, to the tier above -- only down ONE tier, (Presentation to Business, and Business access to Data, but not Presentation directly to Data, nor Integration directly to Data, but Integration to Business is fine.

However -- even when properly implemented -- you must secure the interfaces between each tier, otherwise -- it is just as vulnerable as if everything was running on the client.

Answer 2

I would argue B is objectively more secure given a certain context. Specifically, if the third-party API requires a login or API key, the client (browser) should not have access to that information.