Why is API security always somebody else's problem?

Examining the many reasons that API security is being ignored.

OWASP recently updated its list of top 10 security vulnerabilities and, judging by the accompanying assessment, security continues to be a major issue with today’s applications. This is especially true now in the era of APIs, where companies are making their core assets and business processes available for others to integrate in the hope of becoming a crucial (and thus "monetizable") part of an ecosystem. In this era, the risk for intrusion attacks, data theft or just plain-old DOS attacks is evident. The risk might be small, but the consequences enormous. Consider the Playstation Network outage that exposed 77 million user accounts, or the more recent Twitter security breach that exposed more than 250,000 accounts.

Strangely, though, testing for security vulnerabilities and making sure that your application or API can’t be exploited through common security attacks still seems to be something that most development teams either don’t know about or just plainly ignore. At both StarWEST and StarEAST in 2013 (major testing conferences in the U.S.), only three of the more than 70 sessions were focused on security vulnerabilities. An analyst firm I spoke with recently was "baffled" by the lack of attention to API security. Vendors, API providers, and API consumers don’t seem to be putting much effort into this area.

I have a couple of ideas why that is the case:

  1. First up is plain ignorance. "It won’t happen to us" (or "I don’t know what you’re talking about"): The notion that no one would care to attack your application or API, or that the technologies, components or languages you are using aren’t vulnerable to attacks, is just plain wrong.
  2. Early adoption of new and cool technologies. As already stated, far too often development teams don’t care about assessing their code for security vulnerabilities, and of course that goes for developers of new components and frameworks as well. The risk is even higher here; their focus is probably on adding new features and disrupting their landscape, not on making sure that their error messages don’t disclose sensitive information or that their APIs aren't vulnerable to injection attacks.
  3. Security is a vast field, and it means different things to different people. Some think of authentication and authorization, some think of SSL, encryption and signatures – and some think of VPNs, Firewalls and BYOD. Add a never-ending list of standards and acronyms to the mix (WS-Security, SAML, OAuth, SSL, etc.) and the risk is high that only a few of these areas will be pro-actively assessed during the development of your project. Oh, did I leave vulnerabilities and attacks out of that list? There you go…

Also, a number of trends in computing mandate the need for proactive security assessments and know-how:

  1. The general trend to move applications and data to the cloud ultimately puts them in an environment where they are more accessible to others than they were in your private data center – no matter how much firewall and routing configuration is built around them.
  2. Exposing core business data and processes over APIs makes them more accessible both for potential business partners (good!) and hackers (bad!).
  3. Big Data/NoSQL is all about storing as much data as possible – there is the risk that this data could be misused if it ends up in the wrong hands.

Obviously, you need to take security seriously: you are vulnerable to attacks no matter what technology or platform you use. If you are building a new application or API, I recommend that you:

  1. Make sure to add security to your requirements and backlog processes. It deserves to be made visible, just like performance, functionality, usability, etc.
  2. Proactively invest in security know-how and testing at the ground level. Make sure your developers and testers understand common security breaches and how to guard against them, just like they are hopefully aware of common performance pitfalls and how to avoid them.
  3. Test and assess security early in your project and don’t leave it to some single individual at the end right before production.
  4. Continuously monitor your applications for security vulnerabilities using available tools or homegrown solutions – just like you are monitoring performance and functionality (right?). Especially if you are in a fast-moving organization that has embraced DevOps and continuous deployment practices, new components or changes can have unwanted side effects. 
  5. Make use of free tools and resources (like those available at OWASP) to get an overview of relevant vulnerabilities and how to make sure they do not affect you.

As a side note, if you are consuming third-party APIs, an interesting question is how defensive you should be in regard to them being compromised or "compromisable"? For example, what if an attacker manages to inject a malicious script into a third-party solution which returns that script in an API response that you are handling? Should you scan for this yourself? Or what if you are inserting sensitive data into a third-party solution via their APIs – should you proactively encrypt or sign data to "handle" an eventual intrusion on their side? Once again, these are questions that should be proactively assessed, even if your answer to both scenarios is "we'll do nothing."

Ultimately, security is hard, and it requires both time and in-depth technological know-how to master. As such, please don’t make security "Somebody Else’s Problem" - especially since that "Somebody Else" might ultimately be your users or customer if you are compromised. They deserve better, right?

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2013 IDG Communications, Inc.