top of page
  • Writer's pictureMark van Vuuren

The API Security Top 10 List

Because of their flexibility, efficiency, and ease of use, application programming interfaces (APIs) are ubiquitous in today’s environment of app-driven innovation. APIs are used across industries, in both internal and external contexts. While APIs simplify life significantly for developers, they are also an attractive target for bad actors. APIs often expose sensitive personal data and application logic which can increase risk surface.

Additionally, the use of open source code often means developers aren’t fully aware of the vulnerabilities and risks in their code. Whether APIs were developed from or constructed with open-source code, the security vulnerabilities must be managed and mitigated to avoid exploitation by malicious actors.

In an effort to increase API security, the Open Web Application Security Project (OWASP) maintains a list of the top 10 security risks. Understanding and mitigating the security risks associated with APIs will allow developers to rapidly innovate without undue exposure.

1. Broken Object Level Authorization

Attackers can use broken object level authorization to create, read, update, or delete data objects without permission. If confidential or sensitive information such as personal identifiable information (PII) is exposed, this could cause a major breech. In order to fulfill their function, APIs may expose object identifiers that are needed to access resources, creating a wide attack surface.

To counter this risk, object level authorization checks should be implemented whenever a data source is accessed via input from a user. Security checks should prioritize locating API calls that misuse this vulnerability.

2. Broken User Authentication

Broken user authentication can be catastrophic since a single mistake can grant a hacker access to user accounts and restricted data and functionality. APIs frequently use access tokens embedded into individual API calls to implement authentication because multifactor authentication isn’t an option. The inherent challenges in API authentication make it a difficult task. Incorrectly implemented authentication measures give malicious actors an opportunity to exploit flaws or compromise tokens. Attackers can obtain weak or predictable tokens with brute force.

User authentication can break down in a variety of ways. Some common mechanisms of broken user authentication include:

  • Weak passwords

  • Credential stuffing where the attacker has a list of valid usernames and passwords

  • Failure to validate the authenticity of tokens

  • Including sensitive authentication details in the URL

  • Weak encryption keys

  • Unencrypted passwords

  • Long-lived tokens

Preventing broken user authentication can only be done with a multi-pronged approach that includes:

  • Access control for all sensitive data and functionalities

  • Long, randomized, unpredictable strings

  • Invalidation of tokens periodically and after logout, password reset, account recovery, and account deletion

  • Encrypted tokens

3. Excessive Data Exposure

Excessive data exposure occurs when an API reveals more information than necessary to a user. Some developers send a complete API response to a user’s browser because they assume the user can’t see it. However, if the sensitive information isn’t filtered out, anyone who visits a profile page can intercept the response and sensitive information about the user.

Information should be filtered so that only necessary data is returned to the user. Anything the user shouldn’t be allowed to access shouldn’t be sent. In general, only the minimum amount of information needed should ever be returned.

4. Lack of Resources and Rate Limiting

APIs that don’t restrict the number or frequency of requests from a client are vulnerable to performance issues and brute-force attacks. Performance issues related to a lack of resource and rate limiting can lead to denial of service (DoS). If there’s no limit on requests, hackers can brute-force a user password by submitting requests until they succeed.

A lack of rate limiting also increases the jjvulnerability of broken object level authorization since malicious actors can brute-force attack sensitive information. Hackers can also exploit this weakness to access confidential data in the event an API endpoint is leaking data.

Developers can avoid this security issue by setting an appropriate rate and resource limit. Each functionality may require a different limit. Functionalities that protect sensitive data should have lower rate limits. Establishing a benchmark for normal usage can help determine the appropriate rate and resource limits.

5. Broken Function Level Authorization

Broken function level authorization is a security weakness that occurs when an API allows unauthorized access to sensitive functions. This is similar to broken object level authorization but it applies specifically to functions rather than objects. Broken function level authorizations are caused by missing or misconfigured access controls.

Examples of broken function level authorization issues can include:

  • Pretending to be an admin

  • Deleting another user’s post

  • Security through obscurity

6. Mass Assignment

