The first bullet of How to Prevent is "Use container-based solutions that make it easy to limit memory, CPU, ...". Containers is only one way of achieving limits, you could also use serverless technology such as Lambdas (even virtualisation / managed services on cloud allows us to limit these aspects too).

Therefore would recommend slight wording order shift to "Use a solution that makes it easy to limit memory, CPU ..., such as Containers / Serverless code)." This way the guidance has a wider coverage and not bound to a particular implementation approach / technology.

www.socialnetwork.com is a real website, should we have a fictional site instead? owasp.org? example.com?

in the “How to Prevent” section there is a bullet around Human detection. This prevention I don’t believe to be a viable option in an API as ultimately it is code which is the API consumer and thus Captcha or biometric controls aren’t going to work (and more at UI level). Yes you could do Captcha etc to better secure the UI web app / mobile app however it doesn't make any underlying API(s) more secure, i.e. it should be in Web Application OWASP recommendations instead of here.

Personally would recommend removal of this bullet as the following bullet around non-human patterns covers this in a manner which technically could be implemented. As well as time based patterns you could also consider putting something in around potentially secondary checks / validations / monitoring – e.g. [linked to your 2 example scenarios] limiting (or alerting) based on billing address / rate of referral crediting per account etc.

Hello there!

I will be more than happy to create a translation in Greek language. I'm a Software Engineer from Greece.

Hey!

I really appreciate your efforts and think this projects should be translated into as many languages as possible.
I'd like to provide a translation into german.

Cheers,
ch4rl353y

Lack of Protection from Automated Threats: Interesting. And better than Insufficient Logging and Monitoring. But the big problem is that APIs don't detect or block any kind of attack. This category shouldn't be limited to automated threats. And how would you tell anyway?

I would like to kindly ask you to open a new GitHub issue so that we can discuss your comment regarding "Lack of Protection from Automated Threats": we need more details from your side since your point was not that clear to us.

I believe that the lack of attack detection and protection mechanisms is a massive risk. There is absolutely no reason that web applications and web APIs shouldn't be able to detect attacks and respond accordingly. Apps/APIs shouldn't just tolerate attacks. Using parameterized queries, escaping, and sending 400 responses doesn't do anything to increase the burden on an attacker. Most apps/APIs will let an attacker attempt to exploit it forever.

My problem with this item is that it's too narrow. Why limit this to "automated threats." In the first place there's really no way to tell the difference between automated threats and manual attacks. And second, why does it matter? I encourage you to remove the "automated" limitation and expand the scope of this catgory to include all kinds of attacks.

While the How to Prevent section in the documentation calls out the use of allowlists, in practice it is often infeasible to "lockdown" network access due to the possibility of inadvertently blocking legitimate usage. In such cases, a deny list can help reduce attack surface.

Hi team! In the previous issue I suggested to add NoSQL injection attack scenario to the A8:2019 section.

Possible scenarios:
Scenario 1
We have MEAN stack application with basic CRUD functionality for operations with bookings.
Attacker managed to identify that NoSQL injection might be possible through bookingId query string parameter in delete booking request.
Request looks like:
DELETE /bookings?bookingId=678

On server side, application uses the following function to handle a request:

router.delete('/bookings', async function (req, res, next) {
  try {
      const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});
      res.status(200);
  } catch (err) {
     res.status(400).json({error: 'Unexpected error occured while processing a request'});
  };

Attacker intercepted the request and changed bookingId query string parameter as below:
DELETE /bookings?bookingId[$ne]=678
As a result, an attacker managed to delete another user booking.

Scenario 2
Application uses the MongoDB on a server side. Application developers forgot about proper data validation during implementation of log in functionality and it looks like following:

router.put('/auth/login', async function(req, res, next) => {
        const email = req.body.email;
        const password = req.body.password;

        const authenticatedUser = await Users.findOne({email: email, password: password});
        if (authenticatedUser)
           res.status(200).json({users: authenticatedUser});
        else
           res.status(400).json({error: 'Invalid email or password!'});
})

