Providing internet access to my self hosted web api on an internal network. A security threat?

Question

Firstly, I'm relatively new to Web API / CORS and security implementation.

This question is specifically with regards to security. The Web API houses extremely sensitive data and provides clients with the ability to execute transactions online.

The context :

• I have a Web API self hosted as a windows service with a fixed port.
• The Web API is sitting behind a firewall / DMZ on an internal network.
• The Web API (using CORS) only allows traffic from the external server.
• The external server hosts our web site using IIS.
• The Web API is making use of Token authentication (bound to client IP to avoid hi-jacking).
• Both the external website and internal Web API force the use of SSL.

The problem :

The web page makes ajax calls via javascript to the Web API. However, the Web API is not directly exposed to the internet.

• What would the security impact be on having the below setup?
• What sort of vulnerabilities would I be exposing my network too by doing so.
• Is there a better way of implementing such a setup!?

Eg

• User enters https://test.mydomain.com into the browser and is served a page.

• ajax call gets made to https://test.mydomain.com/api/test/action

• external server routes https://test.mydomain.com/api messages to internal server https://myInternalWebAPI/api/test/action which is not exposed to the public.

Answer 1

So this requires a little bit of leg work, but it's implemented into a production environment so I thought I'd share the solution.

I created a WCF service and a WebAPI.

The primary WCF Service resides on the internal network and contains all the business logic, database connectivity. The proxy WebAPI mimics the WCF service structure and is exposed to the public.

The proxy WebAPI is called from the client (javascript), the proxy WebAPI then calls the internal server hosting the WCF service and voila, victory.