Securing APIs From Left to Proper (and All over the place in Between)

Main information breaches are on the rise, and APIs are more and more getting used to achieve entry to delicate information. The explanations for this are twofold: APIs are the primary line of protection into an utility (and it’s information), and increasingly more purposes are accessible by way of the cloud and APIs. Every thing from non-critical performance, like music streaming and social media, to extraordinarily essential information, akin to monetary accounts and healthcare, is accessible 24×7 by means of APIs.

Why is it so fascinating to breach API safety? There are numerous nefarious causes, however listed here are only a few:

• Stealing Personally Identifiable Data (PII) and promoting it on the darkish net or for id theft
• For asset theft, extortion or ransom
• Inflicting utility instability or unavailability
• Espionage (company or political)
• Election interference
• Political instability

The listing goes on. The provision of information and the risks of breaches make it essential to get API safety proper.

Annually, the Open Worldwide Utility Safety Venture (OWASP) comes up with a listing of the High 10 API Safety Dangers. We’ll take a fast have a look at the present listing, with examples of information breaches brought on by every sort of threat.

After that, we’ll discuss concerning the API pipeline and methods to stop widespread API safety points throughout the pipeline.

OWASP High 10 API Safety Dangers (2023)

Let’s check out the OWASP High 10 API Safety Dangers, ranked so as of prevalence (from highest to lowest).

API1:2023 – Damaged Object Stage Authorization (BOLA)

In a BOLA assault, object IDs for utility information are leaked in API responses and used to achieve unauthorized entry to delicate information.

The big Twitter (now X) API breach was a BOLA assault, the place an API that may very well be used to seek out customers ended up leaking PII.

API2:2023 – Damaged Authentication

With damaged authentication, an attacker compromises weak authentication strategies and features entry to an utility (and finally, information).

Many safety breaches are brought on by damaged authentication.

API3:2023 – Damaged Object Property Stage Authorization

That is much like BOLA, the place an attacker is ready to acquire unauthorized entry to information.

API4:2023 – Unrestricted Useful resource Consumption

On this state of affairs, the attacker is ready to get unrestricted entry to an utility and its sources. This sort of assault may cause utility instability and even outages. If giant quantities of utility sources are consumed with out restriction, the end result may very well be very expensive (e.g. paid-tier cloud sources)

An instance of this is able to be a Denial of Service (or DoS) assault, the place an utility is so overwhelmed with site visitors, it could now not operate.

API5:2023 – Damaged Perform Stage Authorization (BFLA)

With BFLA, unauthorized entry to utility performance is allowed. This contains authorization points between microservices.

An insurance coverage firm was the sufferer of a BFLA assault because of buyer information being obtainable to the general public by way of a “protected half” of the appliance.

API6:2023 – Unrestricted Entry to Delicate Enterprise Flows

This risk entails vulnerability to automated abuse of utility transactions, for instance ticket gross sales or thread feedback. For instance, “Unhealthy bots” may very well be used to overwhelm an utility and circumvent safety.

This occurred with the Taylor Swift live performance ticket snafu in November 2022. Scalper bots have been used to purchase restricted launch tickets for verified followers, which have been then bought at an enormous revenue.

API7:2023 – Server Facet Request Forgery (SSRF)

Also called “URL spoofing”, this entails a server utilizing an enter URL to a distant useful resource with out validating the given URL, which may permit attackers to get round a VPN or firewall and doubtlessly acquire entry to delicate information. The attacker makes use of the server to make the request seem official.

The large Capital One information breach in 2019 was an SSRF assault, and resulted in PII for 100 million bank card holders to be stolen. Extra just lately, a category motion lawsuit was filed.

API8:2023 – Safety Misconfiguration

Any weak or misconfigured safety in an utility opens assault surfaces.

In Could 2023, Toyota revealed a giant information breach because of inadequate cloud configurations.

API9:2023 – Improper Stock Administration

Improper API stock administration contains undocumented (shadow) APIs, deprecated (zombie) APIs and unauthorized (rogue) APIs.

Shadow and zombie APIs are dangers as a result of they might not have adequate safety scrutiny. A rogue API can imply the identical factor as a shadow API, nevertheless it will also be the results of malicious code injection opening up a backdoor into an utility.

API10:2023 – Unsafe Consumption of APIs

Weak safety in 3^rd celebration APIs utilized by an utility can permit entry to information.

An instance of this risk is an insecure AWS S3 bucket with entry to information, which appears to be chargeable for many latest information leaks. Even when the appliance which hosts the information could be very safe, the information may nonetheless be accessible by means of S3 APIs.

The API Pipeline

We hear about “pipelines” and “transferring in direction of the left” on a regular basis in software program growth. However what do these ideas imply within the context of APIs?

The API pipeline spans all the API lifecycle, from preliminary growth (“on the left”) to deployment into manufacturing (“on the best”). That is illustrated under.