Mass assignment occurs when developers assign variables to multiple variables or object properties simultaneously. Many application frameworks use mass assignment as a way to simplify app development. However, by not limiting the object properties that users can modify, this vulnerability allows users to overwrite and create new object properties or variables. An attacker exploiting mass assignment could gain access to admin privileges. To avoid mass assignment weaknesses, developers should disable mass assignment in frameworks or use a whitelist to restrict assignments.

7. Security Misconfiguration

The security misconfiguration category covers a range of issues related to configuration. Some of the most common examples include:

  • Misconfigured HTTP headers

  • Unnecessary HTTP methods

  • Verbose error messages with sensitive information

  • Insecure default configurations

  • Incomplete or ad-hoc configurations

  • Open cloud storage

  • Permissive cross-ohyhrigin resource sharing (CORS)

8. Injection

Injection flaws occur when an application mistakenly reads untrusted data as code in a command line or query. This is a very common vulnerability and happens with SQL injections, OS command injections, and XML injections. Hackers can take advantage of injection flaws to trick an application into executing commands or accessing sensitive data without permission.

Injection vulnerabilities can be hard to find. Sometimes the malicious data isn’t used right away but can travel throughout the program where it can execute dangerous functions or an unprotected query. For every bit of untrusted data an application receives, it needs to find and neutralize risks throughout the entire system. Different parts of the application are vulnerable to different types of injections. Data that’s harmless when entered may cause damage in another area downstream.

Because injection flaws can be widespread and variable, several approaches are needed to combat them, including:

  • Validating untrusted data with a blocklist or allowlist

  • Parameterization by compiling the code of a command line before allowing user-supplied parameters

  • Escaping special characters, which is encoding them in user to be treated as data instead of special characters

9. Improper Assets Management

Because APIs expose more endpoints than other types of web applications, proper and updated documentation is critical. APIs have a lot of parameters, functionalities, and versions that affect endpoint behavior. Without proper documentation, it’s impossible to keep track of all of the security vulnerabilities related to the endpoints.

The best way to avoid security risks from improper assets management is to implement detailed documentation procedures. Documentation should cover all API hosts, versions, and endpoints, including all parameters and expected behaviors.

10. Insufficient Logging and Monitoring

Insufficient monitoring and logging allow attackers to go undetected or further attack systems. Most breaches take over 200 days to detect and are found by outside parties rather than by internal operations. Developers can detect abnormal usage by keeping consistent logs. Logging systems can include events such as:

  • Input validation failure

  • Authentication and authorization successes and failures

  • Application errors

  • API events related to sensitive functions like payment and account settings

Logging systems should include alert systems in case of a security incident so that the right team can identify and mitigate any risks.

Reducing API Security Risks

Security should be integrated throughout the entire development operations process. A devsecops approach to code security can identify defects in code and provide a complete understanding of security risks and how to remediate them.

The first step in reducing cybersecurity risks is creating an action plan based on security goals and risk analysis. Using tools such as Kiuwan’s Code Security (SAST) and Insights Open Source (SCA) within the devops environment lets organizations bake security into every step of the process.

Code Security works within most popular IDEs, including Eclipse, Visual Studio, IntelliJ IDEA, Phpstorm, Pycharm and Webstorm to let developers identify and analyze risks directly, providing feedback on best practices and giving contextual advice regarding remediation.

Insights Open Source helps manage open source vulnerabilities and ensure license compliance. Open source code is an integral part of almost every commercial software available today. These components expose businesses to risks from security vulnerabilities, obsolescence, as well as licensing and policy issues. Insights Open Source automates code management so developers can feel secure in their use of open source code.

Kiuwan is trusted by over 20,000 users across the globe, supports over 30 languages, and is compliant with the strictest security standards including OSWAP and CWE. All Kiuwan solutions can be integrated directly into the current software development lifecycle. Kiuwan provides an end-to-end application security testing platform with flexible licensing options. Whether developers are looking for one-time scans or continuous scanning with an SaaS or on-premise model, Kiuwan has a solution for every stage and stakeholder.

4 views0 comments


bottom of page