Schedule a Free Risk Analysis
Schedule a
Free Risk Analysis
Noname Security is the industry leader in Complete Proactive API Security. The Noname API Security Platform proactively secures your environment from API security vulnerabilities, misconfigurations, and design flaws. APIs are protected from attacks in real-time with automated detection and response, and secured faster with pre-production testing.

Market Leading Complete API Protection Platform

Protect APIs throughout their entire life cycle, from code to production, automatically secure your environment, detect vulnerabilities before they are exploited, seamlessly integrate with your existing API gateways, load balancers, WAFs, and more for complete visibility into your API ecosystem.
DISCOVERY
Automatically discover your API attack surface, domains and issues.
POSTURE MANAGEMENT
Understand every API in your organization’s ecosystem with full business context.
RUNTIME PROTECTION
Identify business-logic-based attacks immediately, reduce Mean-Time-To-Resolution(MTTR) and fully align with security operations center (SOC).
TESTING
Secure APIs faster with best in class automated active testing and dynamic API visibility across multiple states and environments.
DEPLOYMENT
Noname Security offers the most flexible and comprehensive deployment and integration options available, leveraging your current infrastructure.

How we Partner with Noname Security

TOM SHAW aggregates all Security Controls under our Noble1 offensive platform. As part of our Cyber Ecosystem of tightly integrated partners, Noname Security seamlessly integrates with your current infrastructure to provide you with the gold standard in Complete API Security, automated and in real-time. All combined with User-Centric Cyber Insights on 1 Platform, Noble1, to take you to the next level of security risk mitigation.

The Noname partnership with TOM SHAW helps you instantly:

– Integrate into your current infrastructure.
– Identify and map your complete API attack surface. – Analyse context of your posture across your full API infrastructure.
– Automate testing, + Advanced, API specific, directly within your development pipelines.
– Generate a risk based remediation roadmap with actionable insights so you can prioritise remediation resources.
– Deliver Organisation wide and Individual User Cyber Insights utilising Al and ML to predict future risk and reduce attack surfaces.

Reduce your cyber risk with Noname Security and Noble1.
Find out your Baseline API Risk with a Free Proof of Value.
Try a FREE Baseline API Risk Analysis

BLOG ARTICLE

The Updated OWSAP API Security Top 10 for 2023, Aug 8, 2023
The Updated OWSAP API Security Top 10 for 2023, Aug 8, 2023

The Updated OWASP API Security Top 10 for 2023 is Here

The Open Web Application Security Project (OWASP) is a global non-profit organization dedicated to improving the security of software. The OWASP foundation first released a list of the top 10 security risks faced by APIs in 2019. After a couple of months of healthy debate on the release candidate we now have the finalized updated list for 2023. Although 4 years is an extremely long time when it comes to computing, the fact remains that most organizations are still in the process of putting better API security controls in place to protect against the 2019 Top 10. Additionally, remember that the list contains ten categories of vulnerabilities, each category housing multiple vulnerabilities. Comparing the lists, it is of little wonder that the 2023 RC one remains fairly close to the 2019 one, and the final version hasn’t significantly changed either. While #1 remains the same, the rest of the list has new language, new categories, and a shuffling of those that are still from the 2019 version.
API1:2019 Broken Object Level AuthorizationAPI1:2023RC Broken Object Level AuthorizationAPI1:2023 – Broken Object Level Authorization
API2:2019 Broken User AuthenticationAPI2:2023RC Broken AuthenticationAPI2:2023 – Broken Authentication
API3:2019 Excessive Data ExposureAPI3:2023RC Broken Object Property Level AuthorizationAPI3:2023 – Broken Object Property Level Authorization
API4:2019 Lack of Resources & Rate LimitingAPI4:2023RC Unrestricted Resource ConsumptionAPI4:2023 – Unrestricted Resource Consumption
API5:2019 Broken Function Level AuthorizationAPI5:2023RC Broken Function Level AuthorizationAPI5:2023 – Broken Function Level Authorization
API6:2019 Mass AssignmentAPI6:2023RC Server Side Request ForgeryAPI6:2023 – Unrestricted Access to Sensitive Business Flows
API7:2019 Security MisconfigurationAPI7:2023RC Security MisconfigurationAPI7:2023 – Server Side Request Forgery
API8:2019 InjectionAPI8:2023RC Lack of Protection from Automated ThreatsAPI8:2023 – Security Misconfiguration
API9:2019 Improper Assets ManagementAPI9:2023RC Improper Assets ManagementAPI9:2023 – Improper Inventory Management
API10:2019 Insufficient Logging & MonitoringAPI10:2023RC Unsafe Consumption of APIsAPI10:2023 – Unsafe Consumption of APIs

Release Candidate Changes

