5 bad practices that lead to insecure APIs in cloud computing

1. Unwanted exposure

A good API offers relevant functionality and end-user feedback, either when something goes awry or works as expected. An end user doesn't see what happens in the background. All inputs are supplied on the front end, via the GUI.

For example, PayPal's Identity API enables customers to access websites via their PayPal account. End users interact with the login fields, but the API silently does the heavy lifting to authorize and fetch account information.

An exposure might offer accidental insight into how this process works, what causes errors and how the back end works to achieve its goals. In other words, the API's technical workings are on display. While API documentation does provide deep insight here, some things shouldn't be publicized. Nefarious actors can harness information, such as business logic, API structure or syntax and endpoints, and launch an attack.

Similarly, exposures aren't just on the technical end. Poorly coded APIs can grant unwanted visibility or access to protected data -- which invites breaches. These events are costly, betray user trust and open infrastructure to further issues.

Key takeaway: Always be sure to safeguard application data. Similarly, design any error code messages or feedback with a contextual focus -- without sensitive insights into API architecture. Also, do not publicize header responses to end users.

2. Half-baked access controls

IT teams need to ensure that only the right individuals access protected information. Additionally, all protected services must verify that users are who they say they are. Many APIs fail to validate user inputs appropriately, which can create cross-system vulnerabilities.

APIs provide access to user data from other sources and use applications as gateways to this information. Unfortunately, half-baked authentication and authorization protocols can promote data oversharing.

For example, say you're buying something from an online store that has an integrated third-party payments option. End users might appreciate this option, since they can rely on existing payment services and credentials without handing sensitive information to the merchant. Ideally, the payments API will not share any credentials or payment information with that online store. However, poorly coded and implemented APIs can accidentally leak credentials to unwanted recipients.

Key takeaway: Use APIs that implement some sort of token system, notably OAuth 2.0. This facilitates controlled access to external data without spilling the metaphorical beans. APIs are fantastic resources; however, some data must be siloed to remain secure.

3. Substandard encryption

There are two types of data: data in motion and data at rest. Some APIs leave data unprotected during transport, which happens when an HTTP request is made. The API goes out and retrieves information from the database -- point A -- and sends it to the destination service -- point B.

What if there's a man in the middle? Some developers fail to realize that not all data pathways are secure. Others implement outdated protocols or weak shields that don't ward off hacking attempts.

Data at rest commonly resides within databases. APIs connect directly to these databases, which is why poor encryption is so problematic. When encryption is nonexistent or even substandard, sensitive data such as personal records, credentials and payment information remains vulnerable. These APIs might not even comply with mandated standards, such as HIPAA, Sarbanes-Oxley Act and PCI DSS.

Key takeaway: Favor APIs that support strong encryption, AES 256 or Triple DES is ideal. For data in motion, APIs should use secure sockets layer and transport layer security (TLS). Ensure you use the newest versions, as TLS 1.0 or 1.1 might be insufficient for some applications.

4. Ignoring limits and throttling

A common attack type seen today is a DDoS attack, in which external networks send surges of traffic to a given service. Poorly limited APIs facilitate these attacks, since they allow attackers to flood servers and networks with false requests. This type of attack creates poor performance, service interruptions and service crashes.

Many APIs don't limit how often they may be called or enforce limits that are too high. That means an application is susceptible to endless loops of activity stemming from the API. Naturally, temporarily terminating that API prevents access to core app features, but it also creates a poor user experience.

When a company fails to consider an API's throttling controls, performance degradation becomes a real concern. Users could cripple resource allocation and throughput across your services ecosystem.

Key takeaway: Choose APIs with configurable rate limits and throttling controls. These will dictate how often an API is called, lead to better uptime, boost performance and shield your services from bad actors. Look for multi-level limits that apply to the API, application and the resources themselves. This also ensures greater control over user behavior.

5. Rushing to market

Fundamentally speaking, API developers cannot expect to launch a good product without scrutiny. By cleaning up code and implementing thorough review and testing cycles, IT teams can significantly reduce the amount of bugs that initially accompany a production.

A problem arises when deadlines take precedence over API quality. Developers often have a ton on their plates, and they're expected to output massive amounts of code in many instances. This pressure leads to programming mistakes. Rushing an API product out the door virtually guarantees an insecure API in cloud computing.

A company commonly rushes when it hopes to gain a foothold in the marketplace before its competitors. While an API might be open or free, it can still generate revenue for its creators. The same applies to outside developers, whose inclusion of APIs helps attract users. Developers might not properly test how a given API meshes with their code or determine if baked-in controls offer sufficient data protections.

Key takeaway: Both parties must put an API through its paces. The battle between security and revenue isn't a zero-sum game. In fact, building APIs that are known for being secure can bolster long-term adoption.