Attacker modifed login request payload and send it to the server. Modified request listed below:

PUT /auth/login

{"email":{"$ne":"[email protected]"},"password":{"$ne":"mypass234"}}

Request was completed successfully and an attacker got access to another user account.

Injection could cover case where validation is done but does not go far enough as well as an associated recommendation using this example below.

Scenario #
“An e-commerce API validates that a quantity input parameter in a shopping cart represented in JSON is an integer but stops short at validating that the value is not a negative value. Attacker uses this vulnerability to get zero-sum totals in a transaction:
POST /ecommerce/cart
{
items:[
{
id: 123456,
quantity: 1,
price: 200
},
{
id: 789123,
quantity: -2,
price: 100
}
]
}”

How to Prevent
“Validate incoming structured data using schemas (e.g. JSON schema) that include sufficient filters to only allow valid values for each input parameter.”

There's an ongoing pt-BR translation led by @raphaelhagi:

• Mailing list thread
• GitHub Fork

I think the section about broken authentication needs to be more clear, examples and suggestion follows:

The section about "is the API vulnerable?" needs to be more specific.

The API is vulnerable if:

• Authentication only relies on access tokens.

What does this really mean? Do we have any examples to clarify? Maybe the concept of "access token" needs to be defined in the introduction.

The API is vulnerable if:

• The same access token is valid for multiple APIs or API versions.

Needs to be more specific with regards to multiple APIs. Why is it broken if two different APIs are using the same auth service?

The API is vulnerable if

• Access tokens are tracked together with the source code on a version control system or hard-coded in the client.

I would not say that an API is vulnerable to broken authentication if it has bad secret management. The API is only vulnerable if the secrets in the source code is exposed.

Suggestion to other points that can indicate that an API is vulnerable to broken authentication:

1. If the authentication mechanism relies on random tokens, then the tokens should not be predictable.
2. If some value can be derived from the token itself, i.e.: in JWTs or where the value is an encrypted string, then it must be tamper-proof.

When it comes to the attack scenarios and the "how to prevent" section, I feel it would be nice to tie them together. Example: if you need to do API requests on behalf on a user from a mobile app, what is the best practice? Providing suggested "fix" or best practice alongside the attack scenarios will be much more helpful.

In the About, the project details https://www.owasp.org/index.php/OWASP_API_Security_Project
That URI results in 404
eg:

#48

Not sure if this has been discussed earlier, but I would consider proper integration tests as a preventive mechanism to broken access control. By writing tests for access controls you will get a guarantee that it will not happen, and you will (should) break the build and not deploy the vulnerable changes to production. This of course requires a thorough test suite, with all the "bad" cases covered, and also mechanisms to detect when new API endpoints are added without test coverage.

Assuming scores are based on the way previous top 10's have worked:

((Exploitability + Prevalence + Detectability)/3) * Technical impact

The entries aren't in the correct order

Hi everybody,

We want to translate API-Security to the Dutch language, any contributors are welcome!

Based on early feedback, a lack of consideration about JWT/JWE/JWS was pointed in A2:2019 Broken Authentication.

We would like to hear from the community whether this is a general feeling and request contributions on that matter.

@philippederyck maybe you can help us here?

Cheers,
Paulo A. Silva

Scenario #1 - This category shows a JNDI injection issue.
I don't believe a JNDI injection is a good example of a "security misconfiguration" issue. sure, sometimes there might be an unnecessary JNDI feature within some specific functionality, and it's really better to turn it off. However, in many other cases, the JNDI functionality is required, and cannot be simply removed. In this case, the best mitigation should follow the line of "Input Sanitization", Usage of "Parameterized Queries", and so on.
This is a much better example for Injection use cases (which is partially described in API10:2023 - Unsafe Consumption of APIs)

Hi,

Would you like the OWASP API Security Top 10 to be translated into French? If so, I would be pleased to do it and submit a PR when the translation is ready.

