This guest post comes from Mark O’Neill, Vice President, Innovation for API and Identity Management at Axway. Mark was founder and CTO at Vordel, a leader of REST and Web Services Security that was acquired by Axway in 2012. Mark is author of the book Web Services Security and contributing author of Hardening Network Security, both published by McGraw-Hill/Osborne Media. He provides guidance on REST and Web Services Security to Fortune 100 and Global 500 firms and is a frequent speaker at key industry events such as the RSA Security Conference and Oracle Open World.
The explosive growth of social media, cloud computing and mobile devices is making Web APIs the primary interface for technology-driven products and services, and placing more and more attention on the emerging “API economy.” And with 50 percent of B2B collaboration predicted to take place through APIs by 2016, we are only seeing the tip of the iceberg.
While APIs present companies of all sizes with exciting opportunities for finding new customers and generating new revenue streams, they also come with serious security and privacy concerns. We were given a reminder of the dangers when social content management and scheduling service Buffer was recently hacked.
In that case, the damage was limited to a slew of weight-loss spam, but when you look beyond social networking sites and consider the importance of some of the things that could be connected with APIs—such as satellites, vehicles, medical devices and even weapons—the risks are magnified.
So in the hunt for the perfect API, organizations must keep API security and privacy at the top of their list. Here are seven ways organizations can securely manage APIs and reap the benefits of future customer and community engagement.
In theory it may seem that a system can be secure so long as nobody outside of its implementation group is allowed to find out anything about its internal mechanisms, but the reality for APIs is very different.
Simply put, operating on a “need to know” basis and relying on security through obscurity is not a safe or effective approach for enterprise APIs over the long haul. Instead, organizations must assume that if a product or service has an API, it will be examined and analyzed.
Take, for example, the electronic car manufacturer Tesla. Instead of documenting its APIs and following conventional wisdom around API authentication, Tesla decided to roll its own (more on that later), and that resulted in potentially serious flaws in the Tesla Model S car’s API that could allow remote users to trigger actions in the car. Although there was nothing in the API that would result in an accident if someone malicious were to gain access, the lesson for other organizations was clear: if you don’t document your API as part of an API management strategy, someone else will—and their intentions might not be good.
It might sound obvious, but it’s important that organizations clearly, accurately and securely document how their APIs are being used.
By producing an audit trail detailing API use, organizations not only have a forensic trail to investigate API attacks, but can also ensure compliance with industry regulations. This is particularly important for organizations in highly regulated industries such as energy and healthcare. For example, the Health Insurance Portability and Accountability Act (HIPAA) requires healthcare organizations to notify patients if anyone accesses their records. And as APIs are increasingly used for B2B collaboration and information access, an audit trail for APIs will in many cases equal an audit trail for people accessing information.
In addition to its value for regulatory compliance, an audit trail of API usage also provides valuable usage information over time.
Variety is the spice of life, but in the case of API management, it is important not to succumb to “shiny object syndrome” and gravitate toward something simply because it is new. This is particularly true when it comes to SSL.
SSL may seem like an old technology and be seen as “just for the transport layer,” but it works and should always be used to underpin your API’s security when using Web transports. SSL/TLS provides a secure pipe by encrypting data in flight and provides reassurance that the parties are who they say they are by enabling you to check security certificates. New standards like OAuth can certainly complement these capabilities, but should never be viewed as an alternative. Instead, organizations should see SSL as the baseline.
Put it this way: If companies like Amazon and Salesforce.com, which are both managing billions of API interactions per month, only allow API access through SSL, there is no reason for your organization to ever consider looking for an alternative to SSL.
Between SSL, OAuth, OpenID, SAML, HTTP authentication and Web Services Security, there are a lot of authentication schemes available. Given this choice and complexity, it is perhaps understandable that your developers may consider developing their own security techniques. Don’t do it! It’s not only extra work, but it’s also a security pitfall because it is always inadvisable to try to generate your own security schemes.
Yes, it’s tempting to make some slight modifications to established standards because each has its own pros and cons—but remember, security standards exist for a reason and any changes that developers make are made at their own (or your own) risk.
If you bake security into an API, you risk mixing business logic with security logic, which introduces potentially dangerous complexity. For example, mixing business processes and security causes a number of maintenance issues because you will not be able to change security policies without a knock-on effect on business logic. Mixing the two areas can also impact the performance of your network; security processes can be very CPU-intensive and slow everything to a crawl. Instead, organizations should place security on a separate platform that delivers the computing power required and adds an additional layer of protection by reducing the attack surface.
In addition, if you decide to make a change to your security policy—for example, adding an API usage quota—it does not make sense to risk any knock-on effects on your business logic.
While it is natural to focus on new API-specific security and privacy threats, it is important to remember that Web APIs are examples of Web apps, so attacks like cross-site request forgery, cross-site scripting and SQL injections all still need to be recognized and blocked.
To do this, think of APIs as another Web app: That will ensure that you take into account both new and traditional security threats. This mindset will also help when selecting an API management system because it is important that any system you select also includes Web application security. This does not necessarily mean purchasing a separate Web Application Firewall (WAF), it just means ensuring that your security solution is not vulnerable to known Web application attacks.
Pepsi or Coca-Cola? Mac or PC? Dog or cat? People often have strong opinions about their personal preferences, but when it comes to XML and JSON, it is important to not let your own preferences stand in the way as you will ultimately need to validate and protect both.
If you design solutions to apply to only one, you risk letting your own bias narrow security. Instead, you need to assume that your customers and partners will want to do both, and ensure your API security is all encompassing.