Believe it or not, security can still be an afterthought when companies expose back end services to internal and third party developers driving digital innovation. This can be especially true when your focus is away from your base API infrastructure.  But make no mistake: a robust API Gateway is critical to reduce security risksJava-based API Gateways offer a false sense of security on the cheap, a fact that API developers and project leads don’t often grasp until it’s too late. A well planned API security strategy, built off a purpose-built gateway, is what keeps the bad guys/gals at bay. Read on for another installment in our Blog Series: Top 8 API Management Considerations for Winning Digital Strategies.

Your APIs expose valuable back end services and applications.  An API Gateway acts as a shock absorber to your back-end systems to ensure your business continues to run even while your front end services face high workloads. If your gateway is compromised, hackers get access to core business data and applications, and can overload your back end systems, leading to an unplanned outage.

With this in mind, your gateway needs to be purpose-built to be secure, robust, and performant.  That’s why the technology beneath your API Gateway is critical to your API strategy, and why Java , optimized for business logic, doesn’t cut it as a gateway solution.

Java isn’t designed for the DMZ:

Java is a great application language, in use by thousands of companies to power internal and external facing applications. However, Java isn’t meant to be deployed in the DMZ. The DMZ is outside of your corporate firewall and open to the public Internet. Hackers often attempt to gain control of software deployed in the DMZ using known (unpatched) or unknown vulnerabilities.  As you can see here, Java requires frequent patching, with around 500 vulnerabilities identified to this date.

Not that Java isn’t secure. Thousands of IBM WebSphere customers are safely using Java to run their businesses.  However, very few vendors would recommend running Java applications in the DMZ.  Use a proxy server or Web server to receive the public request and forward it to a Java application residing within your internal network.

Java-based API Gateways introduce security risks:

You tell yourself: “I’m only interested in the API economy, API management or API Gateways.  Why are you telling me about Java and the DMZ?”   The answer is simple:  everything you learned about the risks of running Java applications in the DMZ is 100% applicable to your API strategy if you decide to use a Java-based API Gateway.  Why? Because for APIs consumed by mobile, web, or partner applications, API Gateways are always deployed in the DMZ!

Oh, and your API Management vendor likely won’t advertise that their API Gateway is simply a Java application!  You must ask, or see if it pre-reqs a JDK (Java Development Kit) or JRE (Java Runtime Environment).  For instance, MuleSoft’s API Gateway is just a Java app, and therefore open to security vulnerabilities not just in the Java gateway code that MuleSoft wrote, but also in the JDK code that Oracle wrote.

But perhaps you think that this doesn’t apply to you.  Maybe your use case is only internally-facing, or you think that you can structure your networks to secure yourself without a purpose-built gateway.  It doesn’t matter: in both cases you remain vulnerable to fundamental Java security flaws.

Myth: “But this is just an internal API project!”

I hear this response from customers, and I assume it comes from a competitor with a Java-based API Gateway. Well, as often happens in IT, what you thought was going to be internal can quickly become an internal- and external-facing API.  So if your strategy is to ignore the security risk because your project is only dealing with internal APIs, what will you do when the project grows in scope?  All IT projects face some degree of scope creep.  Will you have time to migrate away from a Java-based API Gateway like MuleSoft and adopt a secure API management platform like API Connect? Use your time more effectively from the beginning with IBM API Connect!

Also, consider that you likely already (or soon will) plan to expose API’s outside your firewall.  It’s inevitable.  You definitely don’t want to manage two separate technologies (read: tools, skills, processes, licenses) for internal and external API’s.  Why would you go through that complexity just to enable yourself to use a less secure technology inside your firewall?

Myth: “I’ll just put an Edge Gateway or Proxy in front of my Java-based API Gateway!”

I’ve also heard this response from customers.  In several cases the customer uses IBM DataPower as the edge gateway in front of a Java-based API Gateway. But why sacrifice the performance of your APIs by introducing an extra network hop from the public Internet, to the Edge Gateway, and then to your API Gateway?  Clients expect millions to billions of API calls per month, and this extra network hop lowers performance, resulting in more waiting by users and extra costs on you to support two gateways.

So, how do you achieve a secure API strategy?

Answer: Use a purpose-built API Gateway

The API Connect Enterprise Gateway is a purpose-built API Gateway available in your preferred form factor.  It comes as a hardware appliance, a virtual software appliance, a Docker image, and a Linux installable. With the IBM API Connect Enterprise Gateway, you get these 3 security benefits:

  • A single self-contained, signed & encrypted secure gateway image without external software dependencies 
  • Minimized security exposure due to a smaller vulnerability surface (few user-exposed and 3rd party components)
  • A high assurance, “locked-down” configuration

Further, the IBM API Enterprise Gateway benefits from IBM’s secure software engineering process.  This holistic approach to software development mitigates sources of risk in development, deployment and maintenance in all IBM products.  As a result, our API Gateway minimizes vulnerability for customers, from initial design of the product to end user behavior.

Which of these two Gateways in the picture below would you trust your API program to? If you said IBM DataPower, you’re in good company with thousands of enterprise and government clients with stringent security requirements!


A common misunderstanding is that DataPower is only a hardware appliance. On the contrary, the security benefits of DataPower apply to all form factors!

Implement a non-Java based, purpose-built API Gateway to reduce the risk of your API projects being hacked.  Forrester, IDC, and Gartner all agree that IBM API Connect’s enterprise API Gateway, based on IBM DataPower, is both the market leader and more secure option.

 

Try IBM API Connect

Don’t take our word for it, use IBM API Connect for free and compare for yourself.

Talk to Us

Want to learn more about API Management or IBM API Connect? Contact us and our team will be in touch.

 

2 comments on"Secure your API Strategy"

  1. Very interesting article Zach!

  2. ManojkumarPhate July 14, 2017

    Really Good Article Zach 🙂

Join The Discussion

Your email address will not be published. Required fields are marked *