Best practices reveal how to shore up the connective tissue of a website

An application programming interfaces (API) is the connective tissue of scalable websites—indispensable for functioning in a digital world. But, as in the physical world, weaknesses in those connections can cause serious, sometimes existential, trouble.

One recent example is data leaks resulting from misconfiguration of Microsoft Power Apps portals to allow public access. According to UpGuard, “the types of data varied between portals, including personal information used for COVID-19 contact tracing, COVID-19 vaccination appointments, Social Security numbers for job applicants, employee IDs, and millions of names and email addresses.”

But the operators of those portals have lots of company; API misconfigurations and the attacks they attract are more common than you’d expect. Indeed, Salt Security reported earlier this year that of nearly 200 enterprise security officials they surveyed, 94% said their organization had experienced an API security incident in 2020. The report also highlighted malicious API traffic had increased 348% over six months, an indication of how attackers are focusing their attention on data access.

And at the end of 2019, OWASP started a separate “OWASP API Security Top 10” covering API weaknesses. APIs represent a ready method to access data exposed by an organization. Some APIs are intended for public use, while others are intended for use within an application. Regardless of their usage, an API is designed to provide direct access to data and as such should be explicitly tested to ensure it doesn’t return excess data or that authorization bypasses are possible. In the BSIMM12, activity ST2.6 covers fuzz testing of APIs, but only 12% of organizations were found to be performing this activity.

In an effort to change that narrative for the better, here are 5 best practices for API monitoring and protection.

1. Inventory and documentation

A security cliché (because it’s true) is “you can’t protect what you don’t know you have.” And that is the problem with far too many APIs. A lot of code may not be formally documented in a way either humans or machines can consume, so it may not get tested.

To address this:

• Build an inventory of API-based application assets
• Prioritize them by risk level
• Find API endpoints for those assets
• Track automated deployments to maintain your API inventory
• Automate detection of issues with security tools and services

Additionally, identity and access management (IAM) is a standard security practice. But for APIs, it should focus on how users are authenticating to the API and how the API is authorizing each user at different points. And there are many ways to go about that. The key is to track a user through the system. Each function within the app needs to be designed with an understanding of its responsibilities for authenticating or authorizing the user.

2. Data Trust

Consider how your APIs validate the request data they receive from the data consumer, and whether it is malformed. If so, how is the request data being validated?

Just like with web applications, APIs must conduct input validation. When your application uses public APIs, an attacker may try to modify the underlying data within the API meaning that the API needs to know what to do with malformed data. But the way validation is done might be a little different—not only the values of parameters need to be checked, but API data often is part of a data schema meaning that each parameter might have meaning relative to the remainder of the data and thus validation needs to be done at the data level and not just the parameter level.

3. Cryptography

This should go without saying, but it is critically important to ensure data at rest and in transit are encrypted in a secure manner as and when needed. This includes implementing expiration semantics for items like the JSON Web Tokens that are frequently used for AuthN/AuthZ. But this also includes validating the various cryptographic signatures and certificates used during authorization and by message encapsulation protocols.

4. Configuration

If you are deploying your API in a cloud environment or with containers, make sure that those are configured securely so as not to weaken or even undo all the hard work put into securing the API.

API misconfiguration is API7:2019 on the OWASP API Top 10. It can include unpatched systems, unprotected files and directories, unhardened images, missing, outdated, or misconfigured TLS, exposed storage or server management panels, missing CORS policy or security headers, error messages with stack traces, and unnecessary features enabled.

5. Active monitoring/alerting

This requires several key areas of focus. They include:

• Examining the content: Perform application layer scanning to look for someone trying to use SQL injection. Be sure you have a clear understanding of how you are examining traffic coming into your API, and what you are doing with that traffic.
• Bot/attack detection: Ensure that you have controls in place or built into your APIs to protect against known attack techniques and heavily automated attacks conducted by bots.
• Data throttling: Determine how you will limit API usage and what you will do when usage has exceeded your limits.
• Logging: Build a tactical auditing procedure. You should be auditing logs and getting meaningful alerts that give you what you actually need.
• Tracing: The ability to trace any negative findings or activities back to their source—a development team or application—is particularly valuable. Without it, you are not setting yourself up for success.

By applying these concepts, your organization will be better equipped to understand how APIs impact various elements of a piece of software. They will ensure that security is built into software, exposing or consuming APIs at the right place and the right time.