As with the 2019 version, the 2023 release candidate still holds firm that business logic based attacks misusing authorization implementations (BOLA) remain the biggest risk category for APIs today and into the foreseeable future. An API potentially serves many users and provides access to multiple pieces of data, frequently sensitive data. These different users and user types naturally have different data access policies, depending on the business need. From an API design and development perspective, it remains challenging to build an API that correctly enforces these granular authorization policies. We witness this daily as customers test their code using our Active Testing solution. The new list also consolidates two existing categories under API3:2023RC BOPLA (Broken Object Property Level Authorization). In the 2019 list, they were separated out in:
  • API3:2019 Excessive Data Exposure, whereby the API returns sensitive data to the client by design. This data is expected to be filtered on the client side before being presented to the user, but an attacker can easily sniff the traffic and see the sensitive data.
  • API6:2019 Mass Assignment whereby the sensitivity of internal objects is misjudged, and the API endpoint automatically converts client parameters into internal object properties.
The BOPLA vulnerability is apparent when allowing a user to access an object using an API endpoint, without validating that the user has access to the specific object properties they are trying to access.
New on the 2023 list and somewhat borrowed from the existing OWASP Top 10 2021 is API6:2023RC Server-Side Request Forgery.

Server-Side Request Forgery (SSRF) flaws occur whenever an API fetches a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN. Using modern concepts like Webhooks, file fetching from URLs, custom SSO, and URL previews, encourages developers to access an external resource based on user input, heightening the potential risk. Additionally, concepts like microservices based architectures expose control/management plane elements over HTTP using well known paths, making them an easier target.

API4:2023RC Unrestricted Resource Consumption borrows heavily from API4:2019 Lack of Resources & Rate Limiting, with a focus on protecting the available compute and storage resources to successfully serve legitimate API requests. By managing API limits around timeouts, processes, available memory, number of operations, etc., we can prevent an unfair distribution of resources.

API8:2023RC Lack of Protection from Automated Threats, these types of attacks have increased as commercial businesses move more and more to API based systems for eCommerce purposes. Traditional API Gateway and WAF based solutions like rate limiting fall short, as bot-net operators use more distributed approaches to launch their attacks. For these types of attacks, it remains paramount that we identify the malicious traffic and implement automated blocking actions to safeguard the API and allow normal business traffic to continue to flow.

Final Version Changes

The “new’ ‘ category is API6:2023 Unrestricted Access to Sensitive Business Flows, which is a lack of understanding which business flow your newly created API exposes. Some business flows are more sensitive than others, in the sense that excessive access to them may harm the business. For example; A ride-sharing app provides a referral program – users can invite their friends and gain credit for each friend who has joined the app. This credit can be later used as cash to book rides. An attacker exploits this flow by writing a script to automate the registration process, with each new user adding credit to the attacker’s wallet. The attacker can later enjoy free rides or sell the accounts with excessive credits for cash. So identifying the user identity and limiting access or timed access would be a good way to mitigate this type of attack. The previous API8:2023RC Lack of Protection from Automated Threats was dropped or subsumed by API6:2023 as it mostly addresses a similar issue. API9:2023 Improper Inventory Management has replaced API9:2023RC Improper Assets Management and matched wonderfully well with the Noname Platform capabilities as it turns out.

How Noname Security Addresses the OWASP Top 10

Noname Security provides the option to view your API issues through the lens of both the 2019 and 2023 versions. If you use the OWASP list as a guideline in prioritizing vulnerabilities, it will be easier to link real life findings to the framework.
Close

Finding clarity in the noise: Visibility and AI in an age plagued by security threats.

The Open Web Application Security Project (OWASP) is a global non-profit organization dedicated to improving the security of software. The OWASP foundation first released a list of the top 10 security risks faced by APIs in 2019. After a couple of months of healthy debate on the release candidate we now have the finalized updated list for 2023.

Although 4 years is an extremely long time when it comes to computing, the fact remains that most organizations are still in the process of putting better API security controls in place to protect against the 2019 Top 10. Additionally, remember that the list contains ten categories of vulnerabilities, each category housing multiple vulnerabilities.

