Perspective — Unveiling the Secret of Robust API Security

As the API ecosystem has proliferated over the past few years, businesses have faced a growing number of attack vectors and security challenges. Unfortunately, with the broad landscape of API design patterns and consumer types, it is challenging to create best practices and tailor traditional security practices to API use cases. According to Palo Alto¹, 92% of organisations experienced API-related security incidents, while 74% reported having a robust API security program. While most organisations’ API security strategy accounts for security at the periphery of infrastructure, such as API Management, Web Application Firewall (WAF), and DevSecOps tooling, the recent upward trend of API attacks¹ raises questions on the adequacy of existing security controls. The latest OWASP API Top 10, June 2023² report highlights that attackers are increasingly exploiting vulnerabilities stemming from poor design and development practices — causing significant disruption to operations. Overreliance on security tooling often results in neglect of security processes such as evil user stories³, threat modelling, secure-by-design, and privacy-by-design, leading to API vulnerabilities.

This blog explores critical insights from OWASP’s API Top 10 to identify security design considerations often neglected during the API development lifecycle. It also provides practical measures that organisations can take to address these gaps.

Broken Authorisation is the most common attack vector for API attacks, representing 40% of such attacks⁴. This vulnerability results from authorisation design and implementation flaws, where an API fails to properly enforce role-based access control to limit what authenticated users can access. While the current security tools can validate against pre-configured authorisation rules, they provide limited protection against unusual requests from authenticated users and are constrained to enforce authorisation rules dynamically.

Despite efforts by organisations to streamline access management policies, this vulnerability still holds the top spot in OWASP’s API top 10. To prevent these attacks, it is essential to implement security design practices at the outset, which includes a thorough understanding of the business use case, identifying actors involved, determining the resource access requirements, and implementing authorisation policies as per the least privilege principle. As part of our assessment of public health sector enterprises in UK, we observed that they often struggle to scale security design practices as the API workload grows, leading to inadequate and ad-hoc implementation of authorisation policies.

Recognising the importance of integrating the security process seamlessly, the implementation of OWASP’s security champion framework⁵ has proven to be effective. This framework empowers development teams to advocate for security causes. It facilitates greater communication between product and security teams to ensure consistent integration of the security process into the development lifecycle.

Broken Authentication remains the second most prevalent vulnerability in OWASP’s Top 10, despite the availability of industry-standard protocols such as OpenID Connect (OIDC), Security Assertion Markup Language (SAML) and Fast Identity Online (FIDO). This vulnerability often stems from an inadequate selection of security patterns and standards, where technical teams may overlook crucial nuances of the protocol during the design or implementation phase. For example, use of OAUTH credential grant type for public facing API. The current tools have limited capabilities to profile user traffic and detect anomalies in user’s requests. Additionally, these tools generate a high percentage of false positives⁶, making it challenging to interpret information accurately and meaningfully.

To provide in-depth and layered cybersecurity protection, it is crucial to develop blueprints and standards for authentication that are specific to the organisation’s environment. This includes considering regulatory requirements, industry standards, technology platforms and threat perception. A major public sector organisation based in the UK designed multiple reusable blueprint patterns and standards for different authentication scenarios, such as public, private, or semi-public API, data access requirements, etc. These blueprint patterns enabled multiple technical teams to consume them rapidly and securely at scale, ensuring consistency in implementation and adequate protection against Broken Authentication vulnerabilities.

Data Privacy breaches occur when API responses include additional metadata, such as telephone numbers and addresses, that malicious actors can exploit for reconnaissance and social engineering attacks. To mitigate this, organisations should adopt the minimalistic data principle, ensure APIs are designed with granular controls at the metadata level, and permit only necessary data in the API response.

It is important to integrate privacy-by-design standards at every step of the API development lifecycle to ensure compliance with regulations and privacy laws, such as the Data Protection Act (DPA) and the UK General Data Protection Regulation (GDPR). For example, consider mapping API contracts to privacy standards, limiting data access to authorised personnel, encrypting data in transit and at rest, and designing audits and monitoring approaches for APIs during design time to enhance API data security. In practice, the development team may over-rely on security tooling, but currently available security tools are not yet advanced enough to return the response selectively based on the caller context. Our varied experience working with multiple client’s time and again reinforces the importance of integrating data privacy best practices during design.

Unrestricted resource consumption is a vulnerability where malicious attackers can overwhelm API resources, causing them to become unusable without any restriction. The attacker manipulates user input parameters, query strings, and the target API’s business logic to trigger excessive resource consumption. Alternatively, an attacker may scrape an entire service to retrieve its data and use it for illegal purposes. A recent example of this is when 500 million records were scraped from social media⁷. Despite the availability of many security tools and frameworks to configure the rate limit, organisations often struggle to baseline the optimum value of resources like network, storage, and CPU to leverage these tools effectively. For instance, while working with a public sector organisation recently, it was observed that the technical team resorted to guesswork to set CPU and memory limits due to the absence of a baseline for memory and CPU for the microservices being designed.

To address the vulnerability, it is essential to establish a rigorous process for developing security baselines. This involves working with stakeholders and considering factors such as historical usage patterns, regulatory requirements, industry benchmarking, and best practices. By developing a unified security view and leveraging advanced tooling, organisations can be better equipped to prevent unrestricted resource consumption. Additionally, it is important to regularly access the security baseline and make adjustments to ensure adequate deterrence against the evolving API threat landscape.

