Securing APIs From Left to Right (and Everywhere in Between)

Major data breaches are on the rise, and APIs are increasingly being used to gain access to sensitive data. The reasons for this are twofold: APIs are the first line of defense into an application (and it’s data), and more and more applications are accessible via the cloud and APIs. Everything from non-critical functionality, like music streaming and social media, to extremely critical data, such as financial accounts and healthcare, is accessible 24×7 through APIs.

Why is it so desirable to breach API security? There are many nefarious reasons, but here are just a few:

• Stealing Personally Identifiable Information (PII) and selling it on the dark web or for identity theft
• For asset theft, extortion or ransom
• Causing application instability or unavailability
• Espionage (corporate or political)
• Election interference
• Political instability

The list goes on. The availability of data and the dangers of breaches make it critical to get API security right.

Each year, the Open Worldwide Application Security Project (OWASP) comes up with a list of the Top 10 API Security Risks. We’ll take a quick look at the current list, with examples of data breaches caused by each type of risk.

After that, we’ll talk about the API pipeline and ways to prevent common API security issues across the pipeline.

 

OWASP Top 10 API Security Risks (2023)

Let’s take a look at the OWASP Top 10 API Security Risks, ranked in order of prevalence (from highest to lowest).

 

API1:2023 – Broken Object Level Authorization (BOLA)

In a BOLA attack, object IDs for application data are leaked in API responses and used to gain unauthorized access to sensitive data.

The large Twitter (now X) API breach was a BOLA attack, where an API that could be used to find users ended up leaking PII.

 

API2:2023 – Broken Authentication

With broken authentication, an attacker compromises weak authentication methods and gains access to an application (and ultimately, data).

Many security breaches are caused by broken authentication.

 

API3:2023 – Broken Object Property Level Authorization

This is similar to BOLA, where an attacker is able to gain unauthorized access to data.

 

API4:2023 – Unrestricted Resource Consumption

In this scenario, the attacker is able to get unrestricted access to an application and its resources. This type of attack can cause application instability or even outages. If large amounts of application resources are consumed without restriction, the result could be very costly (e.g. paid-tier cloud resources)

An example of this would be a Denial of Service (or DoS) attack, where an application is so overwhelmed with traffic, it can no longer function.

 

API5:2023 – Broken Function Level Authorization (BFLA)

With BFLA, unauthorized access to application functionality is allowed. This includes authorization issues between microservices.

An insurance company was the victim of a BFLA attack due to customer data being available to the public via a “protected part” of the application.

 

API6:2023 – Unrestricted Access to Sensitive Business Flows

This threat involves vulnerability to automated abuse of application transactions, for example ticket sales or thread comments. For example, “Bad bots” could be used to overwhelm an application and circumvent security.

This happened with the Taylor Swift concert ticket snafu in November 2022. Scalper bots were used to buy limited release tickets for verified fans, which were then sold at a huge profit.

 

API7:2023 – Server Side Request Forgery (SSRF)

Also known as “URL spoofing”, this involves a server using an input URL to a remote resource without validating the given URL, which could allow attackers to get around a VPN or firewall and potentially gain access to sensitive data. The attacker uses the server to make the request appear legitimate.

The huge Capital One data breach in 2019 was an SSRF attack, and resulted in PII for 100 million credit card holders to be stolen. More recently, a class action lawsuit was filed.

 

API8:2023 – Security Misconfiguration

Any weak or misconfigured security in an application opens attack surfaces.

In May 2023, Toyota revealed a big data breach due to insufficient cloud configurations.

 

API9:2023 – Improper Inventory Management

Improper API inventory management includes undocumented (shadow) APIs, deprecated (zombie) APIs and unauthorized (rogue) APIs.

Shadow and zombie APIs are risks because they may not have sufficient security scrutiny. A rogue API can mean the same thing as a shadow API, but it can also be the result of malicious code injection opening up a backdoor into an application.

 

API10:2023 – Unsafe Consumption of APIs

Weak security in 3^rd party APIs used by an application can allow access to data.

An example of this threat is an insecure AWS S3 bucket with access to data, which seems to be responsible for many recent data leaks. Even if the application which hosts the data is very secure, the data could still be accessible through S3 APIs.

 

The API Pipeline

We hear about “pipelines” and “moving towards the left” all the time in software development. But what do these concepts mean in the context of APIs?

