Stay up to date
Stay up to date with the latest threat reports, articles & mistakes to avoid.
Simple, yet important content.
No salesy pitches and all that, promise!
What is OWASP API Security Top 10?
The OWASP, stands for The Open Web Application Security Project, is a non-profit foundation that works to improve application security by listing guidance such as top OWASP API security vulnerabilities and their prevention. Through community-led projects globally, it is a great source for tools, resources, education & training for developers and technologists to secure the web and mobile applications. This community has also produced some of the best testing guides, cheat sheets, methodologies and lot of community work for which all of us are grateful.
OWASP API (Application Programming Interface) security is a project aimed at helping organisations from deploying insecure APIs. APIs are fundamental components of today’s app-driven internet life. Whether it’s banks, online retailers, transportation or consumer services, APIs are a critical part of modern SaaS, mobile and cloud technologies infrastructure. APIs are the most common ways today defining how microservices and containers communicate like systems, applications and other entities.
If new software (mobile computing, cloud computing) is affecting the world, API security is affecting this software.
Let’s look at the OWASP Top ten list of API security vulnerabilities:
- Broken Object Level Authorization
- Broken User Authentication
- Excessive data exposure
- Lack of resources and rate limiting
- Broken Function Level Authorization
- Mass assignment
- Security misconfiguration
- Improper assets management
- Insufficient logging and monitoring
This article presents each of these API vulnerabilities with API attack examples and measures around how to prevent these attacks. This API can also be used as API security checklist within application teams to help produce secure code. Web applications and API penetration testing services often include OWASP top 10 as part of the testing methodology.
Broken object level authorization
This attack, also known as Insecure Direct Object Reference (IDOR) vulnerability, is amongst the topmost API security risks. Improper access controls for assets accessible from the internet make it an easy target for threat actors. This is largely due to the lack of strict authorisation controls implementation or no authorisation controls. This issue impacts in varied ways, from data disclosure to full account takeover.
Use case for broken object level authorization
For example, an API call with parameters using value (ID) associated with the resource i.e.
A threat actor attempts different usernames guessing through correct accounts
and so on. If the API does not check current user permissions and allows the current call through the current user shall access Lisa and Peter user profiles. Based on the user permissions, the resulting access would relate to horizontal or vertical privilege escalation vulnerability.
Another example is sending POST requests to update data on the backend. In this case, the following JSON payload is sent to update user account details:
"user": "[email protected]",
Now, if we can change the userID to another userID and were able to update other user details, that is another example of broken object level authorization vulnerability.
How to prevent broken object level authorization?
The following mitigations should act as a defensive measure against broken object level authorization vulnerability.
- A stricter access control policy coupled with the use of random and unpredictable user ID values that are hard to guess.
- Check authorization for each client request access to backend.
Broken user authentication
Insecure or missing protection mechanisms for API endpoints causes broken user authentication flaws. Due to the way authentication mechanisms work, an authentication endpoint being always exposed makes it an attractive target for cyber criminals. Threat actors can exploit this vulnerability to steal sensitive data, take over accounts, or impersonate users.
How to prevent broken user authentication?
Implement stricter protection including but not limited to factors such as strong credential encryption, failed login attempts limit, authentication token validation. OAuth has been the de facto standard for securing APIs for both authentication and authorization mechanisms. For Java, using encrypted JWT tokens ensures identity and user characteristics are not easily susceptible to attacks.
Excessive data exposure
APIs disclose varied types of data based on the who is requesting. This purpose of what information will be served, and to whom this will be served are the core concepts while designing an API. Insecure implementation or lack of implementation of data filtering leads to disclosing more than required information. Data exposure issues are a common sight, ranging from technology or version information disclosure to high-risk issues related to user preferences or account information.
How to prevent API excessive data exposures?
Threat model the information based on how data flows from the endpoints to the client and vice versa and review the data filtering. Never process user input on the server-side without any validation.
Lack of resources and rate limiting
Threat actors can easily abuse an API leading it to consume available resources and making the service unavailable to legitimate users. This could lead to Denial of Service (DoS) attacks.
Public APIs are often the target as common misconception that there is no authentication removes risks to the application applies commonly. This is also an issue that could be exploited using multiple attack vectors such as brute force attacks, credential stuffing attacks, user enumeration, or other fuzzing techniques. Bots and other automated techniques could end up using the victim’s precious computing resources.
How to prevent?
Implement size and rate limits such as number of items to be required in a single API request, or maximum number of records that can be retrieved.
Broken function level authorization
Deploying unique strategies for different services yields complexity, that leads to vulnerabilities or increased attack surface. Every API function call should require authorization to verify that the user requesting the data is authorized to send the request on those objects. This flaw is used by threat actors to find administrative functions that may be hidden otherwise and allow access to higher privilege functions.
How to prevent?
Keep it simple. Deploy a standard approach to authorize client requests and avoid function-level authorization. Deny all access by default, and allow explicitly.
Mass assignment issue occurs where the lack of properties filtering allows exposure of internal variables or objects. Due to lack of restrictions, an endpoint may provide access to other properties outside the authorized scope allowing a threat actor to modify objects related to those parameters. This also illustrates the API security risk how direct mapping client inputs to internal variables can be exploited by unauthorised users.
How to prevent?
Define properties that a client can access and avoid direct mapping of client inputs to internal variables or object names.
Discuss your concerns today
Security misconfiguration vulnerabilities arise due to use of insecure configuration or misconfiguration in the web application components. This could be either application framework, web server hosting the application or third party libraries in use.
Exploiting configuration weakness in an application leads to security misconfiguration attacks.
What causes security misconfiguration attacks?
Enterprise web applications are built by multiple parties (database admins, system developers, middleware teams) whether internally or group of companies (outsourced vendors, hosting providers, etc). Security issues often arise due to lack of security oriented cohesion between these teams. Whether it is down to insecure coding practices or lack of secure hardening of databases, or other issues – these all fall into misconfiguration checklist. Security misconfiguration impact has far reaching consequences including but not limited to high risk vulnerabilities such as data leakage (AWS S3 or Azure blob leakages), default accounts leading to compromises up to database compromise.
Some of the examples of security misconfiguration vulnerabilities are:
- Lack of patch deployment
- Insecure encryption (TLS) configuration
- Default accounts or passwords
- Insecure coding practices
- Default configuration allowing access to unwanted/unused features
- Missing security headers
- Verbose error messages
How to prevent security misconfiguration?
Perform regular penetration testing of your web application and API. Perform regular secure hardening reviews against the hosting server. These measures would act as inherent API attack prevention measures built into internal SDLC (software development life cycle).
Similar to web application injection attacks, all injections i.e., OS Command injection, SQL, NoSQL, LDAP injections fall under one of the notable API security risks. Due to the lack of strict input validation on the server-side, malicious input can make way as a query or command to enumerate backend information.
How to prevent Injection attacks?
The core concept behind injection flaws is the lack of input validation and sanitisation of data used by the application. Any input request that contains parameters as input can be vulnerable to a code injection flaw. This could be an OS code injection, SQL injection or simple script injection based on the underlying code of vulnerable function in use.
API attack prevention measures against SQL injection attacks are effective by separating data from commands and queries. Use of prepared statements (with parameterised queries) is how developers should write database queries. This allows to first define all the SQL code and then pass each parameter to the query, therefore, distinguishing between code and data irrespective of user input (malicious or legit).
Improper assets management
Just like other assets in a business, APIs go through a lifecycle and lack of asset management is related to legacy security vulnerabilities. By not retiring older versions, APIs expose more endpoints, exposing endpoints that are no more needed, not known or forgotten by the teams. This increases attack surface due to older and newer API versions running alongside.
How to prevent?
Documentation is an important step towards maintaining assets information. There should be clear segregation at the user, network and functional level between production and non-production environments. Review and retire older versions that are no more required.
Insufficient logging and monitoring
Logging and monitoring of data is a vital step for audit trails and incident response teams. Due to the lack of logging and monitoring controls, a threat actor finding difficult to attack the victim API has more time by his side, that may lead to bigger and high impact attack. This can be easily avoided by logging and analysing the suspicious events early in the attack chain due to stricter monitoring processes. Unfortunately, this is one of the reasons data breaches go unnoticed early in the attack stage.
How to prevent?
Review and ensure all necessary log levels are in place for all API endpoints. Deploy a monitoring solution to continuously monitor logs for APIs and infrastructure. Ensure that incident response process is defined and shared with teams to be prepared for any eventuality.
As can be seen above, while a few issues are common to the OWASP Top 10 application security risks, APIs are an opportunity for threat actors leading to sensitive data. API security testing is one of our offerings under web application penetration testing services. Our team of skilled security experts with proven industry experience ensure comprehensive coverage for web application risks, especially issues such as business logic flaws, business contexts that are often missed by automated scanners or less experienced consultants. Get in touch if we can help with your security concerns.