Main knowledge breaches are on the rise, and APIs are more and more getting used to realize entry to delicate knowledge. The explanations for this are twofold: APIs are the primary line of protection into an utility (and it’s knowledge), and increasingly more purposes are accessible by way of the cloud and APIs. Every little thing from non-critical performance, like music streaming and social media, to extraordinarily important knowledge, comparable to monetary accounts and healthcare, is accessible 24×7 via 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 supply of information and the risks of breaches make it important to get API safety proper.
Every year, the Open Worldwide Software Safety Challenge (OWASP) comes up with a listing of the Prime 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 kind of danger.
After that, we’ll discuss concerning the API pipeline and methods to forestall 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 utility knowledge are leaked in API responses and used to realize unauthorized entry to delicate knowledge.
The massive Twitter (now X) API breach was a BOLA assault, the place an API that could possibly be used to seek out customers ended up leaking PII.
With damaged authentication, an attacker compromises weak authentication strategies and features entry to an utility (and finally, knowledge).
Many safety breaches are brought on by damaged authentication.
That is just like BOLA, the place an attacker is ready to acquire unauthorized entry to knowledge.
On this situation, the attacker is ready to get unrestricted entry to an utility and its assets. Such a assault may cause utility instability and even outages. If massive quantities of utility assets are consumed with out restriction, the end result could possibly be very expensive (e.g. paid-tier cloud assets)
An instance of this could be a Denial of Service (or DoS) assault, the place an utility is so overwhelmed with visitors, it might now not perform.
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 on account of buyer knowledge being out there to the general public by way of a “protected half” of the appliance.
This menace entails vulnerability to automated abuse of utility transactions, for instance ticket gross sales or thread feedback. For instance, “Unhealthy bots” could possibly be used to overwhelm an utility and circumvent safety.
This occurred with the Taylor Swift live performance ticket snafu in November 2022. Scalper bots had been used to purchase restricted launch tickets for verified followers, which had been then offered at an enormous revenue.
Also called “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 doubtlessly acquire entry to delicate knowledge. The attacker makes use of the server to make the request seem respectable.
The massive Capital One knowledge breach in 2019 was an SSRF assault, and resulted in PII for 100 million bank card holders to be stolen. Extra not too long ago, a category motion lawsuit was filed.
Any weak or misconfigured safety in an utility opens assault surfaces.
In Could 2023, Toyota revealed a giant knowledge breach on account of 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 might not have enough safety scrutiny. A rogue API can imply the identical factor as a shadow API, nevertheless it may also be the results of malicious code injection opening up a backdoor into an utility.
Weak safety in 3rd get together APIs utilized by an utility can enable entry to knowledge.
An instance of this menace is an insecure AWS S3 bucket with entry to knowledge, which appears to be chargeable for many latest knowledge leaks. Even when the appliance which hosts the info may be very safe, the info might nonetheless be accessible via S3 APIs.
The API Pipeline
We hear about “pipelines” and “shifting in direction of the left” on a regular basis in software program improvement. However what do these ideas imply within the context of APIs?
The API pipeline spans the complete API lifecycle, from preliminary improvement (“on the left”) to deployment into manufacturing (“on the suitable”). That is illustrated beneath.
Let’s talk about the assorted levels of the API pipeline.
APIs are born in improvement, ideally by first crafting an OpenAPI specification (OAS spec) to formalize the API, specify parameters, establish attainable 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, comparable 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 completely different OAS spec linters from the command line.
Be aware that not all API safety points might 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.
As soon as improvement 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 take a look at setting remains to be static as a result of, though calls might be made to consumer and server features, the appliance isn’t operating as a complete.
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 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 evaluation, the picture is constructed and a few gating checks are run automagically. The gating checks embody static checks, comparable to unit checks and OAS spec linters, and dynamic checks like end-to-end purposeful checks, the place the code is definitely put in and fundamental performance might 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 setting is just like an precise manufacturing setting, however is remoted for inner testing. In staging, the appliance is put in and a top quality assurance group can confirm the performance.
Excessive availability and efficiency checks may 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 visitors.
Instruments for API efficiency and cargo testing embody Locust (open supply), SoapUI and Postman.
One other kind of instrument that’s useful throughout staging is a fuzzer. A fuzzer passes unhealthy knowledge 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 knowledge, and many others.). Examples of fuzz testing instruments are RESTler (open supply) and Panoptica.
The primary time an utility is deployed to manufacturing, it’s known as a “greenfield deployment.” In greenfield, since there are not any present artifacts, there aren’t any versioning or improve issues.
In a manufacturing setting, you possibly can dynamically scan real-time API visitors for safety dangers to guard your utility. The Panoptica CNAPP platform has a full suite of API safety performance, which we’ll talk about beneath.
Brownfield deployment is when the appliance is upgraded in an present manufacturing setting.
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 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 to be able to cut 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 vital concerns.
Stop Frequent API Safety Points Throughout the Pipeline
Now that we’ve talked concerning the OWASP Prime 10 API Safety dangers and the complete API pipeline, let’s check out some widespread API safety points and learn how to forestall them throughout the pipeline.
BOLAs had been probably the most prevalent sort of API safety difficulty in 2023, in line 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 consumer is ready to entry knowledge that they don’t have the authorization to entry, normally as a result of metadata is leaked in API responses from the appliance.
Since knowledge, 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 improvement, ensure you have a robust authorization mannequin in your utility that doesn’t enable entry to knowledge with out authorization, and ensure no knowledge is leaked in API responses.
- In improvement 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 knowledge 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 knowledge.
- 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 utility performance is accessed with out the correct authorization, both by an finish consumer calling into the appliance or between utility microservices. BOLA (above) is about accessing knowledge, BFLA is about accessing performance. Gaining unauthorized entry to performance can finally result in knowledge breaches. BFLAs are OWASP difficulty API5:2023 (Damaged Perform Stage Authorization).
How can BFLAs be prevented throughout the API pipeline?
- Throughout improvement, ensure you have a robust authorization mannequin for accessing utility performance from finish customers and between microservices.
- In unit testing and CI/CD, run mock API visitors that tries to entry utility 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 be taught the BFLA authorization mannequin after which detect any potential violations in real-time visitors.
Weak authentication into an utility is simpler for an attacker to compromise. It might give menace actors entry to consumer accounts and knowledge. 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 quick passwords, passwords which can be too widespread (e.g. might be present in a dictionary search), or passwords which can be reused throughout accounts.
Weak authentication may also be on account 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 visitors is “within the clear” that 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 fundamental auth, require robust passwords and multi-factor authentication (MFA).
- In improvement and CI/CD, use OAS spec linters (significantly 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 realize 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 difficulty API9:2023 (Improper Stock Administration) contains shadow APIs. Shadow APIs aren’t documented in an OAS spec. They’re a safety danger it’s possible you’ll not even know you will have.
As your utility evolves, it’s unlikely that the safety of shadow APIs will even evolve. They might even be forgotten solely, exposing an ongoing safety loophole or backdoor into your utility.
How can shadow APIs be prevented throughout the API pipeline?
- Throughout improvement, ensure 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 visitors and reconstruct an OAS spec for them to doc them correctly. Panoptica has these capabilities.
OWASP difficulty 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 throughout 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 attainable.
- In staging and manufacturing, run dynamic API safety instruments that may detect zombie APIs in real-time visitors, comparable to Panoptica.
Weak 3rd Get together Authentication
Even when your utility knowledge entry is admittedly safe, weak 3rd get together authentication might nonetheless expose your knowledge to threats. 3rd get together entry to your knowledge contains databases, S3 buckets, and many others. Weak third get together authentication is included in OWASP points API8:2023 (Safety Misconfiguration) and API10:2023 (Unsafe Consumption of APIs).
How can weak 3rd get together authentication be prevented throughout the API pipeline?
- Throughout improvement, hold an stock of all 3rd get together APIs and providers which can be being utilized by your utility.
- Confirm that 3rd get together entry is safe.
- In CI/CD and staging, use a instrument to assess the safety of threerd get together API calls. The Panoptica CLI has this performance.
- In staging and manufacturing, use cloud safety scanners to detect weak 3rd get together 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 difficulty API4:2023. If an utility is inundated with many API calls inside a brief time frame, it might have damaging penalties. For instance, utility assets comparable to CPU, RAM and storage might 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 improvement, add rate-limiting to the API processing in your utility, together with a most price of API requests and an affordable timeout.
- In staging, use efficiency testing that exceeds the allowed price of API requests and verifies that the appliance remains 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 common 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). Be aware that the appliance nonetheless wants it’s personal rate-limiting performance when utilizing an API gateway.
OWASP difficulty 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.
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 could possibly be a pretend website or a webhook. This might enable entry to delicate knowledge and PII. Such a vulnerability is roofed in OWASP difficulty API7:2023 (Server Aspect Request Forgery).
How can URL spoofing be prevented throughout the API pipeline? Defending in opposition to this sort of assault might be advanced. This is an effective useful resource to get began. The high-level gist of prevention measures is:
- Throughout improvement, carry out validation on the given URL, together with the IP deal with and area title (see above useful resource hyperlink).
- Create a listing of allowed URLs, if attainable, and validate the given URL in opposition to the listing (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.
Knowledge injection can enable menace actors to cross malicious knowledge, configurations or applications into an utility by way of APIs. This might enable entry to knowledge (e.g. BOLA) or make an utility unstable.
How can knowledge injection be prevented throughout the API pipeline?
- Throughout improvement, embody strict kind checking (i.e. test for proper kind of information in a request, don’t enable surprising knowledge varieties) 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 improvement and CI/CD, use OAS spec linters to detect points with knowledge enter.
- In unit testing and CI/CD, run mock API visitors that tries to inject invalid knowledge.
- In CI/CD and staging, run a fuzzer in opposition to your API endpoints that sends invalid or malformed knowledge into your API. The Panoptica CLI contains fuzzing capabilities.
- In staging and manufacturing, run dynamic API safety instruments that may examine API visitors in opposition to the OAS spec and flag knowledge discrepancies (together with spec drift). The Panoptica CNAPP platform has this performance.
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 consumer and server code, there’s a danger that “unhealthy” code could possibly be injected into your utility. This might have unintended and even malicious unintended effects. For instance, a rogue (malicious) API could possibly be injected into your utility creating backdoor entry. Rogue APIs fall beneath OWASP difficulty API9:2023 (Improper Stock Administration).
How can code injection be prevented throughout the API pipeline?
- Throughout improvement, it’s vital to confirm any generated code with thorough code critiques.
- In CI/CD, staging and manufacturing, picture scans can seek for any Frequent 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.
From the OWASP Prime 10 API Safety Dangers, via the API pipeline and on to widespread API safety points and learn how to forestall them, we’ve lined numerous floor, with a lot of instrument ideas alongside the way in which.
Wishing you and your purposes the perfect in API safety!
Featured picture courtesy of @ZinetroN / Shutterstock.com