The API pipeline spans the entire API lifecycle, from initial development (“on the left”) to deployment into production (“on the right”). This is illustrated below.

 

 

Let’s discuss the various stages of the API pipeline.

 

Development/Coding

APIs are born in development, ideally by first crafting an OpenAPI specification (OAS spec) to formalize the API, specify parameters, identify possible return parameters and codes, etc.

Many developers use Integrated Development Environments (IDEs) to organize the environment, such as VSCode (open source), PyCharm (community and paid-tier) or GoLand (paid-tier).

Depending on the IDE, there may be extensions to help as you write your OAS specs. For example, VSCode has several OAS spec linter extensions that can statically flag issues with the spec, such as Spectral (open source), and Postman (free and paid-tier). The Spectral extension even has an OWASP Top 10 API Security Risks ruleset. Panoptica (free trial and paid-tier) can run different OAS spec linters from the command line.

AI copilots are all the rage now, and can be used to develop the API client/server code. Popular AI copilots include GitHub Copilot (paid-tier) and others.

Note that not all API security issues can be detected statically. Many issues can only be detected in a dynamic environment, where API calls are actually being acted upon.

After the API code is finished, it is ready for unit testing.

 

Unit Testing

Once development is complete, the API code undergoes unit testing, where “mock” API calls are made to verify that the APIs are behaving correctly. A unit test environment is still static because, although calls can be made to client and server functions, the application isn’t running as a whole.

There are many tools to auto-generate mock API code and run mock API servers, including WireMock (open source), Mockoon (open source), Microcks (open source), Postman (free and paid-tier), RestAssured (open source) and SoapUI (open source).

Once unit tests are written and passing, the API code is ready for CI/CD.

 

Continuous Integration/Continuous Delivery (CI/CD)

In CI/CD, the code is submitted for code review, the image is built and some gating tests are run automagically. The gating tests include static tests, such as unit tests and OAS spec linters, and dynamic tests like end-to-end functional tests, where the code is actually installed and basic functionality can be tested in an automated way.

If the CI/CD tests all pass, the code is ready to be merged into the code repository and tested in staging.

 

Staging

A staging environment is similar to an actual production environment, but is isolated for internal testing. In staging, the application is installed and a quality assurance team can verify the functionality.

High availability and performance tests can also be run in staging. High availability testing involves verifying that no single points of failure exist in your application. Performance testing verifies that your application performs at scale, which includes a high volume of API traffic.

Tools for API performance and load testing include Locust (open source), SoapUI and Postman.

Another type of tool that is helpful during staging is a fuzzer. A fuzzer passes bad data into API endpoints in your application and tries to negatively affect the application (e.g. make it stop responding, make it crash, leak data, etc.). Examples of fuzz testing tools are RESTler (open source) and Panoptica.

 

Greenfield Deployment

The first time an application is deployed to production, it’s called a “greenfield deployment.” In greenfield, since there are no existing artifacts, there aren’t any versioning or upgrade concerns.

In a production environment, you can dynamically scan real-time API traffic for security risks to protect your application. The Panoptica CNAPP platform has a full suite of API security functionality, which we’ll discuss below.

 

Brownfield Deployment

Brownfield deployment is when the application is upgraded in an existing production environment.

With brownfield, things like API backwards compatibility and versioning come into play. For example, API clients could continue to use a prior OAS spec version after the application has been upgraded with a new one. Multiple API versions must be supported.

A canary deployment is a brownfield deployment where different versions of the application are running simultaneously in order to reduce risk with a new version. The canary deployment manages only a subset of the total API traffic. Here again, API backwards compatibility and versioning are important considerations.

 

Prevent Common API Security Issues Across the Pipeline

Now that we’ve talked about the OWASP Top 10 API Security risks and the full API pipeline, let’s take a look at some common API security issues and how to prevent them across the pipeline.

 

BOLA

BOLAs were the most prevalent kind of API security issue in 2023, according to OWASP. They are included in issues API1:2023 (Broken Object Level Authorization) and API3:2023 (Broken Object Property Level Authorization).

As previously mentioned, in a BOLA attack, an end user is able to access data that they don’t have the authorization to access, usually because metadata is leaked in API responses from the application.

Since data, especially PII, is a major target of breaches, any unauthorized access is a huge security problem.

How can BOLAs be prevented across the API pipeline?