Comparing the lists, it is of little wonder that the 2023 RC one remains fairly close to the 2019 one, and the final version hasn’t significantly changed either. While #1 remains the same, the rest of the list has new language, new categories, and a shuffling of those that are still from the 2019 version.
API1:2019 Broken Object Level AuthorizationAPI1:2023RC Broken Object Level AuthorizationAPI1:2023 – Broken Object Level Authorization
API2:2019 Broken User AuthenticationAPI2:2023RC Broken AuthenticationAPI2:2023 – Broken Authentication
API3:2019 Excessive Data ExposureAPI3:2023RC Broken Object Property Level AuthorizationAPI3:2023 – Broken Object Property Level Authorization
API4:2019 Lack of Resources & Rate LimitingAPI4:2023RC Unrestricted Resource ConsumptionAPI4:2023 – Unrestricted Resource Consumption
API5:2019 Broken Function Level AuthorizationAPI5:2023RC Broken Function Level AuthorizationAPI5:2023 – Broken Function Level Authorization
API6:2019 Mass AssignmentAPI6:2023RC Server Side Request ForgeryAPI6:2023 – Unrestricted Access to Sensitive Business Flows
API7:2019 Security MisconfigurationAPI7:2023RC Security MisconfigurationAPI7:2023 – Server Side Request Forgery
API8:2019 InjectionAPI8:2023RC Lack of Protection from Automated ThreatsAPI8:2023 – Security Misconfiguration
API9:2019 Improper Assets ManagementAPI9:2023RC Improper Assets ManagementAPI9:2023 – Improper Inventory Management
API10:2019 Insufficient Logging & MonitoringAPI10:2023RC Unsafe Consumption of APIsAPI10:2023 – Unsafe Consumption of APIs

Release Candidate Changes

As with the 2019 version, the 2023 release candidate still holds firm that business logic based attacks misusing authorization implementations (BOLA) remain the biggest risk category for APIs today and into the foreseeable future.

An API potentially serves many users and provides access to multiple pieces of data, frequently sensitive data. These different users and user types naturally have different data access policies, depending on the business need. From an API design and development perspective, it remains challenging to build an API that correctly enforces these granular authorization policies. We witness this daily as customers test their code using our Active Testing solution.

The new list also consolidates two existing categories under API3:2023RC BOPLA (Broken Object Property Level Authorization). In the 2019 list, they were separated out in:

  • API3:2019 Excessive Data Exposure, whereby the API returns sensitive data to the client by design. This data is expected to be filtered on the client side before being presented to the user, but an attacker can easily sniff the traffic and see the sensitive data.
  • API6:2019 Mass Assignment whereby the sensitivity of internal objects is misjudged, and the API endpoint automatically converts client parameters into internal object properties.

The BOPLA vulnerability is apparent when allowing a user to access an object using an API endpoint, without validating that the user has access to the specific object properties they are trying to access.
New on the 2023 list and somewhat borrowed from the existing OWASP Top 10 2021 is API6:2023RC Server-Side Request Forgery.

Server-Side Request Forgery (SSRF) flaws occur whenever an API fetches a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN. Using modern concepts like Webhooks, file fetching from URLs, custom SSO, and URL previews, encourages developers to access an external resource based on user input, heightening the potential risk. Additionally, concepts like microservices based architectures expose control/management plane elements over HTTP using well known paths, making them an easier target.

API4:2023RC Unrestricted Resource Consumption borrows heavily from API4:2019 Lack of Resources & Rate Limiting, with a focus on protecting the available compute and storage resources to successfully serve legitimate API requests. By managing API limits around timeouts, processes, available memory, number of operations, etc., we can prevent an unfair distribution of resources.

API8:2023RC Lack of Protection from Automated Threats, these types of attacks have increased as commercial businesses move more and more to API based systems for eCommerce purposes. Traditional API Gateway and WAF based solutions like rate limiting fall short, as bot-net operators use more distributed approaches to launch their attacks. For these types of attacks, it remains paramount that we identify the malicious traffic and implement automated blocking actions to safeguard the API and allow normal business traffic to continue to flow.

Final Version Changes

The “new’ ‘ category is API6:2023 Unrestricted Access to Sensitive Business Flows, which is a lack of understanding which business flow your newly created API exposes. Some business flows are more sensitive than others, in the sense that excessive access to them may harm the business. For example;

A ride-sharing app provides a referral program – users can invite their friends and gain credit for each friend who has joined the app. This credit can be later used as cash to book rides.

An attacker exploits this flow by writing a script to automate the registration process, with each new user adding credit to the attacker’s wallet.

The attacker can later enjoy free rides or sell the accounts with excessive credits for cash.

So identifying the user identity and limiting access or timed access would be a good way to mitigate this type of attack.

The previous API8:2023RC Lack of Protection from Automated Threats was dropped or subsumed by API6:2023 as it mostly addresses a similar issue.

API9:2023 Improper Inventory Management has replaced API9:2023RC Improper Assets Management and matched wonderfully well with the Noname Platform capabilities as it turns out.

How Noname Security Addresses the OWASP Top 10

Noname Security provides the option to view your API issues through the lens of both the 2019 and 2023 versions. If you use the OWASP list as a guideline in prioritizing vulnerabilities, it will be easier to link real life findings to the framework.
Close