API Business logic vulnerability is a newly introduced vulnerability in OWASP API Top10 2023². It is gaining prominence as it specifically targets sensitive business processes. One example is that an attacker may book all the available tickets for a musical event, making the event unavailable for music lovers. These are hard to detect and restrict through conventional security tooling as requests trigger from legitimate API users and exploit vulnerabilities stemming from poor API business logic design.

To prevent these vulnerabilities, it is crucial to perform threat modelling to identify potential threats and risks associated with business flow. For example, an organisation can develop an in-depth threat modelling process using industry standards such as STRIDE⁸, mapping identified threats against MITRE ATT&CK⁹ to define abuse cases and applicable security control. Ensure that the technical team implements security user stories, encouraging attacker-like thinking throughout the user story lifecycle to uncover the API business logic vulnerabilities and plan mitigation commensurate with the threat landscape.

Security Misconfiguration: With the ever-increasing API landscape, organisations often face challenges related to configuration issues, patching flaws, outdated libraries and runtime misconfiguration. While there are many open-source runtimes protection and configuration tools available that offer decent protection, predicting sophisticated and unknown threats and managing a high rate of false positives⁶ is increasingly becoming challenging. To protect against unknown threats like zero-day vulnerabilities, organisations require access to validated, analysed, and contextualised intelligence that is specific to their unique threat landscape.

At Deloitte, we have developed a methodology and manual research approach that leverages the global Deloitte intelligence network to protect against unknown threats and equip them to manage their security tools and resources effectively. This actionable intelligence and global expertise enable organisations to stay ahead of emerging threats, make informed decisions, prioritise remediation efforts and enhance overall security posture.

API Discovery & Inventory Management: It is common that unused APIs, or those exposed in lower environments, remain unhardened, leaving them open to exploitation. API discovery and cataloguing open-source tools such as OpenAPI Directory can provide a realistic view of the attack surface and help ensure compliance. However, it is important for the technical team to pay attention to API versioning, tagging, deployment patterns, and auditing policy during the design phase to leverage these tools effectively.

To address these challenges organisations should implement a comprehensive API governance and lifecycle framework comprising components such as API lifecycle and governance policies, change management processes, technology considerations and risk objectives. Organisations can achieve better inventory management by adopting a robust framework, reducing the risk of unused or unsecured API. Moreover, it helps in establishing a clear set of API policies to ensure APIs are developed, deployed, and maintained consistently and securely. The success of such a framework is evident in our engagement with Telecom customers, where implementation of API lifecycle and governance led to efficient utilisation of API and a substantial increase in security.

Conclusion

API OWASP Top-10 2023 revealed that implementing security design best practices is critical to hardening API security posture. While security tools are necessary for scaling and automating the manual process, organisations must focus on integrating security processes throughout the API development lifecycle. Moreover, it is equally important to align API security with enterprise information security strategy. With the ever-expanding API landscape, organisations often struggle to scale security processes, leading to vulnerability. Adopting the measures below can help organisations strengthen their API security posture.

• API Centre of Enablement (COE) Establish an API COE to focus on creating a blueprint and lifecycle standards. The COE will act as a governance body, managing these standards and serving as a knowledge repository for blueprints. It will provide teams with the necessary information and capabilities to implement security patterns smoothly.
• Security Champion framework- Implement OWASP’s security champion framework to promote a culture of security awareness and facilitate greater communication between product and security teams to ensure consistent implementation of the security process.
• Unified Security View Establish a unified security baseline for the API resource across the platform and business domain, enabling technical use case development on a secure foundation.

Resources

1 RESEARCH REPORT (23 May 2023) 2023 API Security Data in New Report [Online]. Available at:2023 API Security Data in New Report — Palo Alto Networks (Accessed: 06 Feb2024).

2 OWASP API Security Project team (2023). OWASP Top 10 API Security Risks — 2023 [Online]. Available at: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ (Accessed: 30 Oct 2023).

3 Andreas Falk | OWASP (Aug 20152023). Agile, yes, but secure? OWASP Meeting Stuttgart [Online]. Available at:Agile Security at OWASP Meeting Stuttgart (Accessed: 28 Jan 2024).

4 Stephanie Best (6 June 2023). API1:2023 Broken Object Level Authorization (BOLA) [Online]. Available at: API1:2023 | Broken Object Level Authorization (BOLA) (salt.security) (Accessed: 11 Nov 2023).

5 OWASP Foundation (2023). OWASP Security Culture — 2023 [Online]. Available at: https://owasp.org/www-project-security-culture/v10/4-Security_Champions/ (Accessed: 30 Oct 2023).

6 MORNING CONSULT | IBM (March 2023). Global Security Operations Centre Study Results [Online]. Available at: 5AEDAOJN (ibm.com) (Accessed: 15 Nov 2023).

7 Tidy, B.J. (2021) ‘How your personal data is being scraped from social media,’ BBC News [Online]. Available at: https://www.bbc.co.uk/news/business-57841239 (Accessed: 6 Feb 2023)

8 Microsoft Learning (2022). Microsoft threat modelling tool threats — 2022 [Online]. Available at: https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model (Accessed: 28 Jan 2024).

9 MITRE|ATT&CK (2024). ATT&CK MATRIX FOR ENTERPRISE v14 [Online]. Available at: https://attack.mitre.org/ (Accessed: 28 Jan 2024).

Note: This article speaks only to my personal views/experiences, is not published on behalf of Deloitte LLP and associated firms and does not constitute professional or legal advice. All product names, logos, and brands are the property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.