Let’s focus on the varied levels of the API pipeline.

Improvement/Coding

APIs are born in growth, ideally by first crafting an OpenAPI specification (OAS spec) to formalize the API, specify parameters, establish potential return parameters and codes, and many others.

Many builders use Built-in Improvement Environments (IDEs) to arrange the setting, akin to VSCode (open supply), PyCharm (group and paid-tier) or GoLand (paid-tier).

Relying on the IDE, there could also be extensions to assist as you write your OAS specs. For instance, VSCode has a number of OAS spec linter extensions that may statically flag points with the spec, akin to Spectral (open supply), and Postman (free and paid-tier). The Spectral extension even has an OWASP High 10 API Safety Dangers ruleset. Panoptica (free trial and paid-tier) can run completely different OAS spec linters from the command line.

AI copilots are all the fad now, and can be utilized to develop the API shopper/server code. Widespread AI copilots embrace GitHub Copilot (paid-tier) and others.

Notice that not all API safety points will be detected statically. Many points can solely be detected in a dynamic setting, the place API calls are literally being acted upon.

After the API code is completed, it’s prepared for unit testing.

Unit Testing

As soon as growth is full, the API code undergoes unit testing, the place “mock” API calls are made to confirm that the APIs are behaving appropriately. A unit check setting continues to be static as a result of, though calls will be made to shopper and server capabilities, the appliance isn’t operating as an entire.

There are numerous instruments to auto-generate mock API code and run mock API servers, together with WireMock (open supply), Mockoon (open supply), Microcks (open supply), Postman (free and paid-tier), RestAssured (open supply) and SoapUI (open supply).

As soon as unit exams are written and passing, the API code is prepared for CI/CD.

Steady Integration/Steady Supply (CI/CD)

In CI/CD, the code is submitted for code overview, the picture is constructed and a few gating exams are run automagically. The gating exams embrace static exams, akin to unit exams and OAS spec linters, and dynamic exams like end-to-end useful exams, the place the code is definitely put in and fundamental performance will be examined in an automatic manner.

If the CI/CD exams all move, the code is able to be merged into the code repository and examined in staging.

Staging

A staging setting is much like an precise manufacturing setting, however is remoted for inner testing. In staging, the appliance is put in and a high quality assurance workforce can confirm the performance.

Excessive availability and efficiency exams will also be run in staging. Excessive availability testing entails verifying that no single factors of failure exist in your utility. Efficiency testing verifies that your utility performs at scale, which features a excessive quantity of API site visitors.

Instruments for API efficiency and cargo testing embrace Locust (open supply), SoapUI and Postman.

One other sort of device that’s useful throughout staging is a fuzzer. A fuzzer passes unhealthy information into API endpoints in your utility and tries to negatively have an effect on the appliance (e.g. make it cease responding, make it crash, leak information, and many others.). Examples of fuzz testing instruments are RESTler (open supply) and Panoptica.

Greenfield Deployment

The primary time an utility is deployed to manufacturing, it’s known as a “greenfield deployment.” In greenfield, since there are not any current artifacts, there aren’t any versioning or improve considerations.

In a manufacturing setting, you’ll be able to dynamically scan real-time API site visitors for safety dangers to guard your utility. The Panoptica CNAPP platform has a full suite of API safety performance, which we’ll focus on under.

Brownfield Deployment

Brownfield deployment is when the appliance is upgraded in an current manufacturing setting.

With brownfield, issues like API backwards compatibility and versioning come into play. For instance, API purchasers may proceed to make use of a previous OAS spec model after the appliance has been upgraded with a brand new one. A number of API variations have to be supported.

A canary deployment is a brownfield deployment the place completely different variations of the appliance are operating concurrently with the intention to cut back threat with a brand new model. The canary deployment manages solely a subset of the entire API site visitors. Right here once more, API backwards compatibility and versioning are vital issues.

Stop Widespread API Safety Points Throughout the Pipeline

Now that we’ve talked concerning the OWASP High 10 API Safety dangers and the total API pipeline, let’s check out some widespread API safety points and how one can stop them throughout the pipeline.

BOLA

BOLAs have been probably the most prevalent type of API safety problem in 2023, in accordance with OWASP. They’re included in points API1:2023 (Damaged Object Stage Authorization) and API3:2023 (Damaged Object Property Stage Authorization).

As beforehand talked about, in a BOLA assault, an finish person is ready to entry information that they don’t have the authorization to entry, normally as a result of metadata is leaked in API responses from the appliance.

Since information, particularly PII, is a serious goal of breaches, any unauthorized entry is a large safety drawback.

How can BOLAs be prevented throughout the API pipeline?

