OWASP API Security Project - Revision history

PauloASilva: /* Contributors */

2020-01-06T10:39:47Z

‎Contributors

PauloASilva: /* Quick Links */

2020-01-02T19:27:56Z

‎Quick Links

PauloASilva at 19:26, 2 January 2020

2020-01-02T19:26:56Z

PauloASilva: /* API Security Top 10 Release Candidate is Here! */

2019-12-27T09:49:45Z

‎API Security Top 10 Release Candidate is Here!

PauloASilva: update list of contributors

2019-12-27T09:49:29Z

update list of contributors

PauloASilva: /* News */

2019-12-27T09:48:45Z

‎News

PauloASilva: Update with 2019 Stable version contents

2019-12-27T09:47:13Z

Update with 2019 Stable version contents

Inon at 23:48, 23 October 2019

2019-10-23T23:48:24Z

PauloASilva: change numbering scheme

2019-10-07T09:19:55Z

change numbering scheme

PauloASilva: add link to user page

2019-10-04T11:12:19Z

add link to user page

@@ Line 120: / Line 120: @@
 ==Contributors==
-divyachawla, anotherik, bkimminich, caseysoftware, Chris Westphal, dsopas,
+divyachawla, Abid Khan, Adam Fisher, anotherik, bkimminich, caseysoftware, Chris Westphal, dsopas, DSotnikov, emilva, ErezYalon, flascelles, Guillaume Benats, IgorSasovets, Inonshk, JonnySchnittger, jmanico, jmdx, Keith Casey, kozmic, LauraRosePorter, Matthieu Estrade, nathanawmk, PauloASilva, pentagramz, philippederyck, pleothaud, r00ter, Raj kumar, Sagar Popat, Stephen Gates, thomaskonrad, xycloops123
 = Join =

@@ Line 62: / Line 62: @@
 [https://github.com/OWASP/API-Security GitHub]
-[https://github.com/OWASP/API-Security/raw/master/2019/en/dist/owasp-api-security-top-10.pdf PDF version of API Security Top 10 2019]
+[https://github.com/OWASP/API-Security/raw/master/2019/en/dist/owasp-api-security-top-10.pdf API Security Top 10 2019 (PDF)]
 == News ==

@@ Line 13: / Line 13: @@
 API Security focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs).
-==API Security Top 10 Release Candidate is Here!==
+==API Security Top 10 is Here!==
 Here is a sneak peek of the 2019 version:
@@ Line 62: / Line 62: @@
 [https://github.com/OWASP/API-Security GitHub]
-[https://github.com/OWASP/API-Security/raw/master/2019/en/dist/owasp-api-security-top-10.pdf PDF version of API Security Top 10]
+[https://github.com/OWASP/API-Security/raw/master/2019/en/dist/owasp-api-security-top-10.pdf PDF version of API Security Top 10 2019]
 == News ==

@@ Line 21: / Line 21: @@
 | API1 || Broken Object Level Authorization || APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
 |-
-| API2 || Broken User Authentication || AAuthentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.
+| API2 || Broken User Authentication || Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.
 |-
 | API3 || Excessive Data Exposure || Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.

@@ Line 122: / Line 122: @@
 ==Contributors==
-* David Sopas
+divyachawla, anotherik, bkimminich, caseysoftware, Chris Westphal, dsopas,
-* Chris Westphal
+DSotnikov, emilva, ErezYalon, flascelles, IgorSasovets, Inonshk,
 = Join =

← Older revision		Revision as of 09:48, 27 December 2019
Line 67:		Line 67:

	== News ==		== News ==
		+
		+	=== Dec 26, 2019 ===
		+
		+	OWASP API Security Top 10 2019 stable version release.

	=== Sep 30, 2019 ===		=== Sep 30, 2019 ===

@@ Line 15: / Line 15: @@
 ==API Security Top 10 Release Candidate is Here!==
-The RC version is finally ready and was presented during Global AppSec DC 2019 and Global AppSec Amsterdam 2019. Links to the presentations can be found in the News section on the right.
+Here is a sneak peek of the 2019 version:
 {| class="wikitable"
 |-
-| API1 || Broken Object Level Authorization || APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.
+| API1 || Broken Object Level Authorization || APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
 |-
-| API2 || Broken Authentication || Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.
+| API2 || Broken User Authentication || AAuthentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.
 |-
 | API3 || Excessive Data Exposure || Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
@@ Line 32: / Line 31: @@
 | API6 || Mass Assignment || Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
 |-
-| API7 || Security Misconfiguration || Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
+| API7 || Security Misconfiguration || Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
 |-
-| API8 || Injection || Injection flaws, such as SQL, NoSQL, Command Injection, etc. occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
+| API8 || Injection || Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
 |-
 | API9 || Improper Assets Management || APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

@@ Line 24: / Line 24: @@
 | API2 || Broken Authentication || Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.
 |-
-| API3 || Excessive Data Exposure || Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Without controlling the client's state, servers receive more-and-more filters which can be abused to gain access to sensitive data.
+| API3 || Excessive Data Exposure || Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
 |-
 | API4 || Lack of Resources & Rate Limiting || Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.

@@ Line 20: / Line 20: @@
 {| class="wikitable"
 |-
-| A1 || Broken Object Level Authorization || APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.
+| API1 || Broken Object Level Authorization || APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.
 |-
-| A2 || Broken Authentication || Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.
+| API2 || Broken Authentication || Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.
 |-
-| A3 || Excessive Data Exposure || Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Without controlling the client's state, servers receive more-and-more filters which can be abused to gain access to sensitive data.
+| API3 || Excessive Data Exposure || Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Without controlling the client's state, servers receive more-and-more filters which can be abused to gain access to sensitive data.
 |-
-| A4 || Lack of Resources & Rate Limiting || Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
+| API4 || Lack of Resources & Rate Limiting || Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
 |-
-| A5 || Broken Function Level Authorization || Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
+| API5 || Broken Function Level Authorization || Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
 |-
-| A6 || Mass Assignment || Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
+| API6 || Mass Assignment || Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
 |-
-| A7 || Security Misconfiguration || Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
+| API7 || Security Misconfiguration || Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
 |-
-| A8 || Injection || Injection flaws, such as SQL, NoSQL, Command Injection, etc. occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
+| API8 || Injection || Injection flaws, such as SQL, NoSQL, Command Injection, etc. occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
 |-
-| A9 || Improper Assets Management || APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
+| API9 || Improper Assets Management || APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
 |-
-| A10 || Insufficient Logging & Monitoring || Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
+| API10 || Insufficient Logging & Monitoring || Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
 |}

@@ Line 55: / Line 55: @@
 * [[User:Inon|Inon Shkedy]]
 '''Main Collaborator'''
-* Paulo Silva
+* [[User:PauloASilva|Paulo Silva]]
 == Quick Links ==