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 software (and it’s information), and increasingly more purposes are accessible by way of the cloud and APIs. The whole lot from non-critical performance, like music streaming and social media, to extraordinarily vital information, akin to monetary accounts and healthcare, is accessible 24×7 by way of APIs.
Why is it so fascinating to breach API safety? There are various nefarious causes, however listed here are just some:
- Stealing Personally Identifiable Info (PII) and promoting it on the darkish internet or for id theft
- For asset theft, extortion or ransom
- Inflicting software instability or unavailability
- Espionage (company or political)
- Election interference
- Political instability
The record goes on. The provision of information and the risks of breaches make it vital to get API safety proper.
Annually, the Open Worldwide Software Safety Mission (OWASP) comes up with an inventory of the Prime 10 API Safety Dangers. We’ll take a fast take a look at the present record, with examples of information breaches attributable to every kind of danger.
After that, we’ll discuss concerning the API pipeline and methods to stop widespread API safety points throughout the pipeline.
OWASP Prime 10 API Safety Dangers (2023)
Let’s check out the OWASP Prime 10 API Safety Dangers, ranked so as of prevalence (from highest to lowest).
In a BOLA assault, object IDs for software 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 might be used to search out customers ended up leaking PII.
With damaged authentication, an attacker compromises weak authentication strategies and positive aspects entry to an software (and finally, information).
Many safety breaches are attributable to damaged authentication.
That is just like BOLA, the place an attacker is ready to achieve unauthorized entry to information.
On this situation, the attacker is ready to get unrestricted entry to an software and its assets. The sort of assault could cause software instability and even outages. If giant quantities of software assets are consumed with out restriction, the end result might be very pricey (e.g. paid-tier cloud assets)
An instance of this is able to be a Denial of Service (or DoS) assault, the place an software is so overwhelmed with visitors, it may well not operate.
With BFLA, unauthorized entry to software performance is allowed. This contains authorization points between microservices.
An insurance coverage firm was the sufferer of a BFLA assault resulting from buyer information being obtainable to the general public by way of a “protected half” of the applying.
This menace entails vulnerability to automated abuse of software transactions, for instance ticket gross sales or thread feedback. For instance, “Dangerous bots” might be used to overwhelm an software 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.
Often known as “URL spoofing”, this entails a server utilizing an enter URL to a distant useful resource with out validating the given URL, which might enable attackers to get round a VPN or firewall and probably achieve entry to delicate information. The attacker makes use of the server to make the request seem reputable.
The massive Capital One information breach in 2019 was an SSRF assault, and resulted in PII for 100 million bank card holders to be stolen. Extra lately, a category motion lawsuit was filed.
Any weak or misconfigured safety in an software opens assault surfaces.
In Might 2023, Toyota revealed an enormous information breach resulting from inadequate cloud configurations.
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 could not have enough safety scrutiny. A rogue API can imply the identical factor as a shadow API, but it surely can be the results of malicious code injection opening up a backdoor into an software.
Weak safety in 3rd occasion APIs utilized by an software can enable entry to information.
An instance of this menace is an insecure AWS S3 bucket with entry to information, which appears to be answerable for many latest information leaks. Even when the applying which hosts the information could be very safe, the information might nonetheless be accessible by way of S3 APIs.
The API Pipeline
We hear about “pipelines” and “transferring in the 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 proper”). That is illustrated beneath.
Let’s talk about the varied phases of the API pipeline.
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.
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 Prime 10 API Safety Dangers ruleset. Panoptica (free trial and paid-tier) can run totally different OAS spec linters from the command line.
Observe that not all API safety points may be detected statically. Many points can solely be detected in a dynamic atmosphere, the place API calls are literally being acted upon.
After the API code is completed, it’s prepared for 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 accurately. A unit check atmosphere continues to be static as a result of, though calls may be made to shopper and server features, the applying isn’t operating as an entire.
There are various 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 checks 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 checks are run automagically. The gating checks embrace static checks, akin to unit checks and OAS spec linters, and dynamic checks like end-to-end useful checks, the place the code is definitely put in and primary performance may be examined in an automatic method.
If the CI/CD checks all cross, the code is able to be merged into the code repository and examined in staging.
A staging atmosphere is just like an precise manufacturing atmosphere, however is remoted for inside testing. In staging, the applying is put in and a high quality assurance workforce can confirm the performance.
Excessive availability and efficiency checks can be run in staging. Excessive availability testing entails verifying that no single factors of failure exist in your software. Efficiency testing verifies that your software performs at scale, which features a excessive quantity of API visitors.
Instruments for API efficiency and cargo testing embrace Locust (open supply), SoapUI and Postman.
One other kind of software that’s useful throughout staging is a fuzzer. A fuzzer passes unhealthy information into API endpoints in your software and tries to negatively have an effect on the applying (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.
The primary time an software is deployed to manufacturing, it’s known as a “greenfield deployment.” In greenfield, since there aren’t any present artifacts, there aren’t any versioning or improve considerations.
In a manufacturing atmosphere, you may dynamically scan real-time API visitors for safety dangers to guard your software. The Panoptica CNAPP platform has a full suite of API safety performance, which we’ll talk about beneath.
Brownfield deployment is when the applying is upgraded in an present manufacturing atmosphere.
With brownfield, issues like API backwards compatibility and versioning come into play. For instance, API shoppers might proceed to make use of a previous OAS spec model after the applying 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 totally different variations of the applying are operating concurrently in an effort to scale back danger with a brand new model. The canary deployment manages solely a subset of the overall API visitors. Right here once more, API backwards compatibility and versioning are necessary concerns.
Forestall Widespread API Safety Points Throughout the Pipeline
Now that we’ve talked concerning the OWASP Prime 10 API Safety dangers and the total API pipeline, let’s check out some widespread API safety points and methods to forestall them throughout the pipeline.
BOLAs have been probably the most prevalent type of API safety problem in 2023, in line with OWASP. They’re included in points API1:2023 (Damaged Object Degree Authorization) and API3:2023 (Damaged Object Property Degree 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, often as a result of metadata is leaked in API responses from the applying.
Since information, particularly PII, is a significant goal of breaches, any unauthorized entry is a large safety drawback.
How can BOLAs be prevented throughout the API pipeline?
- Throughout growth, ensure you have a robust authorization mannequin in your software that doesn’t enable 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 visitors that tries to entry information with out authorization.
- In CI/CD and staging, run a fuzzer in opposition to 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 visitors and flag potential BOLA points. Panoptica has BOLA detection capabilities.
BFLAs happen when software performance is accessed with out the correct authorization, both by an finish person calling into the applying or between software 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 Operate Degree Authorization).
How can BFLAs be prevented throughout the API pipeline?
- Throughout growth, ensure you have a robust authorization mannequin for accessing software performance from finish customers and between microservices.
- In unit testing and CI/CD, run mock API visitors that tries to entry software performance with out authorization.
- In staging and manufacturing, run dynamic API safety instruments to examine API visitors and flag potential BFLA points. Panoptica has the flexibility to study the BFLA authorization mannequin after which detect any potential violations in real-time visitors.
Weak authentication into an software is simpler for an attacker to compromise. It might give menace 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 primary authentication, which requires a username and password, the place the password itself is “weak.” This contains brief passwords, passwords which might be too widespread (e.g. may be present in a dictionary search), or passwords which might be reused throughout accounts.
Weak authentication can be resulting from weak endpoint safety, for instance utilizing HTTP as a substitute of HTTPs.
Lastly, encryption points fall into this class. Having endpoints with no encryption or weak encryption can open assault surfaces into your software. If there isn’t any encryption, all API visitors is “within the clear” which means it may be tapped and simply learn. Weak encryption might 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 robust encryption enabled.
- For primary auth, require robust passwords and multi-factor authentication (MFA).
- In growth and CI/CD, use OAS spec linters (notably with the OWASP Prime 10 ruleset) to flag insecure endpoint points.
- In unit testing and CI/CD, run mock API 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 visitors. Panoptica can detect many types of weak authentication.
OWASP problem API9:2023 (Improper Stock Administration) contains shadow APIs. Shadow APIs should not documented in an OAS spec. They’re a safety danger it’s possible you’ll not even know you’ve got.
As your software evolves, it’s unlikely that the safety of shadow APIs may even evolve. They could even be forgotten fully, exposing an ongoing safety loophole or backdoor into your software.
How can shadow APIs be prevented throughout the API pipeline?
- Throughout growth, ensure 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 visitors and reconstruct an OAS spec for them to doc them correctly. Panoptica has these capabilities.
OWASP problem API9:2023 (Improper Stock Administration) additionally contains zombie APIs. Zombies APIs are APIs which might be deprecated within the OAS spec however are nonetheless energetic throughout the software. 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 along with your software and will obtain much less scrutiny from a safety standpoint, thus leaving a backdoor into your software.
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 visitors, akin to Panoptica.
Weak 3rd Get together Authentication
Even when your software information entry is admittedly safe, weak 3rd occasion authentication might nonetheless expose your information to threats. 3rd occasion entry to your information contains databases, S3 buckets, and many others. Weak third occasion authentication is included in OWASP points API8:2023 (Safety Misconfiguration) and API10:2023 (Unsafe Consumption of APIs).
How can weak 3rd occasion authentication be prevented throughout the API pipeline?
- Throughout growth, hold an stock of all 3rd occasion APIs and providers which might be being utilized by your software.
- Confirm that 3rd occasion entry is safe.
- In CI/CD and staging, use a software to assess the safety of threerd occasion API calls. The Panoptica CLI has this performance.
- In staging and manufacturing, use cloud safety scanners to detect weak 3rd occasion 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 software is inundated with many API calls inside a brief time period, it may well have detrimental penalties. For instance, software assets akin to CPU, RAM and storage may be quickly consumed or exhausted, resulting in probably increased operational prices, slower response time and even software 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 software, together with a most fee of API requests and an inexpensive timeout.
- In staging, use efficiency testing that exceeds the allowed fee of API requests and verifies that the applying continues to be functioning as anticipated.
- In staging and manufacturing, use an API gateway in entrance of your software to throttle and rate-limit API requests. Some standard 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). Observe that the applying 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, but it surely implies that automation, unhealthy bots or AI are concerned within the API abuse, compounding the useful resource consumption.
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 might be a faux website or a webhook. This might enable entry to delicate information and PII. The 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 in opposition to the sort of assault may be advanced. This is an efficient 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 handle and area title (see above useful resource hyperlink).
- Create an inventory of allowed URLs, if potential, and validate the given URL in opposition to the record (see above useful resource hyperlink).
- In unit testing and CI/CD, run mock API visitors that makes an attempt to cross an invalid URL into the API.
Information injection can enable menace actors to cross malicious information, configurations or packages into an software by way of APIs. This might enable entry to information (e.g. BOLA) or make an software unstable.
How can information injection be prevented throughout the API pipeline?
- Throughout growth, embrace strict kind checking (i.e. examine for proper kind of information in a request, don’t enable surprising information sorts) and enter validation in API processing.
- Set up an higher restrict on measurement and amount of information that may be enter in a request. For instance, have a most measurement 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 visitors that tries to inject invalid information.
- In CI/CD and staging, run a fuzzer in opposition to 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 evaluate API visitors in opposition to the OAS spec and flag information discrepancies (together with spec drift). The Panoptica CNAPP platform has this performance.
Code injection is the place undesirable code is added to an software. As IDE plugins and AI copilots are more and more used to generate API shopper and server code, there’s a danger that “unhealthy” code might be injected into your software. This might have unintended and even malicious unwanted effects. For instance, a rogue (malicious) API might be injected into your software creating backdoor entry. Rogue APIs fall underneath OWASP problem API9:2023 (Improper Stock Administration).
How can code injection be prevented throughout the API pipeline?
- Throughout growth, it’s necessary to confirm any generated code with thorough code opinions.
- In CI/CD, staging and manufacturing, picture scans can seek for any Widespread Vulnerabilities and Exposures (CVEs) within the software. Panoptica can scan each Kubernetes container photographs and digital machine photographs for points.
- In staging and manufacturing, run dynamic API safety instruments to scan for any rogue APIs. Panoptica has this functionality.
From the OWASP Prime 10 API Safety Dangers, by way of the API pipeline and on to widespread API safety points and methods to forestall them, we’ve coated numerous floor, with a lot of software solutions alongside the way in which.
Wishing you and your purposes the easiest in API safety!
Be taught extra concerning the Panoptica CNAPP platform
and it’s API safety capabilities.
Strive a Cisco DevNet Studying Lab.