Cyber attacks are increasing at an alarming rate and like any other piece of software, APIs can also be compromised by these hack attacks. Since we 
use APIs to integrate our applications with third-parties, and APIs expose valuable back end services and applications, the applications can also come under security threats. 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.
Whenever we’re concerned about securing the API and we need to send and receive messages over a secure network connection, we might use a secure HTTPS connection rather than an insecure HTTP one. It’s not limited only to HTTP and HTTPS, but we might be sending data over other protocols as well such as POP(S), IMAP(S), SMTP(S), LDAP(S), XMPP(S), etc.
Remember to use the secure version of the protocol when you want to encrypt the data you’re sending out on the Internet. Only the sender and recipient should be able to read the message in cleartext. Over here, we have outlined some common API security issues that you need to be careful about:
Bad Programming
As an API developer,if you take shortcuts by hardcoding passwords, optimizing code prematurely or use poor logging practice, your API(s) might get exposed to serious vulnerabilities. Problems can arise from multiple errors like missing jailbreak detection, absence of type checking, memory overflow, incorrect error handling and even the choice of wrong language to coding. Architects and developers need to take time out to properly know how APIs are meant to work with integrated applications and how customers would use them.
Insufficient security at endpoints
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.
A good way to start is to prevent connections to the API application from anything except valid client addresses, e.g your angularjs server. Additional security would be gained by implementing a revocable shared API key between each instance and your API, so you can revoke permissions from compromised instances. Also, it’s good to confirm your traffic between the front-end app and the API server is encrypted, even if it’s only on your internal network.
Lacking transport layer security
Transport Layer Security (TLS) is a protocol that provides privacy and data integrity between two communicating applications. The 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-haves’ in a secure API.
Use both SSL and TLS in your APIs…they are neither too pricey nor too complicated, and they go a long way in removing basic API vulnerabilities. It’s the most widely deployed security protocol used today, and is used for Web browsers and other applications that require data to be securely exchanged over a network, such as VPN connections, instant messaging, VOIP and file transfers.
Using SOAP and XML 
The main problem with SOAP is that it’s been around for too long. It’s also based on a complex data layer, XML. Taken together, it is a complex stack mired by numerous attack vectors including encryption issues, external entity attacks (XXE), and denial of service etc.
So make sure you don’t overlook SOAP when auditing your security. Search for vulnerable endpoints throughout your stack and advise on how to patch them or you may also want to consider REST/JSON as an alternative. Over the last few years REST/JSON has prevailed over more complicated SOAP/XML except legacy systems.
Weak validation and Authentication
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.
Many APIs do not set any specific password complexity rules, do not track the API metrics, or allow repeat session ID tokens. If any suspicious activity is detected, find out the reasons behind it. 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.
After the development of the API, we have to properly test it. Since API is most often built on HTTP(S) there are also standard web application threats lurking in the background. We should also do a penetration test on a regular basis to minimize the number of bugs still residing in our code. In the end, it all depends on how the code is written, but we have a standard principle of never trusting the users data that still applies. To build a safer API, we might even apply SDLC (Secure Development Life Cycle) into the development process.
