Main knowledge breaches are on the rise, and APIs are more and more getting used to achieve 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 through the cloud and APIs. All the pieces from non-critical performance, like music streaming and social media, to extraordinarily vital knowledge, corresponding to monetary accounts and healthcare, is accessible 24×7 by APIs.
Why is it so fascinating to breach API safety? There are various nefarious causes, however listed below are only a few:
- Stealing Personally Identifiable Data (PII) and promoting it on the darkish internet or for identification 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 hazards of breaches make it vital to get API safety proper.
Every year, the Open Worldwide Software Safety Mission (OWASP) comes up with an inventory of the High 10 API Safety Dangers. We’ll take a fast have a look at the present listing, with examples of information breaches attributable to every kind of danger.
After that, we’ll discuss in regards to the API pipeline and methods to forestall frequent 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 Degree Authorization (BOLA)
In a BOLA assault, object IDs for utility knowledge are leaked in API responses and used to achieve unauthorized entry to delicate knowledge.
The big 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.
API2:2023 – Damaged Authentication
With damaged authentication, an attacker compromises weak authentication strategies and beneficial properties entry to an utility (and in the end, knowledge).
Many safety breaches are attributable to damaged authentication.
API3:2023 – Damaged Object Property Degree Authorization
That is just like BOLA, the place an attacker is ready to achieve unauthorized entry to knowledge.
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. One of these assault could cause utility instability and even outages. If massive quantities of utility sources are consumed with out restriction, the end result could possibly 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 visitors, it will possibly not perform.
API5:2023 – Damaged Operate Degree Authorization (BFLA)
With BFLA, unauthorized entry to utility performance is allowed. This consists of authorization points between microservices.
An insurance coverage firm was the sufferer of a BFLA assault as a consequence of buyer knowledge being out there to the general public through 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” 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 have been used to purchase restricted launch tickets for verified followers, which have been then offered at an enormous revenue.
API7:2023 – Server Aspect 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 achieve entry to delicate knowledge. The attacker makes use of the server to make the request seem reputable.
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.
API8:2023 – Safety Misconfiguration
Any weak or misconfigured safety in an utility opens assault surfaces.
In Might 2023, Toyota revealed an enormous knowledge breach as a consequence of inadequate cloud configurations.
API9:2023 – Improper Stock Administration
Improper API stock administration consists of undocumented (shadow) APIs, deprecated (zombie) APIs and unauthorized (rogue) APIs.
Shadow and zombie APIs are dangers as a result of they could not have ample 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 utility.
API10:2023 – Unsafe Consumption of APIs
Weak safety in 3rd social gathering APIs utilized by an utility can permit entry to knowledge.
An instance of this risk is an insecure AWS S3 bucket with entry to knowledge, which appears to be answerable for many current knowledge leaks. Even when the appliance which hosts the info may be very safe, the info may nonetheless be accessible by S3 APIs.
The API Pipeline
We hear about “pipelines” and “shifting 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 your complete API lifecycle, from preliminary growth (“on the left”) to deployment into manufacturing (“on the appropriate”). That is illustrated beneath.
Let’s focus on the varied levels of the API pipeline.
Growth/Coding
APIs are born in growth, ideally by first crafting an OpenAPI specification (OAS spec) to formalize the API, specify parameters, establish attainable return parameters and codes, and so on.
Many builders use Built-in Growth Environments (IDEs) to arrange the surroundings, corresponding 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, corresponding 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 totally different OAS spec linters from the command line.
AI copilots are all the fad now, and can be utilized to develop the API consumer/server code. Fashionable AI copilots embrace GitHub Copilot (paid-tier) and others.
Be aware that not all API safety points might be detected statically. Many points can solely be detected in a dynamic surroundings, 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 accurately. A unit take a look at surroundings remains to be static as a result of, though calls might be made to consumer and server features, the appliance isn’t working as a complete.
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 evaluate, the picture is constructed and a few gating checks are run automagically. The gating checks embrace static checks, corresponding 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 fundamental performance might be examined in an automatic method.
If the CI/CD checks all go, the code is able to be merged into the code repository and examined in staging.
Staging
A staging surroundings is just like an precise manufacturing surroundings, 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 checks can 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 embrace 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 so on.). 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 aren’t any present artifacts, there aren’t any versioning or improve considerations.
In a manufacturing surroundings, you may 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 focus on beneath.
Brownfield Deployment
Brownfield deployment is when the appliance is upgraded in an present manufacturing surroundings.
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 totally different variations of the appliance are working concurrently to be able to cut back danger with a brand new model. The canary deployment manages solely a subset of the entire 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 in regards to the OWASP High 10 API Safety dangers and the total API pipeline, let’s check out some frequent API safety points and easy methods to forestall them throughout the pipeline.
BOLA
BOLAs have been probably the most prevalent type of API safety situation in 2023, based on 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 consumer is ready to entry knowledge that they don’t have the authorization to entry, often 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 downside.
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 knowledge with out authorization, and ensure no knowledge 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 knowledge with out authorization.
- In CI/CD and staging, run a fuzzer in opposition to your API endpoints that can 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
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 in the end result in knowledge breaches. BFLAs are OWASP situation API5:2023 (Damaged Operate Degree 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 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
Weak authentication into an utility is simpler for an attacker to compromise. It may give risk 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 consists of quick passwords, passwords which might be too frequent (e.g. might be present in a dictionary search), or passwords which might be reused throughout accounts.
Weak authentication can be as a consequence 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” which 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 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.
Shadow APIs
OWASP situation API9:2023 (Improper Stock Administration) consists of shadow APIs. Shadow APIs should not documented in an OAS spec. They’re a safety danger chances are 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 completely, exposing an ongoing safety loophole or backdoor into your utility.
How can shadow APIs be prevented throughout the API pipeline?
- Throughout growth, 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.
Zombie APIs
OWASP situation API9:2023 (Improper Stock Administration) additionally consists of zombie APIs. Zombies APIs are APIs which might 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 attainable.
- In staging and manufacturing, run dynamic API safety instruments that may detect zombie APIs in real-time visitors, corresponding to Panoptica.
Weak 3rd Social gathering Authentication
Even when your utility knowledge entry is admittedly safe, weak 3rd social gathering authentication may nonetheless expose your knowledge to threats. 3rd social gathering entry to your knowledge consists of databases, S3 buckets, and so on. Weak third social gathering authentication is included in OWASP points API8:2023 (Safety Misconfiguration) and API10:2023 (Unsafe Consumption of APIs).
How can weak 3rd social gathering authentication be prevented throughout the API pipeline?
- Throughout growth, maintain an stock of all 3rd social gathering APIs and providers which might be being utilized by your utility.
- Confirm that 3rd social gathering entry is safe.
- In CI/CD and staging, use a instrument to assess the safety of threerd social gathering API calls. The Panoptica CLI has this performance.
- In staging and manufacturing, use cloud safety scanners to detect weak 3rd social gathering 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 situation API4:2023. If an utility is inundated with many API calls inside a brief time period, it will possibly have unfavourable penalties. For instance, utility sources corresponding to CPU, RAM and storage might be quickly consumed or exhausted, resulting in doubtlessly increased 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 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 fashionable 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 situation API6:2023 (Unrestricted Entry to Delicate Enterprise Flows) is expounded 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.
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 could possibly be a faux website or a webhook. This might permit entry to delicate knowledge and PII. One of these vulnerability is roofed in OWASP situation API7:2023 (Server Aspect Request Forgery).
How can URL spoofing be prevented throughout the API pipeline? Defending in opposition to such a assault might 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 deal with and area identify (see above useful resource hyperlink).
- Create an inventory 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 go an invalid URL into the API.
Information Injection
Information injection can permit risk actors to go malicious knowledge, configurations or packages into an utility through APIs. This might permit entry to knowledge (e.g. BOLA) or make an utility unstable.
How can knowledge 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 permit surprising knowledge 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 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 consists of fuzzing capabilities.
- In staging and manufacturing, run dynamic API safety instruments that may evaluate 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
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 unwanted effects. For instance, a rogue (malicious) API could possibly be injected into your utility creating backdoor entry. Rogue APIs fall underneath OWASP situation 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 utility. Panoptica can scan each Kubernetes container photos and digital machine photos 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 the API pipeline and on to frequent API safety points and easy methods to forestall them, we’ve coated plenty of floor, with a number of instrument strategies alongside the way in which.
Wishing you and your purposes the perfect in API safety!
Be taught extra in regards to the Panoptica CNAPP platform
and it’s API safety capabilities.
Strive a Cisco DevNet Studying Lab.
Share:
