0

I have been proposed a solution where our API serves up some JavaScript which will be executed on the client. The code will render some HTML on the client and provide some functionality such as calling other APIs and verifying info entered into the dynamically rendered elements.

In essence it would do everything a programmer would do if they wanted to call this API, we are just providing a pre-packaged version of all that. So the rendered HTML and JavaScript wouldn't be doing anything that we wouldn't be doing on the client anyway.

From an initial walkthrough I can't see anything insecure with this approach so long as the API we are executing the JavaScript from is trusted. are there any major security flaws with this approach?

EDIT

I am not an expert in security, but here is a hopefully better explanation of my concerns.

If a hacker gets into our system, the API is the last thing we are worried about because we have a bunch of other more valuable things he will want. However, if this API which serves dynamic JavaScript makes it any easier for a hacker to get in then that becomes a concern.

Additionally, I have always been skeptical of dynamically executing code, I have been taught under the notion that it is inherently insecure, which is why I am asking this question in the first place. Admittedly I don't see why it is insecure unless the dynamic code is being generated from user input, so my other concern is, are there any inherent security holes in running this dynamic JavaScript so long as it is coming from a trusted source.

By trusted source I simply mean, we are hosting our API at www.myapi.com/some/stuff. So if the client calls the endpoint at that URL we are going to assume that it is a trusted api. Maybe that's bad to do? I don't know I am not a security expert.

Also, we are going to be serving everything over SSL.

Improve this question
6
  • 2
    This seems like horrible design. Load dynamic javascript, rely on it, It doesn't get sent because the server can't be reached and suddenly your web app goes down. Really the script should be there so it can be cached(for speed), and initialized only when needed. Lazy loading of javascript is always a bad idea if you need to rely on it. Lazy loading of static content is fine because if it doesn't show up, the rest of the application can still run.
    – Robert Mennell
    May 10, 2016 at 17:23
  • @RobertMennell thanks for the concern, I also don't like the design but certain people who make much more money than me do. I just want to make sure this design isn't inherently insecure.
    – tt9
    May 10, 2016 at 17:28
  • Then save those certain people a lot of money by telling them what it leads too and let them come ot the conclusion of it's bad design.
    – Robert Mennell
    May 10, 2016 at 17:30
  • @RobertMennell I am having a hard time figuring out who this is horrible design. This is pretty typical usage by companies like Facebook, Microsoft, Twitter, Google, etc with a lot of their APIs. For example: social feeds, maps, and advertising.
    – Bacon Brad
    Jun 9, 2016 at 19:19
  • As long as it doesn't serve private or problematic customer data is a very different concern than buisiness data.
    – Robert Mennell
    Jun 9, 2016 at 19:25

1 Answer 1

Reset to default
1

It's not clear what your threat models are or how you designate any of the nodes in the system as "trusted." Here's a short list of things you should have already considered:

  • What happens if the primary API is compromised (e.g. hacker serves malicious javascript code from the API)?
  • What happens if the connection between the primary API and the client is compromised (e.g. MITM (are you using SSL?) injects malicious javascript code)?
  • What happens when the client's computer is compromised (e.g. client starts hacking around to see what happens) and sends other "locally-verified" commands to the other APIs?
  • What happens when the connection between the client and the other APIs is compromised (probably no different effect than if the client's computer is compromised)? Or the other APIs themselves are compromised?
Improve this answer
2
  • Basically if this api serves JavaScript that is to be dynamically executed, does this api become a weakpoint moreso than our other systems? I assume if a hacker has control of the API he has control of other things we dont want him in that can do more damage. The concern is if this API makes it easier for a hacker to take control, or if there is some way of injecting malicious javascript etc... We are using SSL, and by trusted API I mean we call myapi.com/api/stuff and we assume that URL is good because it's where we are hosting our API.
    – tt9
    May 10, 2016 at 17:35
  • How can the message get modified in transit? Particularily if we are using SSL? Also, if that is the case that would mean the attacker could use if for a malicious purpose right? Like grabbing user info?
    – tt9
    May 10, 2016 at 18:08

You must log in to answer this question.

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