• During development, make sure you have a strong authorization model in your application that doesn’t allow access to data without authorization, and make sure no data is leaked in API responses.
• In development and CI/CD, use OAS spec linters (discussed earlier) to flag potential authorization issues.
• During unit testing and CI/CD, run mock API traffic that tries to access data without authorization.
• In CI/CD and staging, run a fuzzer against your API endpoints that will send bad input into the APIs and flag any unexpected access to data.
• In staging and production, run dynamic API security tools to inspect API traffic and flag potential BOLA issues. Panoptica has BOLA detection capabilities.

BFLAs

BFLAs occur when application functionality is accessed without the proper authorization, either by an end user calling into the application or between application microservices. BOLA (above) is about accessing data, BFLA is about accessing functionality. Gaining unauthorized access to functionality can ultimately lead to data breaches. BFLAs are OWASP issue API5:2023 (Broken Function Level Authorization).

How can BFLAs be prevented across the API pipeline?

• During development, make sure you have a strong authorization model for accessing application functionality from end users and between microservices.
• In unit testing and CI/CD, run mock API traffic that tries to access application functionality without authorization.
• In staging and production, run dynamic API security tools to inspect API traffic and flag potential BFLA issues. Panoptica has the ability to learn the BFLA authorization model and then detect any potential violations in real-time traffic.

Weak Authentication

Weak authentication into an application is easier for an attacker to compromise. It could give threat actors access to user accounts and data. Weak (or broken) authentication is included in OWASP issues API2:2023 (Broken Authentication) and API8:2023 (Security Misconfiguration).

One form of this is basic authentication, which requires a username and password, where the password itself is “weak.” This includes short passwords, passwords that are too common (e.g. can be found in a dictionary search), or passwords that are reused across accounts.

Weak authentication can also be due to weak endpoint security, for example using HTTP instead of HTTPs.

Finally, encryption issues fall into this category. Having endpoints with no encryption or weak encryption can open attack surfaces into your application. If there isn’t any encryption, all API traffic is “in the clear” meaning it can be tapped and easily read. Weak encryption could involve shorter encryption keys that can be easily compromised.

How can weak authentication be prevented across the API pipeline?

• Develop secure endpoints (e.g. HTTPs) with strong encryption enabled.
• For basic auth, require strong passwords and multi-factor authentication (MFA).
• In development and CI/CD, use OAS spec linters (particularly with the OWASP Top 10 ruleset) to flag insecure endpoint issues.
• In unit testing and CI/CD, run mock API traffic that uses weak authentication and tries to gain access.
• In staging and production, run dynamic API security tools to flag weak authentication in real-time API traffic. Panoptica can detect many forms of weak authentication.

Shadow APIs

OWASP issue API9:2023 (Improper Inventory Management) includes shadow APIs. Shadow APIs are not documented in an OAS spec. They are a security risk you may not even know you have.

As your application evolves, it’s unlikely that the security of shadow APIs will also evolve. They may even be forgotten entirely, exposing an ongoing security loophole or backdoor into your application.

How can shadow APIs be prevented across the API pipeline?

• During development, make sure to take an inventory of all APIs and document each of them in an OAS spec.
• In staging and production, run dynamic API security tools that can detect shadow APIs in real-time traffic and reconstruct an OAS spec for them to document them properly. Panoptica has these capabilities.

Zombie APIs

OWASP issue API9:2023 (Improper Inventory Management) also includes zombie APIs. Zombies APIs are APIs that are deprecated in the OAS spec but are still active within the application. They occur in brownfield and canary production environments, where multiple API versions may be in use.
Like shadow APIs, zombie APIs are unlikely to evolve with your application and could receive less scrutiny from a security standpoint, thus leaving a backdoor into your application.

How can zombie APIs be prevented across the API pipeline?

• Remove support for zombie (deprecated) APIs as soon as possible.
• In staging and production, run dynamic API security tools that can detect zombie APIs in real-time traffic, such as Panoptica.

Weak 3^rd Party Authentication

Even if your application data access is really secure, weak 3^rd party authentication could still expose your data to threats. 3^rd party access to your data includes databases, S3 buckets, etc. Weak 3rd party authentication is included in OWASP issues API8:2023 (Security Misconfiguration) and API10:2023 (Unsafe Consumption of APIs).

How can weak 3^rd party authentication be prevented across the API pipeline?