Hi, I found this resources super helpful and I would like non-english speakers to be able to benefit from this as well.

Do you have translation projects or do you accept translation PRs?
I see the sources are in 2019/en, so I guess I could create a 2019/es for a Spanish translation to work in.

Would that be something you'd want/like? I'm willing to make the Spanish translation, but let me know if there is an established way to contribute on this matter (maybe there is a separated repo for translations or you already have a Spanish version that I couldn't find.

Under the "Is the API Vulnerable?" section, two examples appear that IMO is out-of-scope for this category:

1. Interacts with other APIs over an unencrypted channel
   This conflicts with API7:2023 Security Misconfiguration - as this category clearly states (and rightfully so) that usage of HTTP instead of HTTPS is a configuration issue.
2. Does not limit the number of resources available to process third-party services responses
   This conflicts with API4:2023 Unrestricted Resource Consumption - as this category clearly states (and rightfully so :) that resource consumption can lead to a security issue.

I would, therefor, humbly recommend removing these indicators from the API10 category and integrating them where applicable in the other, more relevant categories.

Hi @PauloASilva ,

I was going through the 0xa8-lack-of-protection-from-automated-threats.md in the How To Prevent section I thought we could add the Geolocation restrictions.

For example, if I am providing my service in some countries, I can block the traffic from other countries where I don't serve. Doing this can eliminate a lot of risks.

"Does not properly validate and sanitize data gathered from other APIs prior to processing it or passing it to downstream components;"

Performing validation on input from a third party may cause an error which a user of the service cannot fix e.g.

1. user sends a request to the API to do something
2. API takes user data and makes request to third party API
3. response contains invalid data and results in error
4. user can't do anything to fix it

While input validation is important, the only truly valid schema is that applied by the third party, as it's their data.

Performing your own input validation might be useful to log issues, but blocking invalid data would be very complex.

The focus should be on sanitization at the point of use - parameterized SQL calls, output encoding for HTML etc

Hi, team! Thanks for the really great project. I would like to suggest the following changes to the "Lack of Resources & Rate Limiting" section:

• add information about improper query string params validation that could lead to DDoS attack against the server. I often face with a problem of absence of query string parameters validation, especially such parameters as size, 'page', .etc. Let's consider an example.
  Scenario 1
  We have a MEAN stack application that contains the users list on a UI. List of users can be retrieved from the server using a following query:
  /dashboard/users?page=1&size=100
  There are limitation on maximum number of users per page (on UI side) - 200 users. An attacker changes the size parameter in order to retrieve large number of users, for example 200 000 or more and it causes performance issues.

Mentioned scenario can be also used to provoke Integer Overflow or Buffer Overflow errors.
One more suggestion:

• add an attack scenario example for the NoSQL injection.
  But I think it can be discussed in the separate issue.

I think the title „Improper Data Filtering“ is a bit misleading as it sounds a bit too much like input filtering.

How about „Excessive Object Property Exposure“?

By the way, I love the idea of this project. Great job!

Why is this a separate item? Assuming an API consumes data from an untrusted API, isn't it only an issue if one of the other problems occurs? Put another way.... why isn't unsafe consumption of USER data a more important issue? Because it's already covered.

(Source: issue #77 by @planetlevel)

At a minimum, I would love to know why the following categories from the main OWASP T10 don't apply to APIs:

* Injection
* Cryptographic Failures
* Insecure Design
* Vulnerable and Outdated Components
* Software and Data Integrity Failures

(Source: issue #77 by @planetlevel)

Hello! I refer to Pull Request #28 to include 0xa10-multiple-verbs-exposure.md

There is an urgency to include this as many APIs are woefully vulnerable to this vulnerability. Please let me know when we can merge this to the master branch?

_By default, APIs do not restrict/limit the HTTP Verbs/Methods by which they can be accessed. In rare occasions, depending on how secure the server was or is setup, a sophisticated attacker may be able to use HEAD to leak information/secrets on the server.

API developers should ensure that APIs they build can only be accessed by the prescribed and specified HTTP verbs. All other verbs should not be permitted.

Nathan Aw (Singapore)_

Authorization: Why are there 6 of 10 issues related to authorization. 1, 3, 4, 5, 8, and 10 are all problems with authorization. Can we combine these? It doesn't make sense to break these out and bump critical problems like Injection, crypto failures, and insecure libraries. All of which are rampant and highly dangerous in APIs.

(Source: issue #77 by @planetlevel)

Hi, team! Thanks for the great project. I think it would be useful to add more information about different tools that can be used to test an application and detect security issues. For example, Arachni, ZAP, Burp Suite, .etc. One more thing that would be useful for application developers, QA engineers, security experts - links or examples of possible payloads that can be used to test an application API. There is a cool repository, called PayloadAllTheThings that contains a lot of payload examples to use during a security testing process. I can provide more information about tools and useful sources if it needed.

Best regards,
Ihor

Hey!

First of all thanks for this outstanding repository about API security.
I would be happy to contribute to the translation of this repository into Turkish.

API2:2019 Broken Authentication was renamed Broken User Authentication.

tuxnam's comment regarding Broken Authentication made us realize that the whole section was about User Authentication and its title should reflect this fact to avoid misunderstandings.

Broken Authentication was too broad since most APIs have to handle either a) API clients authentication and b) User Authentication (by API clients on users' behalf).

This change was made in the develop branch and we will be waiting for comments. After the discussion, it should be released.

Cheers,
Paulo A. Silva

These categories are significantly different from the data from the hundreds of thousands of APIs that my company assesses and protects. This could give rise to suspicions that these categories aren't based on real world data. Could you provide a reference to the data set used and the data science performed?

At a minimum, I would love to know why the following categories from the main OWASP T10 don't apply to APIs:

• Injection
• Cryptographic Failures
• Insecure Design
• Vulnerable and Outdated Components
• Software and Data Integrity Failures

Authorization: Why are there 6 of 10 issues related to authorization. 1, 3, 4, 5, 8, and 10 are all problems with authorization. Can we combine these? It doesn't make sense to break these out and bump critical problems like Injection, crypto failures, and insecure libraries. All of which are rampant and highly dangerous in APIs.

SSRF: I'm glad to see SSRF show up here, mirroring the main OWASP T10.

Lack of Protection from Automated Threats: Interesting. And better than Insufficient Logging and Monitoring. But the big problem is that APIs don't detect or block any kind of attack. This category shouldn't be limited to automated threats. And how would you tell anyway?

Unsafe Consumption: Why is this a separate item? Assuming an API consumes data from an untrusted API, isn't it only an issue if one of the other problems occurs? Put another way.... why isn't unsafe consumption of USER data a more important issue? Because it's already covered.

Hello everybody,

We want to translate API-Security to Persian language.
Is there any contributions guide for this work?

on API8 "how to prevent" section rate limiting should be specified, there 2 kinds of rate limiting in practice :

• appliance / proxy / load balancer rate limit (network level)
• application rate limit (API / software level)
  (for instance if a node of you API can't handle more than X requests per minute you could rate limit globally to X requests per
  minute on all endpoints of the API)

Quote From Neil Madden:
Even if you enforce rate-limiting at a proxy server, it is good security practice to also enforce rate limits in each server so that if the proxy server misbehaves or is misconfigured, it is still difficult to bring down the individual API servers. This is an instance of the general security principle known as defense in depth, which aims to ensure that no failure of a single mechanism is enough to compromise your API.

Hey there,
More than happy to do translation in hindi. I'm developer from India

In prevention it states - "If possible, avoid using functions that automatically bind a client's input into code variables, ..."

If a schema is used for incoming data then using a function to map that schema data onto the real objects is actually beneficial. Automatic binding of the complete object would be bad, but just the schema data is good - assuming the schema is well thought out of course!

Hello,

I have a small question about the release candidates. Are these the final categories that will be in the final release?

Thanks

Currently the numbering scheme is A1:2019, A2:2019 etc. which is identical to the way OWASP Top 10 is doing it. Their latest entries are A1:2017 to A10:2017. This could cause confusion such as people might assume that the OWASP Top 10 had a 2019 release when only seeing references to A1:2019 etc. somewhere.

For comparison, the Docker Top 10 (https://github.com/OWASP/Docker-Security) avoid this by using D1, D2 etc. as their numbering scheme. (They lack the year of document release though.)

Recommendation

As A is taken by OWASP Top 10 and no other single-letter comes to mind change numbering scheme into API1:2019 to API10:2019.

Hey!

I really appreciate your efforts and think this projects should be translated into as many languages as possible.
I'd like to provide a translation into Arabic .

Thanks
Malek aldossary

We want to translate API-Security into Bahasa, any contributors are welcome!

The Portuguese (Portugal) translation is underway, led by @PauloASilva:

• GitHub fork
• Translation branch

Guidelines

• The TOP 10 section names should remain in English.
  This will help readers to find further documentation about the issue.
• Whenever possible, hyperlinks point to OWASP contents should be updated to the new WebSite.

We came across a real-world example of a security misconfiguration at a customer’s API which is easy to understand and is relatable:

“A team is tasked with implementing a REST API with associated access control rules. At implementation time, the team implements a thin REST API layer on top of a legacy XML service (SOAP to REST). An attacker aware of this legacy service sends requests with content-type of this legacy service to new publicly available REST endpoint. At the API entry point, the service detects the legacy format in the request and skips the new REST layer along with associated access control rules. API calls are passed to legacy XML service without any authentication or access control rules applied.”

Based on early feedback, a lack of consideration about CORS misconfiguration was pointed in A7:2019 Security Misconfiguration.

We would like to hear from the community whether this is a general feeling and request contributions on that matter.

We should keep in mind that we're addressing APIs in general and not on a browser-specific context.

@philippederyck maybe you can help us here?

Cheers,
Paulo A. Silva

JSON Parameter Pollution is a common issue I find in API and not that checked upon often, which I feel can be added in the list

We have received some comments and feedback from CISOs and other non-hands-on
managers about our, and other, top 10 guides. The main thing they are usually
missing is an action item for them, in the form of "how to detect".

In the feature/how-to-detect branch you'll find a new "How to Detect"
section on each Top 10 weakness.

We would like to have your comments and contributions to review and improve
them. Bear in mind that we SHOULD NOT mention any specific product, but only the
technology.

Cheers,
Paulo A. Silva

Hi Team,

Glad to see this project, I am an engineer in this area, I could contribute to the Chinese version.

Hi team,

I have noticed whilst going through the new API10 guidelines that there is no dedicated page for injection-based attacks. I realise going into 2023, pure injection-based are becoming less common, but I believe it should still be prevalent enough to test for these issues?

Is it intended for the 2023RC that the injection category is removed?

The initial table (middle raw) states that "Detection relies on proper logging and monitoring.".
Without going into specific vendor solutions and detections (which I do not believe should be encouraged by OWASP in general), several other tactics could mitigate this issue.
One example would be to baseline the common Request types accepted by an endpoint and look for deviations. And yes, you could flag this as "Monitoring," but this is not the first thing you think about when thinking about "monitoring".
My point here is that:

1. Either OWASP decides to elaborate more regarding the specific solutions, in which case this statement should be expanded to be more inclusive and include more tactics for detection (IMO not such a good option, since it can be endless and might create an unnecessary bias to this solution or the other)
2. Remove this statement altogether, as it is already covered in the "How to Prevent" section

Hello @PauloASilva

Information about labs and frameworks that can be used to demonstrate OWASP Top 10 API security will be beneficial for the community. Please let me know if I can contribute to build up such labs under OWASP organization.

Thanks