Instances of cyber hacks and software attacks are increasing at an alarming rate. In 2015, the year-on-year spike in the total number of ‘zero-day vulnerabilities’ (instances of cyber attacks for which fixes were not yet available) jumped by more than 125%. Like any other piece of software, APIs can also be compromised by these hack attacks. Since APIs serve as channels that expose applications for third-party integration, the applications can also come under security threats. Over here, we have outlined some common API security issues that you need to be careful about:

1. Poor coding

   As an API developer, if you try to take the short way out by following the so-called ‘Just Enough Coding’ route, your API(s) might get exposed to serious vulnerabilities. The risk might not be apparent at first, since the concerned API might be doing okay on the usability and the functionality fronts. However, poor coding standards will not allow proper integration of API(s) with the overall platform/ecosystem. Problems can arise from multiple errors – right from absence of ‘type checking’ (which allows uploading of any file and deployment of the app on the server) and memory overflows, to incorrect error handling methods and even choice of the ‘wrong’ language for coding. You need to take time out to get a hang of how your APIs are meant to work and how customers would use them. That will help you in coding properly. If you rush too much to release your APIs, the latter might suffer.

2. Weak validation

   For ensuring the security of web APIs and clients, validation of concerned SSL certificates is essential. However, developers often make the folly of making this validation process rather half-baked – as a result of which hackers can issue their very own bogus certificates (all that’s required is a working net connection), get random users to validate on these, and access confidential user information (breaking into the the encrypted data transfer process). Malicious API traffic interception and the ‘weak validation’ on fake certificates can deliver API keys, passwords and usernames right in the hands of hackers as well. Set up the data encryption and validation methods based on the sites that the web client will access. For iOS applications, consider ‘key pinning’ to keep things more secure.

3. Uncertainties over enterprise API usage

   While on the topic of API validation, we should mention the risks that enterprise APIs might be subject to as well. In many large-sized companies, the administration fails to track who is using the enterprise APIs, how heavy is their usage, and the reasons they are using the APIs for. As a result, the usage charges remain unverifiable and can also spiral upwards. Since there is limited (or no!) information on the applications and/or the systems that are using the enterprise APIs, changing the API provider (as and when required) becomes a tough ask too.

Note: Many employees tend to access APIs with their enterprise credentials. If these credentials are exposed to unauthorized parties, that can put the API in particular, and the enterprise in general, under serious security clouds. For smart enterprise API management guidelines, click here.

4. Whose responsibility is it, anyway?

   The API provider prepares the initial version of an API, the API Developer extends it with features and functionalities, and implements it, while the API customer uses it to create applications. Now, security should always be the responsibility of the person/team at the lowest level – the API providers or developers. Things like user authorization and authentication, API versioning and dependency management need to be handled by developers. Putting it in another way, adopting developer-centric API security norms is important. API customers can put in additional security layers (SSH, HTTPS, SSL, etc.) – but they are only of use when the developers have ‘securely’ designed the software.

5. The risks of using SOAP/XML

   Make no mistake, most vulnerabilities from the server-side can be easily tracked and fixed in SOAP (Simple Object Access Protocol) APIs. However, the XML data format – which is bundled in with the SOAP protocol – has several ‘soft targets’ for hackers, like Denial of Service (DoS), attacks by external entities, and even problems in XML encryption. The fact that the SOAP protocol remains in production for extended periods due to heavy system dependencies complicates matters further. Unless you are working on a corporate API or a software legacy system, it makes a lot of sense to ditch SOAP/XML in favour of the much simpler JSON/REST (Representational State Transfer) combination. The potential security threats will be much lower.

Note: If you HAVE to work with SOAP APIs, make sure that the API audit prior to release is thorough. All vulnerable endpoints in the stack have to be found, and patches for them created, before the API is made available to customers.

6. Enterprise API misuse

   This can be both intentional and unintentional. Let’s explain this risk with a simplistic use case: Employee A uses the enterprise API for a particular service (say, downloading a picture). Now, Employee B also accesses the API and avails the same service (in our case, downloads the picture which is already the property of the enterprise). Such redundant and repetitive API usage can go on, if not tracked by the company. As a result of such API misuse, many corporate houses end up facing a much higher bill than what they should ideally have to pay. Having an strong API governance setup at the enterprise level is important, and API providers need to monitor the usage of the interfaces constantly as well.

7. Lack of security in the transport layer

   Absence of a Transport Layer Security (TLS) in an API is practically equivalent to handing out open invitations to hackers. Transport layer encryption is one of the most elementary ‘must-have-s’ in a secure API. Unless a TLS is used, risks of the fairly common ‘Man-In-The-Middle’ attacks (where an unauthorized third-party can intercept the transferred data and modify it) remain very high. Use both SSL and TLS in your APIs…they are neither too pricey or too complicated, and they go a long way in removing basic API vulnerabilities.

8. Too much control with customers

   When can you say that your API is 100% secure? That’s right – when it is yet to be accessed and used by a customer. As soon as network requests (API calls) start coming in, the API gets exposed – and if you let customers use your APIs in whatever way they like – a hack attack might be waiting just around the corner. Many APIs do not set any specific password complexity rules, do not track the API metrics, or allow repeat session ID tokens. Remember that while most of the users are genuine, there can always be a handful of miscreants, looking to use your API to illegally usurp user-data and maybe even introduce bugs in the system (the ‘black-hat hackers’). Set limits on concurrent API connections, implement password length/complexity requirements, make re-authentication mandatory for extended usage, and be very careful while analyzing the API usage metrics. If any suspicious activity is detected, find out the reasons behind it.

9. API terms of use not considered important

   Yet another security glitch that often bugs enterprise APIs. The threat stems from two sources: firstly, Final-users are not aware of the terms of service (ToS) of an API – and end up using them for purposes/in systems that they are not allowed to. Data ownership in enterprise APIs is also specified in the terms of usage. Secondly, when customers do not pay attention to the API terms and conditions, they often remain unaware of the quality of service the software is likely to deliver. That, in turn, results in improper data tracking on the customer-side. With APIs growing in importance for businesses worldwide, these visibility issues are going down…but they still present a threat.

10. Insufficient security at endpoints 

    Leading API developers recommend the inclusion of ‘key signing’, ‘hashes’, ‘shared secrets’ and other such common endpoint hardening technologies within the API development cycle. Making changes at a later stage is difficult – since the legacy systems which use the API might suffer performance issues. In case the endpoint hardening is not done during the early phases of API development, it might not get done at all. As a result, the endpoints will remain vulnerable – and any competent hacker will have a field day.

The rapid evolution of the API economy throws up threats of its own. As we move on from basic backend-as-a-service (BaaS), to software-as-a-service (SaaS) and Infrastructure-as-a-Service (IaaS), new technologies, resources and API frameworks are becoming available. While technological advancement is a positive thing per se, using the latest tools without proper training and/or limited understanding of how they work can be counterproductive. The mindsets of API providers have to evolve as well, for optimal use of the new technologies.

The onus is on API developers to list out all possible ‘security holes’ in their software – which can be targeted by attackers. Once that is done, steps can be taken to block out these risks systematically, and make the APIs well and truly secure.