• During development, keep an inventory of all 3^rd party APIs and services that are being used by your application.
• Verify that 3^rd party access is secure.
• In CI/CD and staging, use a tool to assess the security of 3^rd party API calls. The Panoptica CLI has this functionality.
• In staging and production, use cloud security scanners to detect weak 3^rd party authentication. Examples of cloud security scanning tools are AWS Config (paid service), Azure Automation and Control (free and paid-tier), GCP Cloud Asset Inventory (free) and CloudQuery (open source and paid-tier).

Resource Consumption

Unrestricted resource consumption is OWASP issue API4:2023. If an application is inundated with many API calls within a short period of time, it can have negative consequences. For example, application resources such as CPU, RAM and storage can be rapidly consumed or exhausted, leading to potentially higher operational costs, slower response time or even application failure and outages.

How can unrestricted resource consumption be prevented across the API pipeline?

• During development, add rate-limiting to the API processing in your application, including a maximum rate of API requests and a reasonable timeout.
• In staging, use performance testing that exceeds the allowed rate of API requests and verifies that the application is still functioning as expected.
• In staging and production, use an API gateway in front of your application to throttle and rate-limit API requests. Some popular API gateways are AWS API Gateway (free and paid-tier), GCP API Gateway (free and paid-tier), Kong (open source and paid-tier), Tyk (open source) and Azure API Management (free and paid-tier). Note that the application still needs it’s own rate-limiting functionality when using an API gateway.

OWASP issue API6:2023 (Unrestricted Access to Sensitive Business Flows) is related to unrestricted resource consumption, but it implies that automation, bad bots or AI are involved in the API abuse, compounding the resource consumption.

 

URL Spoofing

With a URL spoofing attack, an invalid or malicious URL is passed into an API request, and the server proxies the URL without validating it. The suspicious URL could be a fake site or a webhook. This could allow access to sensitive data and PII. This type of vulnerability is covered in OWASP issue API7:2023 (Server Side Request Forgery).

How can URL spoofing be prevented across the API pipeline? Defending against this type of attack can be complex. This is a good resource to get started. The high-level gist of prevention measures is:

• During development, perform validation on the given URL, including the IP address and domain name (see above resource link).
• Create a list of allowed URLs, if possible, and validate the given URL against the list (see above resource link).
• In unit testing and CI/CD, run mock API traffic that attempts to pass an invalid URL into the API.

Data Injection

Data injection can allow threat actors to pass malicious data, configurations or programs into an application via APIs. This could allow access to data (e.g. BOLA) or make an application unstable.

How can data injection be prevented across the API pipeline?

• During development, include strict type checking (i.e. check for correct type of data in a request, don’t allow unexpected data types) and input validation in API processing.
• Establish an upper limit on size and quantity of data that can be input in a request. For example, have a maximum size for a string input.
• In development and CI/CD, use OAS spec linters to detect issues with data input.
• In unit testing and CI/CD, run mock API traffic that tries to inject invalid data.
• In CI/CD and staging, run a fuzzer against your API endpoints that sends invalid or malformed data into your API. The Panoptica CLI includes fuzzing capabilities.
• In staging and production, run dynamic API security tools that can compare API traffic against the OAS spec and flag data discrepancies (including spec drift). The Panoptica CNAPP platform has this functionality.

Code Injection

Code injection is where undesirable code is added to an application. As IDE plugins and AI copilots are increasingly used to generate API client and server code, there’s a risk that “bad” code could be injected into your application. This could have unintended or even malicious side effects. For example, a rogue (malicious) API could be injected into your application creating backdoor access. Rogue APIs fall under OWASP issue API9:2023 (Improper Inventory Management).

How can code injection be prevented across the API pipeline?

• During development, it’s important to verify any generated code with thorough code reviews.
• In CI/CD, staging and production, image scans can search for any Common Vulnerabilities and Exposures (CVEs) in the application. Panoptica can scan both Kubernetes container images and virtual machine images for issues.
• In staging and production, run dynamic API security tools to scan for any rogue APIs. Panoptica has this capability.

 

Conclusion

From the OWASP Top 10 API Security Risks, through the API pipeline and on to common API security issues and how to prevent them, we’ve covered a lot of ground, with lots of tool suggestions along the way.

If you’d like to learn more about the Panoptica CNAPP platform and it’s API security capabilities, go here and also try a Cisco DevNet Learning Lab.

Wishing you and your applications the very best in API security!

 

 

 

Featured image courtesy of @ZinetroN / Shutterstock.com

Share: