The Significance of API Security

The OWASP API Security Project aims to provide value to software developers and security assessors by highlighting potential risks associated with insecure APIs and demonstrating methods to mitigate these risks. To achieve this objective, the project is establishing and upholding a Top 10 API Security Risks document, along with a documentation portal for best practices when creating or assessing APIs.
The project came to be because, while developers or information security consultants engaged in their roles, many were encountering APIs as components of their projects. Although some resources were available to aid in the creation and evaluation of these projects (such as the OWASP REST Security Cheat Sheet), there was a lack of a comprehensive security initiative designed to support members of the community involved in building, testing, and defending against API vulnerabilities.

Understanding the API Security Risks

The core of the OWASP API Security Top 10 report is the identification and detailed analysis of ten critical API security risks. Each risk is assessed based on factors like exploitability, prevalence, detectability, technical impact, and business impact. have a look at the assessment to get more details on the scoring for each risk.

What's changed (tl;dr)

The security landscape is changing all of the time so I thought it would be good to compare how things have moved on since the 2019 edition for those who are generally aware of API security issues. Afterwards, there is more detail on each of the risks on the report, where we've aimed to give a summarised view of each issue to help you have a better idea if you think you may be at risk yourself, without having to read and understand the whole report.

The first and most noteworthy change is that injection has dropped off the list. Injection flaws, such as SQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query and tricks it into doing things without proper authorisation. It's not really made clear why this has dropped but it there has been much attention on injection issues over the last few years due to high-profile vulnerabilities being found in common applications and libraries. I have noted that injection is covered as potential approaches in other security risks, so the survey may have considered it more of way someone may exploit a particular risk.

Previous Excessive Data Exposure and Mass Assignment risks have been combined together, focusing on the common root cause: object property level authorisation validation failures.

More emphasis on resource consumption, over focusing on the pace they are exhausted, and recategorised as Unrestricted Resource Consumption. Giving more clarity on how successful attacks can lead to Denial of Service and an increase of operational costs.

A new category has been added called, "Unrestricted Access to Sensitive Business Flows". It aims to address the lack of a holistic view of APIs and addresses new threats, including most of those that can be mitigated using rate limiting.

"Unsafe Consumption of APIs" was added to address new awareness into how attackers have started looking at compromising integrated services which a targeted API is using, instead of hitting the APIs of their target directly. This has significant concern and comes straight in a number 6

Software developers should focus on improving their awareness and education about API security. Whilst also ensuring they have a good understanding of the security requirements and associated architecture security around these risks.

Platform engineers can help in this process by understanding and implementing threat models, as well as facilitating continuous security testing for the development teams

The API Security Risks

In this section we're summarising each of the issues to hopefully give the reader a quick view on whether they could be vulnerable and some preventions that can be checked quickly to see if you're performing these actions. If not, you may want to add these to your backlog.

Broken Object Level Authorisation

With this issue attackers exploit API endpoints that are vulnerable by manipulating the ID of an object (object being some kind of resource in your app - this could be representation of a user's record in a database, for example), leading to unauthorised access to sensitive data. Such attacks are common and give access to other users' objects which could lead to full account takeover.

What to check:

• Ensure that session management is secure.
• Implement RBAC to define roles and assign users to specific roles based on their responsibilities.
• Consider using ABAC, which allows you to define access policies based on attributes.
• Validate and sanitise user inputs, especially object IDs, to prevent injection attacks or unauthorised object manipulation.
• Implement comprehensive logging and audit trails to monitor and track access to sensitive objects. Log all access attempts, including successful and failed ones.
• Follow the "default deny" principle, which means that access is denied by default unless explicitly granted. Avoid granting broad permissions.

Broken Authentication

This is an issue where misconfigured authentication mechanisms are exploited which can allow attackers to compromise authentication tokens or impersonate other users, resulting in potential data breaches and identity theft.

What to check:

• Implement well-established and secure authentication methods, such as OAuth 2.0, OpenID Connect, or SAML, based on the specific requirements of your application.
• Ensure that API tokens and secrets are securely stored in a secure system like Secret Manager or KMS and not exposed in client-side code or public repositories.
• Consider implementing passwordless authentication methods, such as one-time passwords (OTPs) or email-based verification, to reduce reliance on traditional passwords.
• Avoid exposing whether a user account exists through error messages. Always use generic error messages for login failures.
• Provide users with the ability to log out securely and invalidate their session tokens.
• Train your development team on secure authentication practices and the importance of protecting user credentials.

Broken Object Property Level Authorisation

Broken Object Property Level Authorisation combines the vulnerabilities addressed in Excessive Data Exposure and Mass Assignment from the 2019 report and focusses instead on the lack of or improper authorisation validation at the object property level (think of a user's email address on a "user" object). This vulnerability can lead to unauthorised parties gaining access to sensitive information or manipulating data.


What to check:

• Ensure that users have access to only the object properties they should access.
• Avoid using generic methods to return all object properties. Cherry-pick only the specific properties to return.
• Do not automatically bind client input into code variables, internal objects, or object properties. Ensure they're safe before assigning them.
• Allow changes only to object properties that should be updated by the client. I.e. some properties should not be able to be changed.
• Implement a schema-based response validation mechanism to enforce data returned by all API methods. Schemas are easy to consume and compare and give software and security engineers a clear structure to work with/
• Keep returned data structures to the minimum required according to business/functional requirements.

Source: APIsec

Unrestricted Resource Consumption

This risk identifies APIs that do not limit client interactions or resource consumption behind the scenes. Exploitation of this vulnerability can lead to DoS due to resource starvation and increased operational costs (e.g., higher CPU demand, increased cloud storage needs). In today's Cloud-based pay-as-you-go model, this issue can cripple businesses by pushing operational expenditure through the roof.

What to check:

• Utilise solutions like Containers or Serverless code that make it easy to limit memory, CPU, restarts, file descriptors, and processes.
• Define and enforce maximum data size for all incoming parameters and payloads, including strings, arrays, and upload file sizes.
• Implement rate limiting based on business needs to control how often clients can interact with the API within defined timeframes.
• Restrict how many times a client/user can execute a specific operation, such as validating an OTP or requesting password recovery.
• Implement server-side validation for query string and request body parameters, especially those that control the number of records returned in responses.
• Configure spending limits for all service providers/API integrations.
• Set up billing alerts when spending limits cannot be configured.

Broken Function Level Authorisation

Exploitation of this risk involves sending legitimate API calls to endpoints that should not be accessible and allow attackers unauthorised access to important functionality which may lead to data disclosure, data loss, or data corruption.

What to check:

• Implement consistent and easy-to-analyse authorisation mechanisms.
• Deny access by default to all resources and require explicit grants to specific roles.
• Regularly review API endpoints for authorisation flaws.
• Ensure administrative controllers inherit from an administrative abstract controller with authorisation checks.
• Implement authorisation checks for administrative functions inside regular controllers.

Unrestricted Access to Sensitive Business Flows

This is where attackers manually identify what resources (e.g. endpoints) are involved in the workflow of a targeted API and how they work together so that they can bypass important steps. Exploitation of this vulnerability may not always have a direct technical impact but can harm the business in various ways, such as preventing legitimate users from purchasing products or causing economic inflation within a system (e.g., a game's virtual economy).

What to check:

• Identify business flows that could harm the business if excessively used. Understand the potential financial, operational, and repetitional risks associated with these flows.
Engineering Layer:
• Implement protection mechanisms to mitigate business risks, such as rate limiting, device fingerprinting, and human detection. These measures help maintain the integrity of sensitive business flows and prevent exploitation by malicious actors.

Server Side Request Forgery (SSRF)

Modern concepts in software development encourage developers to make secondary requests to third party URLs provided by the user. Without proper validation of those URLs, an attacker can manipulate the application and make it act as a proxy for some other malicious activity. This can cause significant financial losses, operational disruptions, data exposure, and reputation damage.

What to check:

• Isolate the resource fetching mechanism in your network, primarily designed for retrieving remote resources, and prevent access to internal ones. Limit the scope of accessible resources.
• Whenever possible, implement allow lists for:
  •  Remote origins that users are expected to download resources from (e.g., Google Drive, Gravatar, etc.).
  •  URL schemes and ports that are considered safe.
  •  Accepted media types for a given functionality, ensuring that only safe types are processed.
• Disable HTTP redirections to prevent attackers from manipulating the request's destination through redirects.
• Utilise a well-tested and maintained URL parser to parse and validate URLs, avoiding issues caused by URL parsing inconsistencies.
• Validate and sanitise all client-supplied input data, especially URLs, to ensure that they conform to expected patterns and are safe for use in requests.
• Do not send raw responses to clients, especially if the responses contain sensitive information. Consider filtering and sanitising responses before sending them to clients.

Security Misconfiguration

Bit of a broad one here. Misconfiguration can happen in all sorts of places from the network layer to the application layer. They can lead to unauthorised access, data exposure, server compromise, repetitional damage, financial losses, and operational disruptions. Preventive measures include encryption, HTTP verb control, CORS policies, security headers, and consistent request processing. Proper configuration management is crucial.

What to check:

• Implement a repeatable hardening process for your API stack, ensuring a securely configured environment that can be deployed easily.
• Regularly review and update configurations across the entire API stack, including orchestration files, API components, and cloud services permissions (e.g., object storage buckets).
• Employ automated processes to continuously assess the effectiveness of your configurations and settings in all environments.
• Ensure that all API communications, whether internal or public-facing, occur over an encrypted communication channel (TLS).
• Specify which HTTP verbs each API can be accessed by, disabling all other unnecessary verbs (e.g., HEAD).
• For APIs accessed by browser-based clients (e.g., WebApp front-end), implement a proper Cross-Origin Resource Sharing (CORS) policy and include relevant Security Headers.
• Restrict incoming content types/data formats to those that align with your business and functional requirements.
• Ensure all servers in the HTTP server chain (e.g., load balancers, proxies, back-end servers) uniformly process incoming requests to prevent desync issues (where attacker manipulate different ways in which these systems process requests).
• Schemas come in useful here as well. Where applicable, define and enforce API response payload schemas, including error responses, to prevent the exposure of sensitive information like exception traces to potential attackers.

Source: Kinsta

Improper Inventory Management

Outdated documentation complicates the process of identifying and addressing vulnerabilities, while the absence of asset inventory and retirement strategies leads to the operation of unpatched systems, resulting in the exposure of sensitive data.

What to check:

• Maintain a comprehensive inventory of all API hosts, including purpose, environment, and version.
• Create and maintain up-to-date documentation for all APIs, including authentication, error handling, and data flow.
• Integrate documentation generation into your CI/CD pipeline using open standards.
• Clearly define network access permissions for each API host.
• Develop a retirement plan for each API version, considering security improvements in newer versions.
• Maintain an inventory of integrated services and document their role, data exchange, and sensitivity.
• Implement API security firewalls for all exposed API versions.
• Segregate production data from non-production API deployments.
• Continuously review and update asset management and security practices.
• Educate teams on proper asset management and security risks.

Unsafe Consumption of APIs

This risk describes how developers trust data received from third-party APIs more than user input, especially if those APIs are offered by well-known companies. This can lead to weaker security practices which allow attackers to identify and potentially compromising other integrated APIs or services, often not publicly disclosed or easily exploitable. The impact varies based on how the target API handles the data, potentially resulting in unauthorised data exposure, various types of injections, or denial of service.

What to check:

• Evaluate the security posture of service providers before integrating their APIs.
• Ensure that all API interactions occur over a secure communication channel (TLS).
• Always validate and properly sanitise data received from integrated APIs before using it.
• Maintain an allowlist of well-known locations that integrated APIs may redirect to and avoid blindly following redirects to untrusted sources.

Key takeaways

For Developers:

• Education and Awareness:
 Stay updated on evolving security threats and best practices through regular training and workshops. Understand key security principles like authentication, authorisation, encryption, and input validation.
• Security Requirements:
 Integrate security considerations early on. Define and address security requirements during the initial stages. Collaborate with experts to prioritise needs based on project context and risks.
• Security Architecture:
 Treat security as integral, not an add-on. Develop a robust architecture aligned with project goals. Include threat modelling in the design phase to proactively identify and address vulnerabilities.
• Standard Security Controls: 
Use established controls and industry standards like OWASP to reduce vulnerabilities. Update controls regularly to adapt to emerging threats.
• Secure Software Development Life Cycle (SDLC): 
Implement security measures at every SDLC stage. Adopt frameworks like OWASP SAMM for assessment. Integrate assessments like code reviews and penetration testing. Utilise OWASP's Code Review Project for comprehensive security assessments.
Developers are crucial in ensuring software and API security. By integrating security from the start, following standard controls, and implementing security measures throughout the SDLC, they build secure software, protecting against potential threats.

Source: CyberArk

What Platform Engineering teams like us can do to help:

Facilitating Continuous Security Testing:

• Promote the practice of continuous security testing throughout the API development life cycle to encourage collaboration between development and operations.
• Integrate automated security checks into the DevOps pipeline for swift identification of vulnerabilities and misconfigurations.
• Provide security policies as code for developers to easily adopt
• Implement automated checking of security policies to proactively address potential security issues in the early stages of development.
• Provide the ability do developers to test code against policies with suitable tooling provided as images or simple commands which can be added to CI/CD pipelines
• Maintain and optimise libraries of security tests, policies and scripts that can be readily applied during the various stages of development and testing.

Understanding and Implementing Threat Models:

• Develop testing priorities by thoroughly analysing threat models to identify potential risks and attack vectors.
• Utilise resources such as OWASP's Application Security Verification Standard (ASVS) and Testing Guide to gain insights into common threats and secure coding practices.
• Customise security testing strategies to specifically target the threats and vulnerabilities relevant to the APIs under development.
• Ensure a holistic approach to security testing, covering critical aspects such as authentication, authorisation, input validation, and data protection.

Source: Dynatrace

Mesoform has been providing platform engineering solutions for business critical systems for nearly two decades and has worked with startups and some of the largest companies on the planet in doing so. Shifting down (or service oriented organisation as we've previously called it) is exactly we've been doing for at-least the last decade. This experience and expertise places Mesoform in a unique position to enable businesses to adopt a shift down approach quickly and easily and with significantly reduced challenges and deliberations like remediation of OWASP API Security Risks. If you would like to discuss any of these topics in more detail, please feel free to get in touch