• Throughout growth, be sure you have a sturdy authorization mannequin in your utility that doesn’t permit entry to information with out authorization, and ensure no information is leaked in API responses.
• In growth and CI/CD, use OAS spec linters (mentioned earlier) to flag potential authorization points.
• Throughout unit testing and CI/CD, run mock API site visitors that tries to entry information with out authorization.
• In CI/CD and staging, run a fuzzer towards your API endpoints that may ship unhealthy enter into the APIs and flag any surprising entry to information.
• In staging and manufacturing, run dynamic API safety instruments to examine API site visitors and flag potential BOLA points. Panoptica has BOLA detection capabilities.

BFLAs

BFLAs happen when utility performance is accessed with out the correct authorization, both by an finish person calling into the appliance or between utility microservices. BOLA (above) is about accessing information, BFLA is about accessing performance. Gaining unauthorized entry to performance can finally result in information breaches. BFLAs are OWASP problem API5:2023 (Damaged Perform Stage Authorization).

How can BFLAs be prevented throughout the API pipeline?

• Throughout growth, be sure you have a sturdy authorization mannequin for accessing utility performance from finish customers and between microservices.
• In unit testing and CI/CD, run mock API site visitors that tries to entry utility performance with out authorization.
• In staging and manufacturing, run dynamic API safety instruments to examine API site visitors and flag potential BFLA points. Panoptica has the flexibility to be taught the BFLA authorization mannequin after which detect any potential violations in real-time site visitors.

Weak Authentication

Weak authentication into an utility is simpler for an attacker to compromise. It may give risk actors entry to person accounts and information. Weak (or damaged) authentication is included in OWASP points API2:2023 (Damaged Authentication) and API8:2023 (Safety Misconfiguration).

One type of that is fundamental authentication, which requires a username and password, the place the password itself is “weak.” This contains brief passwords, passwords which can be too widespread (e.g. will be present in a dictionary search), or passwords which can be reused throughout accounts.

Weak authentication will also be because of weak endpoint safety, for instance utilizing HTTP as an alternative of HTTPs.

Lastly, encryption points fall into this class. Having endpoints with no encryption or weak encryption can open assault surfaces into your utility. If there isn’t any encryption, all API site visitors is “within the clear” that means it may be tapped and simply learn. Weak encryption may contain shorter encryption keys that may be simply compromised.

How can weak authentication be prevented throughout the API pipeline?

• Develop safe endpoints (e.g. HTTPs) with sturdy encryption enabled.
• For fundamental auth, require sturdy passwords and multi-factor authentication (MFA).
• In growth and CI/CD, use OAS spec linters (notably with the OWASP High 10 ruleset) to flag insecure endpoint points.
• In unit testing and CI/CD, run mock API site visitors that makes use of weak authentication and tries to achieve entry.
• In staging and manufacturing, run dynamic API safety instruments to flag weak authentication in real-time API site visitors. Panoptica can detect many types of weak authentication.

Shadow APIs

OWASP problem API9:2023 (Improper Stock Administration) contains shadow APIs. Shadow APIs aren’t documented in an OAS spec. They’re a safety threat you might not even know you might have.

As your utility evolves, it’s unlikely that the safety of shadow APIs may even evolve. They could even be forgotten completely, exposing an ongoing safety loophole or backdoor into your utility.

How can shadow APIs be prevented throughout the API pipeline?

• Throughout growth, make sure that to take an stock of all APIs and doc every of them in an OAS spec.
• In staging and manufacturing, run dynamic API safety instruments that may detect shadow APIs in real-time site visitors and reconstruct an OAS spec for them to doc them correctly. Panoptica has these capabilities.

Zombie APIs

OWASP problem API9:2023 (Improper Stock Administration) additionally contains zombie APIs. Zombies APIs are APIs which can be deprecated within the OAS spec however are nonetheless energetic inside the utility. They happen in brownfield and canary manufacturing environments, the place a number of API variations could also be in use.
Like shadow APIs, zombie APIs are unlikely to evolve together with your utility and will obtain much less scrutiny from a safety standpoint, thus leaving a backdoor into your utility.

How can zombie APIs be prevented throughout the API pipeline?

• Take away help for zombie (deprecated) APIs as quickly as potential.
• In staging and manufacturing, run dynamic API safety instruments that may detect zombie APIs in real-time site visitors, akin to Panoptica.

Weak 3^rd Celebration Authentication

Even when your utility information entry is de facto safe, weak 3^rd celebration authentication may nonetheless expose your information to threats. 3^rd celebration entry to your information contains databases, S3 buckets, and many others. Weak third celebration authentication is included in OWASP points API8:2023 (Safety Misconfiguration) and API10:2023 (Unsafe Consumption of APIs).

How can weak 3^rd celebration authentication be prevented throughout the API pipeline?

