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.

  • 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 '16 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 '16 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 '16 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 '16 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 '16 at 19:25
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?
  • 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 '16 at 17:35
  • I can't really answer that question for you. The thing about javascript is that it executes on the client's computer, out of your control. It can be modified in transit or at the client's computer (including by the client themselves), so you can't trust what it does, and if it can be modified before it gets to the client they can't trust that it will be safe. Those are the things you should be thinking about, in the context of your system. – drewbenn May 10 '16 at 17:47
  • 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 '16 at 18:08
  • SSL isn't a magic bullet; someone could MITM the key exchange, for instance. But that only matters if you care about ensuring that only trusted code reaches the client: it sounds like maybe you don't. Again, you need to think about what can happen at each stage in the process if someone interferes with your code, and you need to think about what it is you're trying to protect. With your edits: if for example you are trying to protect the other APIs and they're already protected against malicious input from untrusted sources, then modifying the JS can't hurt them and you're okay. – drewbenn May 10 '16 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.