Modern cloud strategies make heavy use of APIs for controlled, interactive access to hosted services. But the access is only controlled if the APIs are securely implemented and they're not susceptible to abuse.

Web APIs

An application programming interface (API) lets software talk to other software. That requires a set of specifications. There must be a documented set of functions that the API endpoint provides and rules about what the API client must do to use those functions. The type and format of the data returned by the API must be defined for each function. You usually want to restrict who has access to the API, so API clients must authenticate in some way. In a restricted API, requests must only be serviced when the API endpoint has verified the request is legitimate.

As with all software development, a security-by-design methodology is far better than a build it first, secure it later approach. The Peloton API disaster illustrates this perfectly. A flawed API implementation---which is now fixed---allowed unauthenticated API calls to be serviced.

Anybody could pull back personal data about any Peloton customer. The first "fix" simply restricted the API to Peloton owners. This was only marginally better. With the final fix in place, a Peloton user's data is finally private, unless they explicitly choose to share it.

There are many other examples of weak or poorly designed APIs. Facebook exposed the personal data of 533 million of its users because an API allowed anyone to search a database using telephone numbers---at a rate of up to 1000 per minute.

Over 80 percent of all internet traffic is API traffic. That's a lot of APIs. As of mid-2021, the Open Web Application Security Project (OWASP) top 10 security risks haven't changed in several years. Sadly, the same mistakes leading to the same vulnerabilities are being repeated over and over. And that's too enticing for cybercriminals to ignore.

Development Stakeholders

APIs are often less well protected than websites and mobile apps. Performance requirements can force the development team to focus on making them lean and mean. So lean that they contain very little ---if any---code devoted to protecting the API and the data they safeguard. A poorly designed or badly implemented API will have weaknesses that can be exploited. The proper remediation isn't to stick a Band-Aid over it and try to plug the holes. You need to fix the code, or possibly the business logic that was modeled into the API.

When you have many software components talking to one another over API calls---such as microservices---it becomes very difficult to spot business layer process errors. Your code may pass the unit, regression, and other tests. You may experience no crashes. All your logs are clean. But that doesn't mean the logic is correct, nor that all possible vulnerabilities have been considered. Bringing your security team and your development team together can yield surprising insights.

The development team is responsible for writing the APIs that deliver the required functionality. The security team is responsible for protecting the data that is being serviced via the API. They're both stakeholders in the success of the development process. Developers are never going to think about security, threats, and attacks like the security team. Why not bring both sets of expertise to bear on the problem?

Types of Attacks

The common attack types you'll encounter can be grouped according to their attack technique.

• Credential Stuffing: This is similar to password brute-force attacks, but it uses API credentials instead of user account passwords.
• Injection Attacks: In an injection attack the cybercriminal adds computer instructions to their API requests in such a way that the embedded instructions act upon the API endpoint. SQL injection is an attack that exploits SQL databases. Often it is easy to work out which text elements in an API call are going to be included in SQL statements. Appending SQL statements to those API function calls can lead to those snippets of SQL being acted on by the API endpoint SQL servers. Cross-site scripting is a similar attack where the embedded instructions are in a scripting language, typically JavaScript.
• Distributed Denial-of-Service (DDoS): These attacks are very similar to the DDoS attacks that flood a website with traffic, preventing it from servicing genuine requests. DDoS attacks aimed at API endpoints are growing in popularity with threat actors.
• Man-in-the-Middle (MitM) These attacks rely on the interception of traffic between a genuine, innocent API client and the API endpoint. If API authentication credentials are captured they can be used to reconnect by masquerading as the genuine API client. Sometimes the API calls made from the genuine client are modified so that the API endpoint does what the attackers want, not what the actual client wants.

Protecting Your APIs

When you're looking to secure a subset of your IT infrastructure, It can be tempting to look for specific or novel solutions. But don't forget the cybersecurity basics.

Quantify What You're Dealing With

If you don't know what you've got, you can't manage it. You must identify and characterize all of the APIs that you use, whether you've created them or not. The results of your API audit might reveal opportunities to simplify or rationalize your use of APIs. It will also highlight any aged or orphaned APIs that need to be updated or turned off.

Once you know what APIs you have, what they do, and how they're protected and made resilient, you can document your API security strategy. Use the opportunity to set ground rules for security-driven development, and plan your API roadmap.

What data is accessible through the API calls? Is it personally identifiable information, or sensitive in some other way? What is its data classification? If your data protection policies have been implemented correctly they'll already contain this information. Critically review the access to the data. Are you revealing more data than necessary?

Make Your APIs Concise

Wanting to make your API a rich experience for the data consumer can lead to over-reporting and needlessly giving away details of the API endpoint itself. Information about data subjects, encryption keys, and authentication tokens have all been leaked by overly-verbose APIs. A more considered and secure approach is to return the minimum amount of data that the API client needs to fulfill the requested function.

This circles back to the principle of least permission, a cybersecurity staple. You should only grant users, processes, IoT devices, or anything else that interacts with your IT the minimum privileges required for their role or function to be fulfilled. Do the same with your APIs.

Use Encryption

Encrypt your API traffic using TSL, the successor to SSL. Don't be guided by the value of the data. Remember, you're also protecting API client authentication tokens. Attackers might not care about the data. But, if they acquire authentication tokens they may be able to use the API to extract more clues about your systems so that they can mount different attacks.

Authentication and Input Values

Obviously, you need to have a strong authentication system. Don't reinvent the wheel. Whenever possible, use a recognized solution such as OAuth2.0. You might feel that internal APIs don't need to authenticate. But can you guarantee that an internal API won't be made public in error, perhaps because it is being reused in another project?

Never blindly accept input from an API without validating it first. Scan it for malformed content, embedded scripts, and overrun attacks.

Be aware of the frequency of connection requests, and apply sensible rate-limiting measures. Is a high-frequency visitor someone trying to brute-force their way in, or are they trying to siphon data out of your database, request by request?

Allied Technologies

Web application firewalls (WAFs) help protect websites, hosted applications, and APIs by filtering and monitoring traffic to and from the protected resource. They can detect attacks such as cross-site scripting and SQL injection, among others. A WAF is an application-layer protection technology, (level 7 in the ISO model), not a fit-and-forget solution to all of your website or API security. They are best deployed as one element in a layered suite of defenses.

An API gateway sits between the API endpoint and the API clients. They broker API requests between the clients and the API endpoint, sometimes breaking a request into smaller pieces that are serviced by different back-end microservices. responses are collated and sent back to the API client. API gateways can integrate with, or provide, authentication and rate-limiting facilities. Software-as-a-Service API gateways are available, providing high availability and automatic scaling.

APIs are on the Front Line

With the relentless rise of cloud and microservices, APIs find themselves on the front line of cyberattacks. Cybercriminals like odds when they're stacked in their favor. with so many APIs out there, it's inevitable that many of them will be poorly protected or even unprotected. Don't let them be yours.