• Throughout growth, hold an stock of all 3^rd celebration APIs and companies which can be being utilized by your utility.
• Confirm that 3^rd celebration entry is safe.
• In CI/CD and staging, use a device to assess the safety of three^rd celebration API calls. The Panoptica CLI has this performance.
• In staging and manufacturing, use cloud safety scanners to detect weak 3^rd celebration authentication. Examples of cloud safety scanning instruments are AWS Config (paid service), Azure Automation and Management (free and paid-tier), GCP Cloud Asset Stock (free) and CloudQuery (open supply and paid-tier).

Useful resource Consumption

Unrestricted useful resource consumption is OWASP problem API4:2023. If an utility is inundated with many API calls inside a brief time frame, it could have unfavourable penalties. For instance, utility sources akin to CPU, RAM and storage will be quickly consumed or exhausted, resulting in doubtlessly larger operational prices, slower response time and even utility failure and outages.

How can unrestricted useful resource consumption be prevented throughout the API pipeline?

• Throughout growth, add rate-limiting to the API processing in your utility, together with a most fee of API requests and an affordable timeout.
• In staging, use efficiency testing that exceeds the allowed fee of API requests and verifies that the appliance continues to be functioning as anticipated.
• In staging and manufacturing, use an API gateway in entrance of your utility to throttle and rate-limit API requests. Some in style API gateways are AWS API Gateway (free and paid-tier), GCP API Gateway (free and paid-tier), Kong (open supply and paid-tier), Tyk (open supply) and Azure API Administration (free and paid-tier). Notice that the appliance nonetheless wants it’s personal rate-limiting performance when utilizing an API gateway.

OWASP problem API6:2023 (Unrestricted Entry to Delicate Enterprise Flows) is said to unrestricted useful resource consumption, nevertheless it implies that automation, unhealthy bots or AI are concerned within the API abuse, compounding the useful resource consumption.

URL Spoofing

With a URL spoofing assault, an invalid or malicious URL is handed into an API request, and the server proxies the URL with out validating it. The suspicious URL may very well be a pretend web site or a webhook. This might permit entry to delicate information and PII. This sort of vulnerability is roofed in OWASP problem API7:2023 (Server Facet Request Forgery).

How can URL spoofing be prevented throughout the API pipeline? Defending towards one of these assault will be complicated. This is an effective useful resource to get began. The high-level gist of prevention measures is:

• Throughout growth, carry out validation on the given URL, together with the IP deal with and area identify (see above useful resource hyperlink).
• Create a listing of allowed URLs, if potential, and validate the given URL towards the listing (see above useful resource hyperlink).
• In unit testing and CI/CD, run mock API site visitors that makes an attempt to move an invalid URL into the API.

Information Injection

Information injection can permit risk actors to move malicious information, configurations or applications into an utility by way of APIs. This might permit entry to information (e.g. BOLA) or make an utility unstable.

How can information injection be prevented throughout the API pipeline?

• Throughout growth, embrace strict sort checking (i.e. examine for proper sort of information in a request, don’t permit surprising information sorts) and enter validation in API processing.
• Set up an higher restrict on dimension and amount of information that may be enter in a request. For instance, have a most dimension for a string enter.
• In growth and CI/CD, use OAS spec linters to detect points with information enter.
• In unit testing and CI/CD, run mock API site visitors that tries to inject invalid information.
• In CI/CD and staging, run a fuzzer towards your API endpoints that sends invalid or malformed information into your API. The Panoptica CLI contains fuzzing capabilities.
• In staging and manufacturing, run dynamic API safety instruments that may examine API site visitors towards the OAS spec and flag information discrepancies (together with spec drift). The Panoptica CNAPP platform has this performance.

Code Injection

Code injection is the place undesirable code is added to an utility. As IDE plugins and AI copilots are more and more used to generate API shopper and server code, there’s a threat that “unhealthy” code may very well be injected into your utility. This might have unintended and even malicious negative effects. For instance, a rogue (malicious) API may very well be injected into your utility creating backdoor entry. Rogue APIs fall below OWASP problem API9:2023 (Improper Stock Administration).

How can code injection be prevented throughout the API pipeline?

• Throughout growth, it’s vital to confirm any generated code with thorough code evaluations.
• In CI/CD, staging and manufacturing, picture scans can seek for any Widespread Vulnerabilities and Exposures (CVEs) within the utility. Panoptica can scan each Kubernetes container pictures and digital machine pictures for points.
• In staging and manufacturing, run dynamic API safety instruments to scan for any rogue APIs. Panoptica has this functionality.

Conclusion

From the OWASP High 10 API Safety Dangers, by means of the API pipeline and on to widespread API safety points and how one can stop them, we’ve coated quite a lot of floor, with plenty of device recommendations alongside the best way.

Wishing you and your purposes the easiest in API safety!

Study extra concerning the Panoptica CNAPP platform
and it’s API safety capabilities.

Attempt a Cisco DevNet Studying Lab.

Share: