Restricting API usage with the API Manager

 

I think my question is simple: What's to stop Joe User, or even Joe Subscriber, from circumventing the apikey requirement and hammer away at my api with impunity?

By @AndyPetersonCFUGMgr

That is an important question. It is at the core of API architecture and security.

In short, the answer is: nothing will stop Joe User, or even Joe Subscriber, from circumventing the API Key requirement and hammering away at your API. That is because the API Manager does not magically protect an endpoint that is still publicly reachable. The API Manager is a gatekeeper, but a gatekeeper only makes sense if you lock the back door.

The solution? Separation-of-concerns (SoC). 

By SoC I mean, use 2 separate layers:

• an API Gateway (with public access), and
• an API Backend (with private access restricted to the Gateway).

BKBK_0-1769366923581.png

This is a so-called Proxy Architecture. It entails moving, hiding, or blocking direct access to the original API endpoints.

Ensure that the Gateway (that is, the API Manager):

• has a URI distinct from that of the Backend. For example, 
  

  https://gateway.mysite.com/rest/api/v1/customers/12345

• is the only public entry point.
• authenticates the user and sets up everything required for the API request
  (by requiring an API Key - usually the x-api-key header, inspecting the key, checking the SLA, tracking rate limits, and so on).
• rejects a request with no key or with an invalid key.
• acts as a proxy for every authenticated user (passing the request through to the Backend, on behalf of the user, and receiving the response).

The Backend:

• is where your API code actually lives.
• has a URI distinct from that of the Gateway. This is the "back door". For example,
  

  https://api.mysite.com/rest/api/v1/customers/12345​

• only accepts and processes requests received exclusively from the Gateway.

Some caveats, the sources of common mistakes. Note that the Gateway / API Manager does not have responsibility for:

• rewriting any DNS automatically.
• blocking direct access to the Backend.
• injecting authentication information into a publicly accessible endpoint at the Backend.

To prevent Joe User from circumventing the API Manager, you must ensure that your Backend server only accepts requests coming from the API Manager. There are three common ways to do this:

1.  IP Whitelisting (using a Firewall).
   Configure your web server (IIS, Apache, or Nginx) or your Cloud Firewall to reject any traffic to api.mysite.com unless it originates from the IP address of the Gateway.
2.  Shared Secret Header (using a hidden key).
   Configure the API Manager to inject a "secret" header into every request it passes to the Backend (for examplr, X-Internal-Secret: some-long-GUID). Then, in your ColdFusion code (or via a servlet filter), check for the existence of that header.
3.  Private Networking (the Virtual Private Cloud - or VPC - method).
   In a cloud environment, place your API Backend in a Private Subnet with no public IP address. The API Manager sits in a Public Subnet. The only way to reach the Backend is through the API Manager over the internal network.