As always five of them are Authentication, Authorization, Injection, Misconfiguration and Insufficient Logging+Monitoring (The last 2 are easily avoidable)
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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. |
https://www.owasp.org/index.php/OWASP_API_Security_Project
