From exposed supply-chain APIs to identity-layer weaknesses and unauthenticated RCEs, the pattern is clear: basic API controls still break in production.

We also explore the new identity challenges that emerge with API infrastructures being increasingly consumed by agentic AI ecosystems and how evolving identity standards aim to bring stronger, transaction-scoped controls to answer these challenges.

Lastly, yours truly, is co-presenting a webinar on the hot topic of securing Agentic AI with Omdia’s Chief Analyst, Rik Turner. I hope to see you there.

Vulnerability: SolarWinds Web Help Desk RCE via deserialization

SolarWinds has fixed a critical unauthenticated remote code execution vulnerability in its Web Help Desk (WHD) platform, resulting from insecure deserialization of untrusted data. According to Horizon3.ai’s analysis, the issue stems from the AjaxProxy component, where JSON-RPC request messages are not properly validated against strict schemas before being processed. Because the structure and content of incoming JSON-RPC payloads are not sufficiently constrained, specially crafted requests can reach dangerous deserialization paths and trigger the execution of arbitrary commands without authentication. This flaw, which received a CVSS score of 9.8, has been added to the CISA Known Exploited Vulnerabilities (KEV) catalog and reinforces a persistent lesson for API teams: failures in schema validation at the API boundary often precede full system compromise. SolarWinds has fixed the issue in Web Help Desk 2026.1, and it is strongly recommended that the patch be applied immediately, especially for publicly accessible instances.

Vulnerability: Keycloak unauthorized access to protected resources through invitation token manipulation

A high-severity authentication and authorization flaw has been disclosed in Keycloak, the widely used open-source identity and access management platform that is often found upstream of APIs. The vulnerability stems from incorrect validation of the signature of invitation JWT tokens, allowing an attacker to manipulate the contents of the tokens and self-register in organizations different from the one they had been invited to join. By modifying identity-related fields in a valid invitation token and reusing it, an attacker could bypass intended access controls and gain unauthorized access to protected resources. This issue highlights a recurring weakness in API security: the trust placed in context provided by the client or embedded in the token without strict server-side verification. Keycloak has released patches to address this issue, and users are strongly encouraged to update, as vulnerabilities at the identity layer can have cascading effects on all APIs and services that rely on the platform for authentication and authorization. Github advisory is here.

Vulnerability: Bluspark’s Bluvoyix supply chain platform exposed unauthenticated APIs and plaintext credentials

Security researcher Eaton Zveare discovered a set of critical vulnerabilities in Bluspark Global’s Bluvoyix maritime logistics and supply chain platform, which collectively exposed the platform’s APIs and customer data to the internet. The full disclosure is available here: Bluspark Bluvoyix Security Research. The vulnerabilities included unauthenticated API endpoints that returned sensitive data without credentials, exposed API documentation with interactive testing, the ability to create administrator accounts via unauthenticated HTTP POST requests, retrieval of plaintext passwords for all user accounts, and client-side code that could be used for malicious purposes to send phishing emails. Using these weaknesses in combination, an attacker could have viewed, modified, or canceled shipments and accessed decades of customer data from hundreds of companies using Bluvoyix without ever logging in. Zveare’s attempts to notify Bluspark were delayed by the lack of disclosure channels, leading to an escalation through the press before the issues were finally fixed and a vulnerability disclosure program was promised. Incidents like this highlight why unprotected APIs and misconfigured authentication remain systemic risks, particularly in critical infrastructure software, and how the lack of secure API design and disclosure processes can greatly amplify their impact.

Vulnerability: Order Up online ordering system — critical unauthenticated SQL injection

Security consultant Subhash Paudel of Spartans Security disclosed several unauthenticated SQL injection vulnerabilities in the Order Up v1.0 online ordering system. The full report is available here: Spartans Security Analysis. The flaws appear in the /api/integrations/getintegrations endpoint, where the store_id parameter of a POST request is integrated into backend SQL queries without proper validation or parameterization on the server side, allowing an unauthenticated attacker to manipulate database logic and retrieve or modify sensitive data. Security testing confirmed the effectiveness of boolean-based and timing-based blind SQL injection techniques, highlighting how easily specially crafted payloads can influence the execution of backend queries, even when no errors are reported. This incident serves as yet another reminder that SQL injection, despite being one of the oldest and most well-known vulnerabilities, remains ubiquitous in API contexts where user input is not rigorously validated and parameterized.

Article: Identity as the foundation for secure API consumption by agentic AI

A recent article by Nordic API’s, How Identity Guides the Use of APIs by Agentic AI, by Kristopher Sandoval, highlights a fundamental change: as agentic AI systems increasingly consume APIs autonomously, identity must evolve from static client credentials to contextual, transaction-limited authorization. Traditional API access models assume that clients are predictable and operate within predefined flows. Agentic AI challenges this assumption: agents can dynamically explore API surfaces, chain workflows, and adapt to responses. Without robust and precise identity controls, APIs risk exposing unwanted resources or operations.

An emerging initiative to address these concerns is the IETF’s OAuth Transaction Tokens project, led by Atul Tulshibagwale SGNL’s CTO and co-chair of the OpenID Foundation’s Artificial Intelligence Identity Management (AIIM) working group. Transaction tokens introduce cryptographically verifiable, single-operation identity assertions, allowing APIs to validate not only who an agent represents, but also what specific transaction it is authorized to perform.

At the same time, Nicola Gallo expressed similar concerns about identity and authorization in agent ecosystems, advocating compliance with the PIC (Principle of Identity Context) specification, which emphasizes the explicit propagation of identity context and its strict enforcement across service boundaries. The PIC specification offers a structured approach to maintaining verifiable identity continuity throughout API interactions, reinforcing the principle of least privilege and contextual authorization. 

Together, these initiatives reflect a growing recognition that identity architecture—not just token issuance—will define the security of agent-driven API infrastructures consumption.

Webinar: Agentic AI – Fools rush in where Angels fear to Tread

Next month I will be in discussion with Rik Turner, Chief Analyst at Omdia about how MCP can securely enable and accelerate the exposition of the API infrastructure to agentic AI.

Enterprises are racing to adopt AI — but are they moving forward strategically, or simply following the hype cycle?  We will look to separate signal from noise and explore the practical implications for enterprises seeking to enable agentic AI.

Register here to attend the webinar

The post Issue 289: SolarWinds RCE, Supply-Chain API Exposure, SQL Injection, and Identity for APIs in the Age of Agentic AI appeared first on API Security News.

We also dive into the 42Crunch State of API Security 2026 report, which analyzes 200 production vulnerabilities to show why these patterns persist — and why, as AI agents become first-class API consumers, insecure APIs are far less likely to remain unnoticed or unexploited.

Vulnerability: ServiceNow “BodySnatcher”: Agentic AI Vulnerability Leads to User Impersonation

A critical agentic AI security flaw dubbed BodySnatcher (CVE-2025-12420) has been uncovered in ServiceNow’s Virtual Agent API and Now Assist AI Agents platform, illustrating how autonomous AI integrations can introduce catastrophic risks when identity and access logic are weak. 

Researchers at AppOmni found that an unauthenticated attacker could impersonate any user — including administrators — using only a target’s email address by chaining a hardcoded platform-wide secret with overly permissive account-linking logic, effectively bypassing multi-factor authentication (MFA), single sign-on (SSO), and other controls. Once impersonation was achieved, the attacker could remotely invoke AI agent workflows as the victim, create backdoor admin accounts, and execute privileged actions, weaponizing automation to subvert enterprise controls and escalate access. 

AppOmni described BodySnatcher as “the most severe AI-driven security vulnerability uncovered to date,” highlighting how traditional authentication and API security weaknesses become dramatically worse when high-privilege agents are involved. ServiceNow has since patched the vulnerability in affected versions, but the incident underscores the need for rigorous identity verification, least-privilege agent scoping, and runtime governance of AI agents to prevent similar exploits. 

Vulnerability: SmarterMail Authentication Bypass (CVE-2026-23760) Exploited in the Wild

A critical authentication bypass vulnerability in SmarterTools’ SmarterMail email and collaboration platform — tracked as CVE-2026-23760 and originally reported by WatchTowr Labs  — is now being actively exploited in the wild even after a patch was released. 

The flaw exists in the /api/v1/auth/force-reset-password API endpoint, allowing users to reset their password. 

While normally password reset “rely on a second factor or out-of-band proof of control – for example, a secret token delivered via email”, as WatchTowr Labs frames it, there was no such protection in place. Instead, the old password was requested, suggesting that SmarterMail developers mixed change password and reset password functionalities… 

Furthermore, while in place for regular users, validation of the existing old password was not even done processing password reset requests for system administrator accounts!

Knowing the username of an admin account was therefore enough to change his password, gaining full administrative access to the SmarterMail instance and, through built-in admin features, execute arbitrary operating system commands at SYSTEM level on the host. 

Evidence suggests attackers very quickly reverse-engineered the patch shipped in Build 9511 (January 15, 2026) and began abusing the flaw within 48 hours, demonstrating how rapidly critical API authentication bypasses can be weaponized post-disclosure. 

Organizations running vulnerable versions should update immediately and validate that the forced reset path is protected. 

Vulnerability: Fortinet FortiCloud SSO Authentication Bypass (CVE-2026-24858)

Fortinet has released urgent patches for a critical authentication bypass vulnerability tracked as CVE-2026-24858, which has been actively exploited in the wild across multiple Fortinet products, including FortiOS, FortiManager, and FortiAnalyzer. 

The flaw, categorized as an authentication bypass using an alternate path or channel (CWE-288), allows an attacker with a FortiCloud account and a registered device to authenticate to devices registered under other FortiCloud accounts when FortiCloud SSO is enabled — effectively breaking account isolation and granting unauthorized administrative access without valid credentials.

Exploitation has enabled attackers to create persistent admin accounts and exfiltrate device configurations before patches were widely deployed.

From an OWASP perspective, this maps to OWASP API2: Broken Authentication, where flawed assumptions about identity, trust relationships, or authentication flows allow attackers to bypass access controls entirely. 

Coincidentally (or not!), this incident directly reflects a key finding from the 42Crunch State of API Security 2026 report: authentication bypass remains one of the most prevalent real-world API vulnerabilities, consistently showing up in production breaches due to gaps in access control and trust boundaries. 

Report: State of API Security 2026: What Real Vulnerabilities Tell Us About the Year Ahead

42Crunch published their State of API Security 2026 report. This report delivers a data-driven analysis of 200 real-world API vulnerabilities observed in production between 2024 and 2025, drawn directly from APISecurity.io newsletter coverage and independently verified cases. 

Rather than focusing on theoretical risks, the report highlights how common development mistakes — such as missing authentication, broken authorization, weak input validation, and client-side security assumptions — consistently lead to serious breaches across industries. 

Looking ahead, it also examines how AI agents and LLMs fundamentally change the API risk model, increasing the likelihood that latent vulnerabilities will be discovered and exploited in production. 

The report translates these findings into clear development responsibilities and preventative practices, helping teams prioritize governance and build APIs that are secure by design in an AI-driven ecosystem. 

Report: AI-Assisted Patch Diffing and the New Exploit Race

Recent research by Akamai demonstrates how large language models can be used to automate patch diff analysis, rapidly identifying the root cause of security patches and the precise code changes that fix them. 

Tools like PatchDiff-AI ingest vendor binaries and patch metadata, and generate detailed root-cause analysis reports in a fraction of the time it would take a human — compressing what used to take weeks into hours or even minutes.

This accelerated analysis is a double-edged sword: while defenders can understand fixes faster, attackers can use the same insights to craft one-day exploits targeting newly disclosed vulnerabilities almost immediately after their patches are published. 

The SmarterMail authentication bypass exploit we just discussed, which was weaponized within days (hours? minutes?) of a patch release, is a clear example of this emerging threat landscape. 

In a world where AI can quickly translate patch diffs into exploit logic, timely updates and automated patch deployment are no longer optional — they are essential to stay ahead of attackers who are increasingly using AI-assisted techniques to turn disclosures into active threats in an extremely short time. 

The post Issue 288: State of API Security 2026, Agentic AI, Authentication Bypasses, and the Race to Patch APIs appeared first on API Security News.

Below are the most significant API-relevant security stories from the last few weeks — from critical RCEs to gateway authentication bypasses and automation-platform exploits and an excellent article on BOLA.

Vulnerability: Ni8mare – Critical Unauthenticated RCE in n8n Workflows

A new critical vulnerability in the n8n workflow automation platform — tracked as CVE-2026-21858 and dubbed Ni8mare — discovered by the Data Security Platform vendor Cyera has shaken the automation world with its maximum CVSS 10.0 severity and unauthenticated remote code execution potential. 

The issue stems from a Content-Type parsing confusion in n8n webhooks and form requests, enabling attackers to override expected input structures and read arbitrary server files, including configuration and authentication secrets. With those secrets, attackers can forge administrative sessions and build malicious workflows that execute arbitrary code without valid credentials. 

Because n8n sits at the heart of many API integrations and automation pipelines, a compromised instance can pivot into broader environments. All internet-accessible deployments prior to v1.121.0 are vulnerable and should be patched immediately; restricting public webhook and form endpoints can reduce exposure in the meantime. 

See the full analysis by Cyera Research Labs

Vulnerability: IBM API Connect – Critical Authentication Bypass

IBM has disclosed and patched a critical authentication bypass in IBM API Connect, rated CVSS 9.8. 

Classified as CWE-305: Authentication Bypass by Primary Weakness, this flaw allows remote attackers with no privileges and no user interaction to bypass authentication and gain unauthorized access to API Connect’s management interfaces. 

Successful exploitation can expose sensitive API configurations, administrative functions, and backend services without valid credentials — undermining a core access control layer in API infrastructure. 

Affected versions include 10.0.8.0 through 10.0.8.5 and 10.0.11.0; IBM has published interim fixes (iFixes) to remediate the issue. Customers unable to patch immediately should harden access to management interfaces as an interim control. 

Some information is available, though the details of the problem were not unveiled publicly. 

Vulnerability: HPE OneView – RCE via unauthenticated REST API operation

A maximum-severity RCE flaw has been disclosed in Hewlett Packard Enterprise OneView, a centralized infrastructure management platform. 

This vulnerability exists in a REST API endpoint (/rest/id-pools/executeCommand)  that accepts command parameters without proper authentication, allowing unauthenticated attackers to inject and execute arbitrary code on affected servers. Rapid7’s research highlights how the lack of authentication enforcement in the executeCommand API effectively exposes powerful control functions to attackers. 

Because OneView manages servers, firmware, networking, and lifecycle workflows, exploitation can lead to full infrastructure compromise. U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added it to its Known Exploited Vulnerabilities catalog, underscoring active risk. Affected installations should update to v11.0 or apply vendor hotfixes immediately. 

Vulnerability: SmarterMail – Pre-Auth RCE in Email Server

After the n8n vulnerability, another file upload-based issue opening the door to unauthenticated remote code execution was identified in SmarterTools’ SmarterMail platform, earning a CVSS 10.0 rating and prompting advisories from Singapore’s Cyber Security Agency (CSA). 

WatchTowr Labs’, as always, excellent analysis shows that an unauthenticated file-upload API (/api/upload) fails to validate user-supplied path parameters (contextData), enabling path traversal and writing of files (such as web shells) to arbitrary locations. Attackers can upload a malicious .aspx shell into a web-visible directory, leading to full RCE under the SmarterMail service context. 

The issue was silently patched in Build 9413 (October 2025) and the public advisory lagged, creating a significant exposure window for internet-facing deployments. Administrators should update immediately and audit for unauthorized artifacts. 

Article: Do you really understand BOLA?

In our last issue of 2025, we pointed out the most frequent vulnerabilities identified in this newsletter in the previous 12 months. Number 2 on that list was BOLA (Broken Object Level Authorization). BOLA is still a major problem. In his recent article on Hackernoon, Igboanugo David Ugochukwu gives an excellent, detailed explanation of BOLA, the #1 API security vulnerability identified by OWASP.

He asks a simple question: “So once I’m logged in as User 47, what stops me from just requesting User 48’s data?” As he rightly pointed out
 “the vulnerability that sounds boring in conference talks but costs companies their entire customer database on a Tuesday afternoon!”

And his advice on how to fix it? “…you need every engineer who touches user data to ask, ‘Am I checking that this user is allowed to access this specific object?” Every time. No exceptions.”..”

BOLA needs a proper DevSecOps approach, and too many people are not tackling it correctly, resulting in many APIs today probably leaking data right now.

Webinar: State of API Security 2026

Join Anthony Lonergan and Heshaam Attar later this month for a webinar introducing the State of API Security Report.

The 2026 report delivers a data-driven analysis of real-world API vulnerabilities, showing how common mistakes in implementation translate into security risks in production. 

Drawing on two years of investigative research from the industry’s leading APIsecurity.io newsletter that includes cases from a wide range of independent sources, the webinar highlights the most common API flaws, from broken input validation and missing authentication to operation-level authorization failures.

The post Issue 287: Critical RCEs in n8n, HPE OneView, SmarterMail, and an Authentication Bypass in IBM API Connect appeared first on API Security News.

I’d like to wish all APISecurity.io followers the very best for the year ahead. No doubt we’ll have plenty more API security news and challenges to cover in 2026!

Vulnerability #1: Missing Authentication

Our most frequent API vulnerability this year was Missing Authentication. These are APIs that do not enforce authentication for sensitive operations, allowing anonymous users to access data or perform actions that should be restricted to authenticated users.

In 2024, this was our fifth most reported vulnerability. In 2025, it rises to number one, accounting for 17 percent of all API incidents covered.

One case from March illustrates the impact of missing authentication, when patient data in the UK healthcare system was reportedly exposed through an unauthenticated API. And in August, we covered a similar issue at Intel, where a ‘getAccessToken’ API endpoint would return valid tokens without requiring any authentication. 

Keeping track of your API endpoints and continually verifying authentication controls, both pre-production and in production, can help API teams catch and plug this vulnerability. 

Vulnerability #2: Broken Object Level Authorization 

Broken Object Level Authorization, or BOLA, was second on our list of frequent API incidents. BOLA occurs when an API fails to verify whether a user is permitted to access a specific object. Attackers exploit this authorization vulnerability by manipulating identifiers in API requests, such as user IDs, account numbers, or other resource identifiers, in an attempt to access other users’ data. This has become a go-to tactic for API hackers and is something API developers should be aware of.

We saw many cases of BOLA incidents in 2025. One example from our September issue involved Growatt inverters used in industrial and commercial solar-powered systems. A BOLA flaw in the API allowed hackers to take control of solar-powered IoT devices inside users’ homes. 

“The flawed API accepts a device ID parameter without verifying whether the current user is authorized for that device, a textbook case of Broken Object Level Authorization”

Also in September, we reviewed a researcher’s findings on a BOLA vulnerability in India’s Goods and Services Tax (GST) website. By manipulating API requests, users were able to access the tax information of private companies that should not have been accessible to them.

Authorization checks for individual resources are usually too fine-grained to offload to centralized platforms like API gateways or IAM products. So the responsibility sits with API developers to implement the proper checks at the API endpoint. 

Vulnerability #3: Excessive Data Exposure 

The majority of API data leaks we saw this year involved the exposure of unexpected or unauthorized properties in API responses. This aligns with OWASP’s API3:2023 Broken Object Property Level Authorization (I think the earlier 2019 name, Excessive Data Exposure, still describes the issue more clearly). 

Excessive data exposure occurs when an API returns more properties than needed. This includes returning full objects or records when only a subset of fields is required, or failing to filter sensitive properties before sending a response.

In May, we covered a case involving Volkswagen’s connected vehicle system. A researcher found that an API response returned information that the app didn’t need, including plaintext secrets and passwords. And in October, we reported the case of a registration portal for Formula 1 drivers that leaked excessive data in an API response, giving researchers enough context to uncover a privilege escalation vulnerability. 

We agree with the OWASP guidance for preventing excessive data exposure: define and enforce the data returned by every API method through a schema-based or contract-based response validation mechanism. 

Vulnerability #4: Broken Function Level Authorization

Most of the Broken Function Level Authorization (BFLA) incidents we covered this year were basic errors in role-based access control at the API operation level. These occurred when functions intended for privileged users were accessible to roles with less permissions. 

One example came from an August report on Securden’s Privileged Account Management platform, where a sensitive password backup function was available to users who were not administrators. In our March issue, we highlighted similar issues in the Zitadel platform, where 12 admin-level API endpoints were open to non-admin users. 

Other common BFLA cases involved users being able to run specific API operations, such as PUT or DELETE, that should have been restricted to administrators.

Vulnerability #5: Broken Authentication 

And finally, fifth on our list of the most common API vulnerabilities this year is Broken Authentication. This describes flaws where the authentication mechanism itself is poorly designed or implemented, allowing an API to accept requests without properly verifying the user.

In May, we covered an issue in a Volkswagen mobile application where a one-time password validation API was vulnerable to brute force attacks. In September, FlowiseAI, a platform for building AI agents, disclosed a flaw in its password reset process. The vulnerable API returned a reset token directly in the response, instead of following secure practices to send the token to a registered email address.

We intentionally separated Missing Authentication from Broken Authentication to highlight how often API teams completely fail to enforce authentication. Though challenges also remain prominent with API authentication controls generally.

The post Issue 286: The APISecurity.io Top 5 API Vulnerabilities in 2025 appeared first on API Security News.

Vulnerability: Massive API Data Exposure at Avelo Airlines 

Security researcher Alex Schapiro reveals API flaws he found in Avelo Airlines’ reservation system that exposed millions of passenger records, including PII and payment-related data. 

The main API vulnerability in this case was a broken authentication check. The API accepted a 6-character reservation code without also requiring the passenger’s last name. This allowed anyone with just a valid code to retrieve the corresponding record, without having to guess the relevant passenger’s name. To make matters worse, the API was “very generous” with the passenger data it returned.

The API also lacked rate-limiting controls, which allowed for brute force enumeration of all possible reservation codes, and by consequence, passenger records. The researcher included an eye-opening estimate of the cost to brute force all combinations, calculated at just $435 using AWS Lambda. 

Broken authentication and excessive data exposure are serious API vulnerabilities on their own. But when combined with missing rate limits, the impact can really escalate, allowing sensitive data to be harvested at massive scale. 

These are important API security controls to get right. Read the report.

Vulnerability: 3.5 Billion WhatsApp Accounts Exposed

Continuing on the topic of API rate limiting, researchers have shared a detailed report describing how they were able to exfiltrate 3.5 billion WhatsApp user phone numbers through a vulnerable API.

This is another API enumeration attack, though different from the Avelo Airlines case, because in this instance, the API behaved as intended. Social media platforms often provide lookup services that allow users to find other accounts and search for friends. But that search function can also be abused for large-scale enumeration attacks. Beyond social media, we’ve seen similar cases before, including the Trello incident that exposed the information of over 15 million users, again through a vulnerable search API. 

The original research highlights the challenge of allowing legitimate users to perform a high volume of lookups while at the same time preventing abuse and exfiltration of massive data sets. The solution requires some sophistication to distinguish normal from abnormal user behavior. 

Part of the challenge is also that the value of these attacks is not necessarily in the data retrieved about any individual user, but more in the large volume of data. At scale, the data becomes highly valuable for use in automated phishing attacks or fraud. So these incidents demonstrate the need for carefully considered API rate-limiting strategies that balance intended user experience with the risks of API enumeration vulnerabilities. Read the article.

Incident: Risks from OpenAI’s API Developer Platform 

A quick note on something that popped up in my inbox today. OpenAI is notifying developers about a security incident that may have exposed private information for users of the OpenAI API development platform.

platform(dot)openai(dot)com

The issue appears to stem from a third-party vendor, Mixpanel, which OpenAI uses on the frontend of its API development site for analytics. OpenAI hasn’t shared details on the technical cause yet, but the incident report advises developers to stay alert for credible-looking phishing attempts or unusual emails.

If you’ve done any API development or testing through OpenAI’s platform, this is one to keep an eye on. Read the incident report. 

Vulnerability: API Routing Flaws in Oracle Identity Manager

While most API endpoints require authentication, some endpoints are deliberately excluded from this step. Skipping authentication is a common source of API vulnerabilities, and we see similar patterns in many previously reported cases.

A recent example involves Oracle’s Identity Manager (OIM). In OIM, authentication is skipped for requests ending with the query string “?WSDL”. This is typically a request for a publicly available SOAP service description file, so skipping authentication in this case makes sense.

However, a common coding mistake made the WSDL check too loose. Developers often use risky pattern checks such as “ends with” or “contains”, which are easily exploited. An attacker can just tack on “?WSDL” to the end of any API request, tricking the API code into treating it as a public WSDL request and so bypassing authentication entirely.

API authentication bypasses like this are common, so this is another vulnerability to watch out for. Read the report.

Survey: Impact of API Vulnerabilities for AI Enablement

F5 has published a new survey report, “2025 Strategic Imperatives: Securing APIs for the Age of Agentic AI in APAC”. The survey looks at API security trends across organizations in the Asia Pacific region and the impact of API vulnerabilities on AI enablement strategies. 

“APIs are now central to digital transformation, partner integration, and AI enablement in Asia Pacific”

APIs are key enablers of AI integrations and autonomous workflows. The report highlights how many OWASP API Top 10 API vulnerabilities align with organizational concerns around AI, as autonomous agents can amplify the impact of issues like API6:2023 “Unrestricted access to sensitive business flows” and also API4:2023 “Unrestricted resource consumption”. 

2025 Strategic Imperatives: Securing APIs for the Age of Agentic AI in APAC

The survey also found that API authentication and authorization remain the weakest links, with many teams struggling to find an effective solution for vulnerabilities such as API1 BOLA and API2 Broken Authentication. 

Undocumented and unmanaged APIs are another major concern, with post-production techniques like code scanning and traffic-based detection proving inadequate, according to a majority of survey participants. Non-deterministic AI agents are likely to exacerbate these risks by automatically uncovering and exposing undocumented APIs.  

This raises the urgency for API teams to address the root cause by adopting a pre-production approach: maintaining a fully documented, tracked and enforceable API inventory. Read the survey.

Article: Deterministic Guardrails for AI-Generated Code

Security has long played “second fiddle” to feature delivery, especially in API development, where new services and updates are pushed out at a breakneck pace with ever-shorter release cycles.

Now, with AI-generated code entering the mix, the question is: is the priority gap between security and time-to-market about to get better or a whole lot worse? That’s the question Ramya Murthy explores in a recent Medium article, and her conclusions are sobering.

“One in five organizations have already suffered material business damage from AI-generated code”

Murthy highlights a key limitation: AI often lacks context. It doesn’t understand an API’s business logic, regulatory requirements, or security policies. Instead, it generates code based on learned patterns, producing mixed results.

“45% of AI-generated code fails basic security checks”

From a security standpoint, AI can help teams to improve productivity through automation and rapid code generation. But developers can’t rely on AI alone. Rigorous security checks and thorough testing will be essential to ensure AI-generated code meets organizational security policies and regulatory standards for APIs. Read the article.

The post Issue 285: API hack at Avelo Airlines, 3.5 billion leak at WhatsApp, F5 API security survey, AI-generated code risks appeared first on API Security News.

Industry News: OWASP Top 10 2025 now available

A release candidate for the new OWASP Top 10:2025 vulnerability list is available from the OWASP website. This is the general OWASP Top 10 list, not the API-specific one. But there are a couple of notable trends that I think could also influence the next API vulnerability list. 

First, Security Misconfigurations has been bumped up from #5 to #2, signaling that insecure or unexpected application behavior is increasingly caused by configuration issues rather than just coding flaws. 

That has important implications for security testing. Static Application Security Testing (SAST) tools that scan only source code may be blind to vulnerabilities introduced through configuration settings outside the application. These issues often only surface during manual configuration reviews or dynamic testing (assuming you can define upfront the expected behavior to test against), so the trends may warrant a shift in emphasis towards dynamic testing. 

There’s also a new entry: Software Supply Chain Failures. In the API space, this likely reflects the growing complexity of API ecosystems and their interdependencies. APIs today often act as just one node in a chain of upstream and downstream API calls, with LLMs and Model Context Protocols (MCPs) now thrown in for good measure as consumers and providers of API data. 

It’ll be interesting to see if this drives any movement in the OWASP API Security Top 10 list, particularly for API10:2023 “Unsafe Consumption of APIs” in its next release. Read the OWASP Top 10 introduction.

Vulnerability: Researcher Claims API Flaw at Mercury Energy NZ 

A recent blog post spotlights a potential API flaw at Mercury Energy in New Zealand, where broken object-level authorization (BOLA) may have allowed access to customer records. This type of API authorization vulnerability is a common root cause in API attacks and highlights the importance of enforcing strict access controls at every API endpoint. 

BOLA is often exploited by authenticated users who gain access to other users’ resources or data by manipulating resource identifiers used in API requests. To prevent it, API developers should add authorization checks to ensure that a user requesting access to a resource is the owner or has the right permissions. 

Testing and validating that these authorization controls are in place and effective can help teams remove low-level authorization vulnerabilities that often carry very high risk. Read the post.

Vulnerability: ChatGPT API Exposes Access Tokens 

Security researcher Jacob Krut uncovered a high-severity API vulnerability in ChatGPT’s custom actions feature. It allows a custom GPT to connect to external tools and services by calling your own APIs to pull in additional context for an AI agent or LLM. It’s similar to Antrophics MCP protocol in effect. 

The researcher found that instead of pointing to some benign external API, the custom actions feature would accept a URL for an internal API, allowing him to trick the system into returning data from its own file system, and sensitive data at that. This is a classic example of server-side request forgery (SSRF). You should always validate and restrict user-supplied data to an API.

ChatGPT did appear to have some input validation in place to check the user-supplied URL, but it was limited. And with some tricks and hacking magic the researcher was able to launch a successful SSRF attack to access an internal metadata service on the hosting cloud platform, and ultimately generate privileged access tokens for Azure management API , the proverbial keys to the kingdom! Read the researchers full report. 

Vulnerability: Risk from AI Products

Cybersecurity firm Wiz recently found critical vulnerabilities in the Github repositories of some of the biggest and most influential AI companies on the Forbes AI 50 list. API Keys, access tokens, credentials, but also model data that can reveal insights about the training data used by these AI systems. 

Leaked credentials from Github and other public repositories aren’t exclusive to AI companies. It’s been a recurring problem across industries for years. I came across a similar case we reported on in this newsletter from 2019, and there have been many others since then. It’s clearly a systemic issue for collaborative software development in general.

That said, AI tools and platforms are increasingly embedded across organizations in software development, testing, and critical business workflows. So any compromise of these tools can have an outsized impact. And with the growing popularity and adoption of MCP servers, AI platforms are also moving into the critical paths of organizations service and data delivery. So vulnerabilities in these AI platforms can quickly spread across systems to multiply risk and business impact. Thread carefully with AI enablement.  Read the news article.

Article: API Risk is a board-level business continuity issue

A discussion on Betanews about the risks from APIs as the fastest growing class of security incidents is worth a read. It covers a range of different topics from the impact of Agentic AI on API security, to the essentials of an API-first security strategy, to the impact of a single API vulnerability on the broader supply chain.

“APIs are not just developer conveniences, they are business-critical assets that demand the same rigor as financial systems or customer databases”

In the article, Scott Wheeler talks about the need for organizations to make API security central to their overall architecture, and to integrate security into the very design and development of APIs, rather than waiting until they’re already out in the world, when it’s too late.

There’s also a discussion on using behavior-based threat detection to identify out of bounds behavior. That’s certainly an improvement on the traditional signature-based defenses of a WAF or Gateway, but behavioral-detection based on machine learning language often struggles to keep up with the pace of API delivery and rates of API updates, since those tools require constant retraining to keep up. During that time the API traffic is essentially unprotected.  

“Once the scope is understood, the priority becomes shifting security left, embedding protection into the design and development lifecycle rather than bolting it on after deployment”

A security-by-design first approach for APIs that evolves along with API development is essential, to build APIs that are reliable data providers for AI models, as well as resilient to the unprecedented speeds of AI-powered attacks. Read the article. 

The post Issue 284: OWASP Top 10 2025, ChatGPT’s API Flaw, BOLA at Mercury Energy NZ, Leaky AI Companies appeared first on API Security News.

Article: Is AI the silver bullet for software vulnerabilities?

In a recent article, former CISA Director Jen Easterly highlights some uncomfortable truths:

“The common factors uncovered by MITRE nearly 20 years ago – cross-site scripting, memory unsafe coding, SQL injection, directory traversal – remain part and parcel of shipped software.”

This aligns closely with our research at APISecurity.io. Over the past year, roughly 25% of all API security cases we’ve covered involved injection attacks, path traversal, or server-side request forgery (SSRF). These are long-standing, well-known vulnerabilities that existed long before web APIs were a thing, yet they continue to appear in production APIs.  

Easterly suggests AI could help, though with important caveats:

“If we’re able to build and deploy and govern these incredibly powerful technologies in a secure way, I believe it will lead to the end of cybersecurity.”

The reality today though is miles away from this ideal. A 2025 GitHub survey found that most experienced developers do not trust AI-generated code. And two frustrations stood out: 66% of developers struggle with AI solutions that are “almost right, but not quite,” and 45% find debugging AI-generated code more time-consuming than writing it manually. 

AI, like any security tool, is not a magic wand. But it can be effective if it’s placed in the hands of experienced developers to help automate practices and processes intelligently. As Jen Easterly emphasizes, real security comes from building systems securely from the start. Without the software engineering discipline, AI is more likely to amplify vulnerabilities and frustrations than prevent them. Read the article. 

Vulnerability: Racing to an F1 authorization vulnerability

Fancy becoming a registered Formula 1 driver? There’s a vulnerable API for that!

Researchers Ian Carroll, Gal Nagli, and Sam Curry, recently uncovered a number of API flaws in the registration portal of Fédération Internationale de l’Automobile (FIA), the governing body for world motorsport. One API allowed users to elevate their role to administrator, and get access to privileged services and sensitive data, including the personally identifiable information (PII) of Dutch F1 driver Max Verstappen!

Two classic OWASP API vulnerabilities were exploited. First, excessive data exposure in the response to an API PUT request leaked “hidden” properties, like user role and status. Using those properties, the researchers then attempted an API mass assignment attack to change their user role to administrator, and it worked! 

Excessive data exposure and mass assignment vulnerabilities are together categorized as Broken Object Property Level Authorization (BOPLA) in the latest OWASP API vulnerability list.

This case is another useful lesson on the need to tightly constrain an API’s allowed input and output properties, using schemas or API specifications. Otherwise hackers, ethical or otherwise, will find vulnerable entry points to exploit. Read the report. 

Vulnerability: Better-Auth’s API coding error 

Better-Auth, a popular open-source plugin for authentication and authorization, was recently found to have a critical API vulnerability. A logic error in the service for API key creation allowed any user to retrieve a valid API key for any other registered user, without needing their credentials.  

In the code, if a request for an API key includes either a valid session or a valid user ID, the API skips authentication. That means if an unauthenticated user knows or can guess another user’s ID, they can send just the ID to the API and will receive back an API key for that user. If you’re interested in the technical details you can see the GitHub code comparison highlighting the logic flaw and its fix.

Missing or broken authentication is a common API vulnerability, and attackers often look for “enabling vulnerabilities” like logic flaws to bypass access controls. These issues can be especially tricky to detect because every API has unique input properties and security checks, and bypass mechanisms are typically very specific to the developer and the logic they code. Careful API design and early testing of the API logic can help prevent or detect these types of vulnerabilities early on. Read the article.

Vulnerability: Broken authentication in WSO2 API Manager

WSO2 API Manager uses method contexts to define and apply security rules for API operations. The rules set out:  

• context = which URL or endpoint the rule applies to
• http_method = which HTTP method (GET, POST, PUT, DELETE, etc.)
• secure = whether this endpoint requires authentication
• permissions = which user roles or permissions are allowed
• scopes = which OAuth2 scopes are required for access

Some of the API platform’s own APIs were missing these method contexts (you can see examples here), exposing administrator-level operations without any authentication or authorization. 

“The successful exploitation of this vulnerability could allow an attacker to gain administrative privileges and perform unauthorized operations.”

This case highlights the importance of verifying that every API endpoint requiring authentication and authorization actually enforces it. Testing should happen both before API deployment and continually in production to catch any changes or drift in APIs access control behavior. Read the advisory.

Vulnerability: Industrial System’s BFLA Vulnerability

Moxa is a provider of industrial networking solutions. They recently released a security advisory  that included four API vulnerabilities in their network security appliances and routers. 

Modern industrial devices often expose APIs for remote configuration, administration portals, or monitoring apps. API security incidents in industrial systems are relatively new, but we’re seeing cases more frequently as these systems become increasingly interconnected.

It’s also noticeable that the same API vulnerabilities commonly seen in web applications also appear in industrial APIs. Like the previous cases we looked at earlier for WSO2 API Manager and the Better-Auth plugin, Moxa’s “protected” APIs were missing authorization controls. 

“A flaw in the API authentication mechanism allows unauthorized access to protected API endpoints, including those intended for administrative functions.”

Without authorization checks, low-privileged users could access administrator-level functions to modify system configurations, perform internal network reconnaissance, and even create new administrator accounts. That’s a classic case of Broken Function Level Authorization, another common API vulnerability that escapes the attention of API teams. Read the advisory.

The post Issue 283: AI Security Solutions, Formula 1’s API Flaw, Latest OWASP Authorization Incidents appeared first on API Security News.

Vulnerability: Security Pros Go All In on Poker Website 

Security researchers Sam Curry and Shubs Shah uncovered a series of vulnerabilities that granted unauthorized access to the administrator panel of the online poker platform ClubWPT Gold.

Early in their investigations, the researchers discovered the full source code for the admin application exposed online. Using information from an exposed configuration file, hardcoded credentials, and easily guessed passwords, they were able to log in to a staging environment of the admin app.

Unfortunately, the same credentials were reused in the production site. Then the only remaining barrier to gaining full admin access to the production site was two-factor authentication (2FA).

That didn’t hold up for long. The researchers identified a vulnerable admin endpoint that failed to enforce authentication, allowing them to reset 2FA secrets for any admin user account as long as they could guess a valid user ID (uid).

Image from the report at samcurry.net

With this flaw, the team gained access to sensitive data on real poker players, including personal details, deposits, and account information.

While several weaknesses contributed to the compromise, the failure to enforce authentication on the admin endpoint proved crucial, since it allowed the researchers to effectively bypass 2FA protections in the production environment. Read the report.

Vulnerability: Credentials Exposed in Nagios Log Server API

In a previous issue, we covered an incident at OneLogin where sensitive client secrets were leaked in plaintext through a vulnerable API response. Researchers Seth Kraft and Alex Tisdale have identified similar flaws in the Nagios Log Server platform.

This issue was originally reported a few months ago, but it again highlights how common it is for APIs to expose highly sensitive data. In this case, a non-privileged user could send a simple GET request to a vulnerable endpoint and receive a list of user records, including usernames and API keys belonging to administrator accounts.

Researcher Seth Kraft also shared a short demonstration video of the exploit on LinkedIn.

Sample from exploit-db.com

This type of excessive data exposure vulnerability falls under OWASP API3:2023, and often occurs when an API is implemented to return entire database objects without proper filtering or authorization checks.

This is where defining and maintaining an OpenAPI definition for APIs can help, by forcing teams to explicitly document which response properties should be exposed, and by enabling automated checks to detect drift between the intended design and runtime behavior of the API. Read the article.

Article: Staying Ahead of API Drift

Continuing on the subject of API drift, Kin Lane of API Evangelist recently shared insights from his experience working on an API governance program at Bloomberg.

He points out how API drift often stems from gaps in communication and vocabulary between engineering and business teams. It’s an interesting perspective, because discussions of API drift typically focus on unsanctioned code changes, misconfigurations, or even malicious API tampering.

For those unfamiliar, API drift occurs when an API’s production behavior deviates from its documented specification. Distinct from the traditional monolithic applications, APIs are updated frequently to meet rapidly changing business demands, whether that means new services, integrations, or hooking up the latest AI tool to some product or service.

As Kin points out, minimizing API drift requires maintaining alignment between product intent, usually captured in text-based documentation, and development intent, expressed through schemas and API definitions. Bridging these silos is a key factor to keeping APIs predictable and avoiding drift. Read the article.

Article: Risks of API Injection Attacks 

An article by Nordic APIs sets out some of the more dangerous or novel injection attacks that often target APIs.

The article includes examples of various attacks delivered through API properties and headers, as well as specific injection cases involving template values or URLs provided as user input, both of which we’ve covered in previous issues of this newsletter.

As an aside, it’s curious that injection vulnerabilities aren’t called out in the OWASP API Top 10 list. Admittedly it’s already a separate category in OWASP Top 10 2021, A03: Injection, but then so is Security Misconfiguration (A05), which is also included in the API Top 10 (API8). Given the prevalence and risk of injection attacks on APIs, it might be worth emphasizing in the OWASP API vulnerability list.

Automation tools like DAST (Dynamic Application Security Testing) are often used to simulate traditional injection attacks against websites and web applications using wordlists of common attack patterns. The challenge with APIs is that each one is unique, supporting a different set of input properties and processing logic. You have to get really lucky with DAST to hit on the particular injection pattern that can exploit a flaw in any given API. Knowing something about the context of the service behind the API helps to generate more relevant and targeted injection tests. There isn’t much benefit in running hundreds of SQL injection attacks against an API that uses a NoSQL database!

A great article on API vulnerabilities and well worth a read.Read the article.

Article: APIs in the Crosshairs of DDoS Attacks

In the previous issue of the newsletter, we covered a case of an accidental denial-of-service incident on one of Cloudflare’s API endpoints caused by a frontend coding error. A recent article on EM360Tech, “The API Blind Spot: How DDoS Attacks Are Bypassing Defences”, is a timely reminder of how API-targeted DDoS attacks are evolving, and why they’re often overlooked.

The article highlights the growing complexity of DDoS threats against APIs, pointing to both poor development practices and the emergence of AI-driven attack automation. It also outlines several attack types now common in the industry, from familiar flood and credential-stuffing attacks to more subtle Slowloris and Amplification attacks that can exhaust API resources while appearing as legitimate API traffic.

The key takeaway: mitigating API-level DDoS requires building secure APIs from the earliest stages of development, and implementing strong authentication and authorization ensures that only legitimate API users can access resources. Combined with measures like rate limiting and enforcing constraints on payload size, these practices help reduce the risk of API abuse and make DDoS attacks harder to execute. Read the article. 

The post Issue 282: Poker Hacks, Credential Leaks, API Injection Threats, and DDoS Risks appeared first on API Security News.

Vulnerability: Secrets Leaked by OneLogin API

Researchers at Clutch Security disclosed an incident involving excessive data exposure in OneLogin’s Identity and Access Management (IAM) platform. 

The vulnerable API endpoint is designed to list all OpenID Connect applications configured in a OneLogin tenant, and is accessible to any user with valid API credentials. But the researchers found that the response also included the client_secret property in plaintext for every application. This secret functions like a password for authenticating authorized clients, making its exposure highly sensitive.

Image from Clutch Security report

Unfortunately, sensitive credentials leaked in API responses is a common enough problem. In APISecurity.io issue 240, for example, a social networking platform’s leaky API exposed passwords, two-factor authentication tokens, and other confidential data.

Multiple factors can lead to these types of leaks: unsanctioned code changes, misconfigurations, or malicious data injected from upstream third-party APIs, or, increasingly, AI agents and LLMs.

One effective mitigation is using runtime schema validation on your most critical or sensitive APIs, which constrains response data to only the expected and authorized properties, preventing sensitive information from being inadvertently exposed. Read the report

Failure: Cloudflare Outage Caused by API Overload

The term denial of service (DoS) often crops up in news of malicious cyberattacks, but it can also happen by accident. A software bug in Cloudflare’s dashboard frontend code caused it to repeatedly call Cloudflare’s Tenant Services API, quickly overwhelming the service. Javascript developers will be familiar with the risk of unintentional loops from misusing React hooks, which appears to be what happened in this case.

Image from Cloudflare Blog Report

Cloudflare’s postmortem describes how the API outage rippled across their systems, disrupting other services including a critical API authorization function. One of the biggest challenges in managing cascading failures is diagnosing the root cause while simultaneously working to restore availability. In this case, the team set a global rate limit to help regulate the API traffic.

Global rate limiting can help shield infrastructure during a DoS event, whether accidental or malicious, but that can be a blunt instrument. Enforcing limits at the API level, especially for high-value services, can help to reduce the risk of failures spreading to dependent systems, and pinpoint the cause of an outage when similar mistakes, or attacks, occur. Read the report.

Vulnerability: Entra ID Tenants Exposed by Global API Token

Researcher Dirk-jan Mollema recently disclosed a critical access control flaw in Microsoft’s Entra ID that could allow a malicious user to take over other Entra ID tenants worldwide. 

Entra ID (formerly Azure Active Directory) is widely used by organizations to manage user accounts and access control policies. Ironically, this case involved an access control platform with a significant access control vulnerability. Exploiting it could give attackers unrestricted access to all downstream services and applications that rely on Entra ID for authentication and authorization.

The root cause stems from use of a global access token called Actor Tokens and a legacy API that failed to enforce proper tenant-level authorization. This flaw allowed a token issued in one tenant to be used to access any other Entra ID tenant, granting full access to the Azure AD Graph API.

Authorization flaws continue to be one of the most common API vulnerabilities, though we don’t often see cases with the potential for such broad and high-impact consequences. This one is worth a full read. Read the report.

Vulnerability: Mass Assignment Flaw in Rancher API

SUSE Rancher is “an open source container management platform built for organizations that deploy containers in production”. One of the platform’s APIs allows update operations on user accounts via PUT requests.

A flaw in this API lets a privileged user modify another user’s username, potentially preventing that user from logging in; effectively causing a denial of service. The risk is particularly severe if the affected account belongs to an administrator.

Image from CyberSecurityNews article

At first glance, this appeared to be an OWASP Broken Function Level Authorization issue, as it seemed the API shouldn’t allow PUT operations on this resource. On further reading though it’s more accurately classified as an OWASP Broken Object Property Level Authorization vulnerability (formerly known as Mass Assignment). The PUT operation should be allowed for privileged users, but the API should restrict updates to the username property once set. 

Hackers use mass assignment to exploit hidden features or logic flaws in API code, which can be harder for some security tools to detect than other input-based API attacks like SQL injection or path traversal.  OWASP recommends whitelisting allowed API properties and enforcing strict schema validation to prevent these vulnerabilities from being exploited. Read the article.

Vulnerability: Data Exposure from Apache Airflow API

If Mass Assignment is one side of OWASP’s Broken Object Property Level Authorization (BOPLA), then Excessive Data Exposure is the other. Both deal with APIs’ data properties:  Mass Assignment concerns unauthorized use of request properties, while Excessive Data Exposure involves unauthorized access to response properties.

A vulnerability recently found in Apache Airflow highlights the latter. A software update unintentionally reversed existing authorization controls, exposing sensitive information in API responses. Users with only Read permissions could suddenly view secrets such as passwords and tokens that should have been hidden.

Just as OWASP advises whitelisting request properties to prevent Mass Assignment (see the previous article), the same security recommendation applies to API responses: enforce strict response schemas so that only authorized properties are returned.

Organizations can also apply API drift testing to detect when a production API’s behavior deviates from expectations, whether due to code regressions, misconfigurations, or overlooked security changes. Read the article.

Vulnerability: Nokia Auth Bypass via Malicious API Header

An API vulnerability in two Nokia networking platforms, Nokia CBIS and Nokia Container Services, allows any user to bypass authentication and gain unauthorized access to management API services.  

A recent Cyberpress article describes details of the vulnerability, caused by a logic error in the API’s authentication code and the way user-supplied HTTP headers are handled.

During the authentication sequence, custom headers in the API request are parsed. Depending on their value, the flawed logic can route requests around the authentication check, giving unauthenticated users access to privileged management services on either platform.

“Exploitation requires sending HTTP requests with a header, for example X-Auth-Bypass: <token>, to management API endpoints.”

Nokia resolved the vulnerability by enforcing strict header validation and mandating mutual TLS for management API calls. These security controls, properly implemented, can significantly reduce the opportunity for attackers to exploit and breach APIs. Read the article.

The post Issue 281: OneLogin leaks secrets, Cloudflare API DoS, Entra ID flaw, OWASP BOPLA bugs appeared first on API Security News.

Vulnerability: Major API Flaws in Solar Power Systems

Many API incidents that we cover in this newsletter involve traditional clients like business apps and SaaS platforms using broken or vulnerable APIs. But APIs now underpin integrations and connectivity for everything from industrial power plants to smart home devices. As a result, API vulnerabilities are surfacing across more industries, though often in very similar ways.

Forescout’s report on solar power platforms is an eye-opening example. It uncovers multiple critical risks in industrial and home systems, many tied to API security. Part 2 of the report, “Growatt Vulnerability Details,” is particularly worth a read.

Many of the API vulnerabilities stem from missing object or resource-level authorization. In one example, a malicious user could remove ownership of a home device from a legitimate user, and allow the malicious user to take ownership and control of the device. 

The flawed API accepts a device ID (devId) parameter without verifying whether the current (malicious) user is authorized for that device, a textbook case of Broken Object Level Authorization (BOLA).

The report outlines multiple instances of BOLA/IDOR vulnerabilities in the Growatt solar power system. And as we’ve seen in our own research recently, BOLA is one of the most pervasive API flaws, showing up everywhere from India’s Government Tax portal to McDonald’s recruitment software, and in service robots used in hospitals and restaurants. 

Other API vulnerabilities documented in the report include an XSS flaw, where an API accepts a malicious script injected into a request property (“name”), without proper validation. And another involves a vulnerable password-reset service, where the underlying API exposes the email address of registered users on the platform to unauthenticated users. Plenty of valuable API security lessons to be learned. Read the report.

Vulnerability: LG Smart TVs with Dumb API Bugs

Another novel API security incident, this time in LG Smart TVs. The TV supports an API to allow connected devices download files from a specific folder or directory on the TV system.

The API defined a query parameter ‘getFile’ to allow a connecting device to indicate which directory in the TV system to grab files from: /tmp/usb or /tmp/home.office.documentviewer. But the API failed to validate the value of the getFile parameter.

By failing to constrain the value, it gives an attacker space to attack the system through the API. A pattern that frequently works, and is well documented, is a directory traversal pattern: “../../”, which allows a hacker to trick an API into giving unauthorized access to sensitive directories and files, including credentials and access tokens that can lead to a full system takeover.

These are very common attacks against APIs that accept file paths and URLS as input. So again one to watch out for. Read the report.

Vulnerability: AI Agent platform Exposing ATO Risk

Researchers recently discovered a vulnerability in Flowise, a platform for building AI agents, that exposed users to account takeover (ATO). 

The issue is related to the password reset API. Normally, these services validate requests by sending a reset link and temporary token to the user’s registered email address, ensuring only someone with access to that inbox can reset the password. But in this case, the API returned the reset token directly in the response payload. That meant an attacker could reset another user’s password without needing their email account.

The Flowise team has since fixed the issue by removing sensitive data like the token from the response. It’s a strong reminder that teams should carefully document and control API response data to avoid leaking sensitive information.

Password reset endpoints are a recurring weak spot. One of the Growatt solar power vulnerabilities mentioned earlier in this issue also involved a reset service, and we’ve covered similar cases in this newsletter: issue 275 “How to Avoid Password Reset Poisoning”, and issue 266 “Authorization Bug in Gitlab Password Reset API”. So these are services and APIs you should review closely for similar vulnerabilities. Read the article.

Article: Developer Survey Reveals AI Usage 

The Stack Overflow team has released its 2025 Developer Survey, and it makes for an interesting and insightful read about developer trends and challenges. 

Unsurprisingly, AI, and its discontents, features prominently in the survey this year. Some of the responses reveal both the opportunities and the downsides from using AI.

The highest percentage of developers report a lack of trust in AI’s accuracy, especially for complex or high-stakes tasks such as deploying software, monitoring systems, or conducting code reviews. AI tools are viewed more positively for learning or quick information retrieval, which probably aligns with most people’s AI experience.

The most consistent pain point emerging from the survey is that AI-generated output is rarely precise, and often requires rework. Debugging unfamiliar code produced by AI occupies a lot of time, undermining the efficiency gains developers hope for.

Some of these findings from professional developers match concerns about using AI in API security. While AI tools are helpful for routine tasks, critical processes still demand a human-in-the-loop to validate AI-generated outputs. Though this safeguard limits some of the key benefits AI promises: speed and scalability through full automation. Read the report

The post Issue 280: Solar device ATO attacks, Smart TVs & Dumb APIs, Password-reset & API bugs, 2025 Developer Survey appeared first on API Security News.

Vulnerability: Tax Records Leak with API IDOR Flaw

Researcher Aseem Shrey disclosed an Insecure Direct Object Reference (IDOR) vulnerability in India’s Goods and Services Tax portal that exposed sensitive taxpayer records. He noticed that the web portal retrieves tax payment data through an API request, and that the request includes a receipt ID. 

This often prompts a hacker to check if by changing a resource ID value can they access other users’ information. The fact that BOLA/IDOR is at the top of the OWASP API Top 10 vulnerability list suggests the answer is often a resounding yes! 

In this case,the API failed to verify that the current user is authorized to access a specific record, or object and so any user logged into the system could access any other tax payment record by simply changing the receipt ID.  This single API flaw risked exposing financial information of 11.8 million Indian taxpayers and companies.

APIs handling sensitive records must enforce strict object-level authorization and avoid exposing predictable IDs to prevent this type of vulnerability. Read the report

Vulnerability: Fleet of Pedu Robots vulnerable to BOLA

Another BOLA flaw to report, this time in the robot management APIs for a large Chinese robotics vendor. You’ve probably seen similar robots serving food or drinks in restaurants. Now apparently they’re also deployed at hospitals, offices, and retail stores. All controlled by Skynet (just kidding). 

A researcher demonstrated how API calls to control robots and change settings could be executed without proper authorization. While the APIs required an access token, no object-level checks were enforced. Once again, by manipulating identifiers in the payload, attackers could take remote control of robots they didn’t own, creating risks of physical harm, sabotage, or surveillance.

This highlights yet again why testing for BOLA vulnerabilities and enforcing strict object-level authorization must be a top priority for API teams. Read the report

Vulnerability: Layer 7 DoS Vulnerability in Hashicorp Vault

When people hear of Denial of service (DoS) attacks, they think of floods of traffic overwhelming a service. But APIs expose other ways for threat actors to knock out a service.

In August, Hashicorp Vault, a security platform for managing secrets and credentials, was itself found to be susceptible to a DoS attack when processing certain malformed API requests. Attackers could repeatedly trigger the issue to disrupt availability of the platform.

Hackers can use malformed payloads to exploit JSON processing with various tricks, using complex data structures, oversized strings, or patterns that overload server-side components. 

Teams can mitigate the risk from application-layer (layer7) DoS attacks by enforcing strict request validation: limit payload size and complexity, reject undocumented properties, and constrain user-supplied input to only what the API actually needs. Read the article

Vulnerability: US Grocery Stores Vulnerable to API Attacks

Emphasizing again the importance of input validation, another report of multiple API vulnerabilities in Copeland refrigeration systems, including a layer 7 DoS vulnerability.

Copeland refrigerators are widely used in grocery stores across the U.S., and could be remotely controlled through APIs to change settings and temperatures, with obvious potential for disruption and damage.

One of the APIs lacked input validation, allowing the researchers to crash the service with a malformed API request and trigger a DoS attack. Other issues included excessive data exposure, where APIs returned sensitive information such as password hashes, and insecure endpoints that allowed remote activation of critical OS services like SSH and Shellinabox.

APIs are everywhere, but the same design flaws surface time and again. Broken object-level authorization and weak data validation remain among the most common and dangerous API vulnerabilities across industries. Read the article

Vulnerability: Privilege Escalation Flaw in Security Platform

Even security platforms can ship with serious API flaws. A recent report outlines multiple vulnerabilities in Securden’s Privilege Account Management (PAM) solution, exposing it to authorization bypass and, ironically, privilege escalation attacks. 

One flaw stemmed from an endpoint that issued session cookies without requiring authentication. Those cookies could then be used to obtain a CSRF token and a secondary cookie, granting access to the API. Because the API failed to verify whether the cookies actually belonged to an authenticated user, attackers could bypass authentication altogether, demonstrating a case of broken authentication. 

In another case, an API allowed unauthenticated users to invoke privileged admin services, including backing up encrypted passwords to an attacker-controlled location. This highlights the need for strict function-level authorization checks, ensuring only users with the right roles and permissions can access sensitive operations. Read the report

Vulnerability: Broken Auth Exposes ESPHome Devices

ESPHome, an open-source technology widely used for IoT automation, was found to contain an authentication bypass in its embedded web server. The flaw allowed attackers to send API requests without credentials and control connected devices, putting homes and offices at risk.

A review of the code change in the ESPHome project shows the issue originated from a logic error in the authenticate function. Instead of validating full credentials, the function based the validation process on the length of the user-supplied credential.

ESPhome source code on Github

This meant an attacker could manipulate how the authenticate function works. In fact, by sending an empty Authorization: Basic header (so a length of zero), authentication was completely bypassed. 

This case highlights the importance of pre-production security testing, particularly around authentication and authorization. Automated identity and access control scans can help catch subtle flaws like this before threat actors find them. Read the article

The post Issue 279: Tax records leak, Hacked service robots, Frostbyte at US stores, Layer 7 API attacks appeared first on API Security News.

Before we dive in this week, a big thank you to everyone who dropped by the 42Crunch booth at Black Hat USA earlier this month and shared your thoughts on the APISecurity.io newsletter.

Hearing your feedback was very encouraging, especially stories from teams using lessons learned from API breaches to improve your own API development. That is exactly why we do this, and so very gratifying to get that feedback! 

Vulnerability: API flaws behind Intel websites

I came across a recent report on eaton-works describing multiple API bugs exposing Intel’s internal websites to breaches and corporate data leaks. 

From this case alone I noted at least four OWASP API Top 10 vulnerabilities. But the bigger lesson is one we see repeatedly in API incidents: a dangerous tendency to confuse client-side security with server-side security, and it’s the server-side API teams who are negligent.

APIs should always be built and tested under the assumption that attackers will target them directly. Even if an APIs is intended for use only by your own website or apps, hackers can bypass client-side checks, and ‘curl’ their way to your APIs. That’s why authentication, authorization, and request/response validation must be enforced on the server-side, regardless of what checks or constraints the website or app frontend enforces.

The vulnerabilities I noted in the article include: 

• API2:2023  Broken Authentication

• API3:2023  Broken Object Property Level Authorization 

• API4:2023  Unrestricted Resource Consumption

• API5:2023  Broken Functional Level Authorization

Did you spot others? 

Article: Headaches continue for Optus’ 2022 API breach

Australian telecommunications group Optus is back in the news this month over its 2022 API breach, which exposed the personal information of more than 9 million customers. Three years later, the reputational damage and financial costs are still mounting. 

We first covered the breach in 2022, and again in 2024 when a third-party investigation revealed the root cause as a coding error in an unused API. Optus had previously identified the same flaw and patched it on one endpoint, but failed to apply the fix consistently, leaving the exploited API unprotected.

Now, the Australia Information Commissioner, the national data protection agency, is seeking penalties against Optus for negligence in failing to adequately protect customer information. 

“All organisations holding personal information need to ensure they have strong data governance and security practices.”

Effective governance in this case means maintaining an accurate API inventory, and crucially bringing every API under proper security and lifecycle management controls, making sure to decommission APIs that are no longer in use. 

Vulnerability: API docs expose TeaOnHer users private data

TechCrunch researchers discovered API flaws in the gossip app TeaOnHer that exposed users’ personal information, including photos of driver licenses, without requiring authentication.

The app developer, maybe accidentally, published API documentation that defined both user and admin API endpoints. Crucially, some of the endpoints did not enforce authentication, so anyone on the internet could call the APIs to retrieve user information, including contact details, private comments, or photos of a user’s driver’s license. 

Notably, even though this case involved a sole developer, it was the same mistake in API security also at the root of breaches at large organizations like Optus and Intel: failing to enforce authentication. It shows there’s a recurring security gap that cuts across API teams of any size. As a security practice, it is crucial to document which APIs require authentication, and then regularly test or scan them to verify authentication controls are in place and effective. 

Article: Tips on designing APIs for AI 

One of the emerging requirements for safely integrating AI agents with external tools and services is precision in API design. There are two main drivers for this: security and integration.

On the security side, precise design and constraints in the API implementation helps reduce the risk of AI agents misusing or abusing APIs. For example, enforcing strict access controls and validating agent-supplied inputs against allowed structures, formats, and values, helps establish guardrails that prevent unintended or harmful API behavior, even when AI agents behave unexpectedly.

On the integration side, the clearer and more precise an API is designed and documented, the easier it is for AI agents to automatically discover and use it. This is true for all API consumers, but it is particularly critical when working with probabilistic AI systems, where small ambiguities in design can cause major integration and usage issues.

This Nordic APIs’ article highlights how well-structured error messages play a role in making APIs more usable for AI agents. Standardizing API response codes, message structures, and semantics can go a long way to making APIs AI-ready and improve “agent experience” (you definitely don’t want to upset those agents!).

Great article, and worth a read.

Vulnerability: API bug provides more free McNuggests

API vulnerabilities have been reported in a number of McDonald’s apps and platforms by a security researcher in a detailed blog post.

This is the third API security incident involving McDonald’s covered in 2025. In Issue 276 (July), we reported a vulnerability in McDonald’s recruitment platform that allowed unauthorized API access. Earlier, in Issue 262 (January), similar flaws in McDonald’s online order and delivery system let anyone modify other customers’ orders.

In this latest case, a McDonald’s app rewards users with free McNuggets based on their reward points. The researcher found that the Web app only validated points on the client side. By bypassing the client and sending requests directly to the API, which didn’t enforce the same checks, users could claim free McNuggets without any points.

Other flaws identified include:

• API2:2023 – Broken Authentication: APIs missing authentication allowed attackers to overwrite corporate data.
• API3:2023 Broken Object Property Level Authorization: Arbitrary data could be inserted into food order API requests.
• API4:2023 – Unrestricted Resource Consumption: “New member” coupons, intended for one-time use, could be reused indefinitely via direct API calls.
• API5:2023 – Broken Functional Level Authorization: Regular users could access administrator-level services and sensitive information.

If that list looks familiar, take another look at the Intel API case from earlier. Again, there are clear parallels in the types of API vulnerabilities that occur often across teams and industries.

Notably, while investigating these vulnerabilities, the researcher temporarily modified private resources and recruited a friend, a McDonald’s employee, to test whether a regular crew member could access privileged systems. According to the blog post, the employee was later terminated by McDonald’s. Perhaps stretching the bounds of responsible hacking?

The post Issue 278: OWASP API Bugs at Intel, TeaForHer, & McDonald’s, Optus Breach Fallout, APIs for AI Agents appeared first on API Security News.

Vulnerability: WAF security hacked by HTTP parameter pollution 

Researchers at Ethiack uncovered security bypass vulnerabilities in a number of WAF products, demonstrating a cross-site scripting attack using a relatively simple technique to bypass WAF security. ‘HTTP parameter pollution’ exploits the fact that some application technologies interpret duplicate parameters in different ways:

‘https:\//example.com/path?myParam=val1&myParam=val2′ 

For example, an ASP.net application automatically combines the values from a duplicate parameter as a comma separated list or array:

myParam=val1,val2

Hackers can use this feature to break a cross-site scripting (XSS) attack pattern into multiple pieces in order to obfuscate the full attack pattern.

The team found that while WAFs will recognize the malicious pattern in its entirety, if the pattern is spread across multiple input parameters most WAFs fail to recognize the risk and allow the malicious request through to the server, where it is combined back into the full attack pattern.

This is a tricky attack to prevent for APIs, and clearly most WAFs aren’t up to the task. But the ambiguity around duplicate parameters can be removed by defining up-front a parameter’s data type, to clarify that it is not a list of array of values and so should only appear once in a request. 

Or If the API does need to support multiple parameter values as an array, best to set further constraints on the parameter values, to limit the room for hackers to smuggle through scripts, commands and other invalid input in a parameter pollution attack. 

One to watch out for!

Article: API Security – guided by tools but driven by expertise

This article outlines a good example of how developers can use AI tools effectively to produce secure APIs. A combination of a developer’s domain knowledge guiding an AI tool to automatically add the appropriate security controls in the API code, rather than trying to offload security expertise to AI.

While the article focuses on building secure APIs for the Fintech industry, this really should be recommended practice for any secure API development.  

First the article makes a great case for API security fundamentals: validate all inputs against strict rules, enforce rate limits to prevent abuse, and handle errors without leaking details. These are solid security recommendations, since they help build-in API resilience to common attacks. 

Next, the developer leverages an AI tool, GitHub Copilot in this case, to enrich the API code with the security controls, but with the critical eye of an experienced practitioner to watch for AI mistakes.

“A basic security check was performed using the prompt generated by Copilot’s code. However, we need to implement a more robust error handling check to enhance security.”

An interesting article and worth a read.

Vulnerability: API flaws in Base44’s vibe coding platform

Reports of vulnerabilities in AI agents, LLMs, and especially MCP solutions have surged in recent months. As with many emerging technologies, the rush to deploy AI-powered tools and integrations has often outpaced security considerations.

The latest example comes from Wiz researchers, who discovered critical API vulnerabilities in the Base44 vibe coding platform, a tool used by enterprises to build applications with the help of AI. Despite offering access control features that allow organizations to restrict application usage to invited users only, researchers found that the platform’s APIs allowed anyone to self-register for any hosted application.

The only requirement was an application ID, which was easily discoverable even for private enterprise applications. This bypassed access controls entirely, exposing private applications and potentially sensitive data to unauthorized access.

Authorization flaws remain one of the most common and dangerous vulnerabilities in API development. As AI-driven platforms become more widely adopted, they must be held to the same security standards as any production system.

Article: Define APIs with precision for AI integration 

A recent New Stack article explores how agentic AI systems discover and call APIs autonomously. There are some useful API design tips here that apply beyond AI clients, but are particularly relevant and important for autonomous systems, to limit the room for integration errors or malicious attacks.

The key message from the article is that vague or loosely defined APIs lead to unexpected behavior from both the calling agent and the API itself.

Without the precision of clear endpoint names, parameter constraints, and schemas, agents can either misuse input fields or misinterpret responses, causing unintended API behaviours.

Some recommendations to make APIs AI-ready include:

• Publish a well-defined OpenAPI contract with complete request/response schemas, parameter constraints, authentication schemes, error formats, and success codes. Agents can rely on that spec as a source of truth.
  
• Add rich, natural‑language descriptions at both API and operation levels. Include business intent and context, and relevant examples that help agents choose endpoints correctly.

High‑quality OpenAPI contracts are essential to clarify how APIs work, for consistent interpretation by clients, especially autonomous agents, and reduce risks of misuse, hallucinations, or unpredictable API behavior. 

Vulnerability: API developers exposed to attacks

Developers are already under pressure to secure production APIs, but now their local development environments are becoming attack surfaces too.

According to recent reports, a package from the popular Next.js framework contained a critical flaw that allowed remote code execution (RCE) attacks against the developer’s environment.  

“it exposes a local HTTP server with an API endpoint at /inspector/graph/interact that accepts and executes JavaScript code within an unsafe sandbox environment”

Attackers could send commands to launch applications on the developer’s local machine and potentially steal sensitive data.

A key issue was the failure to validate the Origin header in a request, which tells the API server where the request came from, allowing it to verify the legitimacy of requests and to enforce CORS protections. 

Without verifying it against a trusted list, the server accepted requests from any source, bypassing CORS protections and enabling exploitation from malicious origins.

The case highlights key lessons: always apply strict validation to headers like Origin and Content-Type, and keep software dependencies updated to avoid known vulnerabilities.

The post Issue 277: Hacking WAFs, AI benefits and risks, AI-ready with OpenAPI, Developers exposed appeared first on API Security News.

Article: How Discovery Hype Is Undermining API Security

An article on API sprawl highlights real risks that emerge when API governance policies aren’t enforced. But a misleading claim about “discovery” really stands out:

“API security is never the problem, it is always the discovery. Once you’ve discovered it, you’ll fix it.”

If only that were true. Unfortunately, decades of experience prove the opposite.

In reality, most API breaches involve known APIs that were simply not properly secured. And the persistent factors driving these failures are a lack of secure development skills and under-resourced security teams.

For instance, OWASP API Security Top 10 issues like BOLA and mass assignment are hard to prevent without secure coding awareness, and hard to detect without dedicated AppSec involvement and targeted testing. These are not “discovery” problems; they are design, development, and validation problems.

To be clear, for teams that have lacked strong API governance in the past, discovery can be a useful recovery tool to bring unmanaged APIs into scope. However, discovery by no means guarantees security, and sweeping statements like “API security is never the problem” risks downplaying the real effort required to secure APIs, and giving teams a false sense of progress.

Vulnerability: Another API BOLA at McDonald’s

Researchers Ian Carroll and Sam Curry published a new report detailing API vulnerabilities in a chatbot-based recruitment platform used by 90% of McDonald’s franchises.

They first gained admin access to a test account via weak credentials (username: 123456, password: 123456). From there, they began probing the platform’s APIs, which returned data on job candidates.

By simply decrementing a candidate ID in API requests, they were able to access real candidate information across McDonald’s franchises. The API relied on predictable IDs (classic IDOR) and failed to enforce authorization, allowing a test account to retrieve production data. Broken Object Level Authorization (BOLA) is number one on the OWASP API Security Top 10 and a common cause of API breaches.

Notably, this isn’t McDonald’s first BOLA exposure. In Issue 262, we covered a McDonald’s API that allowed researchers to modify other customers’ McNugget orders: “Unauthorized API access to McNuggets”.

These recurring BOLA flaws reinforce the need to enforce authorization checks at the object level. Without secure coding practices and robust API authorization testing, the same vulnerabilities will continue to be exploited.

Article: Blocking API Attacks with Input Validation

API vulnerabilities can exist at many layers of the stack, but most vulnerabilities are ultimately exploited through the API request.

For example, common API attacks involve:

• Malicious injection patterns in HTTP headers
  Use of invalid or stolen access credentials
  Input properties deliberately crafted to break or exploit API logic

An allow-list approach to input validation can significantly reduce this attack surface by restricting inputs to the strict requirements of the underlying service. For example, if an API expects a user-supplied UUID, it should immediately reject anything that isn’t a valid UUID.

A recent NordicAPI’s article highlights this best practice, sharing real-world examples, some of which we’ve also covered in previous issues, demonstrating how input validation can block API attacks to prevent serious breaches and data leaks.

Worth a read.

Breach: Weak Input Validation Exposes Cisco APIs

Multiple critical API vulnerabilities have been discovered in Cisco’s Identity Services Engine (ISE) that are now actively under attack. These API flaws stem from insufficient input validation, allowing unauthenticated attackers to upload and execute arbitrary files or code as the root user.

Cisco’s advisory suggests that at least one of the API flaws exposes a path traversal vulnerability:

“This vulnerability is due to a lack of file validation checks that would prevent uploaded files from being placed in privileged directories on an affected system.”

Path traversal allows an attacker to force an API to place files in unintended and potentially sensitive locations on the server. For example, an attacker could exploit a vulnerable endpoint using a URL like:

http://some_site.com.br/get-files?file=../../../../some dir/some file

The Cisco ISE platform is used to manage access control for enterprise networks, meaning these API vulnerabilities pose a serious risk to the security and integrity of business-critical resources, and highlights again the importance of robust input validation and secure coding practices when designing and deploying APIs.

Article: Tightening the first line of defense

In a post on the Hackernoon website, a developer shares his experiences from working on legacy NestJS projects and the risks exposed through poor data validation in the code.

Any validation is better than no validation, but loose validation can still expose software to a range of different attack vectors such as SQL injection and path traversal attacks, not to mention subtle business logic attacks that are more difficult to discern through content inspection.

The writer shares an example of the classic “isString()” validation check, which, while useful, still leaves hackers with plenty of room to test and probe software for vulnerabilities.

This underscores the need for solid input validation, not just checking types, but enforcing additional constraints like length, format, patterns, and value ranges. For APIs the OpenAPI format provides a standard way to define data constraints up front in an API contract,

The contract then acts as a blueprint: developers use it to build proper validation into the API, and security teams use it to test whether those validations are actually enforced. It’s a simple way to catch invalid input and keep APIs tight, predictable, and secure.

Industry Event: Black Hat USA

Next month, all cybersecurity roads lead to the Black Hat USA event in Las Vegas. If you are attending the event this year, be sure to visit the 42Crunch booth (#1967) where our team will be on hand to answer all your API security-related questions. If you would like to book some time with the 42Crunch team, simply reserve a slot here.

The post Issue 276: API discovery hype, BOLA at McDonalds, Cisco APIs exploited, input validation best practices appeared first on API Security News.

Breach: Popular Indian Gold Trading Platform Hacked

A well-known digital platform for buying and selling gold in India has suffered a significant security breach, enabling attackers to gain unauthorized access to sell customers’ digital gold holdings. According to multiple Indian news outlets, this breach at Aditya Birla Capital Digital Limited (ABCD) was traced to vulnerabilities in the company’s APIs.

“This flaw allowed the hacker to bypass security protocols, access user accounts, sell their digital gold holdings, and transfer the proceeds to various personal bank accounts”

Although the latest reports haven’t yet shared specifics of the API vulnerability, they confirm that attackers managed to circumvent an additional layer of protection: a one-time password (OTP) sent to the target users’ registered device.

This detail is similar to a case we covered in issue 272 of APISecurity.io, where a vulnerability in Volkswagen’s API also exposed OTPs and compromised user data.

These breaches highlight that having security controls in place isn’t enough. Organizations must rigorously assess the strength, implementation, and reliability of those controls, as API attackers are increasingly targeting the weakest links in authentication and authorization flows.

Report: Critical API Security Gaps at 84% of Companies 

A recent survey by Raidiam reveals critical deficiencies in API security across a range of organizations. The report evaluates each company’s API security posture relative to the sensitivity of the data their APIs expose, such as personal or payment-related information.

This survey focuses on companies that are not subject to strict regulatory frameworks like Open Banking. In other words, it spotlights how organizations manage API security when they’re left to define their own standards. While most companies had some API security controls in place, the findings are hardly encouraging:

• Widespread use of weak or insecure API authentication methods 
• Lack of fine-grained authorization, leading to over-privileged access 
• Insufficient or nonexistent API security testing

Of the 68 companies assessed, 57 (84%) were classified as needing to “Act Urgently”, meaning their current API security practices are inadequate for the sensitivity of the data they handle.

The survey results underscore our key question: how secure is your API security, really? 

Vulnerability: Weak JWTs Expose the Manufacturing Sector

A report in SecurityWeek describes critical vulnerabilities in Microsens’s NMP Web+ product, used worldwide in the manufacturing sector. The vulnerabilities allowed unauthenticated attackers to forge JWTs and gain admin access. Among the issues: use of static JWT secrets and tokens with no expiration. These flaws enabled attackers to bypass authentication entirely and maintain indefinite access, making it a textbook example of how poor access token implementation can undermine an entire security model.

These types of JWT weaknesses are common targets for attackers. For instance, issue 274 detailed a similar case involving an unprotected payments API exposed through weak JWT validation (“Case Study: JWT Validation & Unauthorized Payments”).

API protection security policies should enforce robust JWT practices. At a minimum, ensure:

• Secrets are rotated and never hardcoded.
  
• Short-lived tokens with strict expiration are enforced.
  
• All JWT claims and algorithms are validated.
  
• API Tokens and requests that fail any part of the policy are rejected outright.

Vulnerability: How to Avoid Password Reset Poisoning

Security researchers and ethical hackers provide a valuable service to the API community by uncovering real-world vulnerabilities and helping developers understand how to avoid them. On that note, this detailed report by researcher Pratik Dabhi is well worth a read.

Continuing our theme of “how secure is the security?”, Pratik explores flaws in password reset functionality. Most apps and websites offer this feature to help users safely recover access to an account. But as this case shows, a weak implementation can become a backdoor for attackers.

By probing the application and its related endpoints, Pratik discovered a way to manipulate the system into generating a malicious password reset link, using the host header in a request.

Input validation, especially for data-rich APIs, often focuses on validating request bodies or URL parameters, often used as a vehicle for injection attacks. But this case is a reminder that headers can also carry risk from malicious input, and so should be considered untrusted and carefully validated. 

A great write-up that might encourage urgent code reviews and security testing!

Breach: API Drift with Malicious Intent for CoinMarketCap

When a third-party API changes unexpectedly, it can break consuming applications or websites relying on specific media types or response formats. But broken functionality will be the least of your concerns when API changes are driven by malicious intent.

A recent API incident involving the cryptocurrency group CoinMarketCap is a perfect example of the risks from unsafe API consumption, highlighted in OWASP API10:2023. 

GBHackers reports that CoinMarketCap used an API to dynamically pull a doodle image for its homepage, but attackers modified the API response to serve a malicious JSON payload instead. The response included JavaScript that ended up embedded on the CoinMarketCap site, tricking users into sharing details about their crypto wallets.

This is one of many reasons why maintaining public documentation for an API has value both for API integration and security. If APIs are delivered along with well-maintained documentation, consumers can routinely test their dependency APIs for drift, which provides teams with an early warning of breaking changes or emerging vulnerabilities in dependency APIs and supply chains.

Industry Events: Nordic APIs Security Unconference, October 13 

Coming in October, Nordic APIs will host an API Security UnConference in the beautiful city of Stockholm, covering topics like API access and identity management, OAuth and OpenID Connect, securing AI agents, governance and monitoring, documentation strategies, sector-specific standards, and more.

Unlike traditional conferences, the unconference format promotes open, participant-driven discussions, spontaneous idea-sharing and real-world problem-solving among peers.

Sounds like a great opportunity to connect with fellow API security professionals and dive deep into current challenges and solutions.

Check out the press release for more information about the event.

The post Issue 275: API hackers strike gold, Malicious API drift at CoinMarketCap, Survey reveals major API security gaps appeared first on API Security News.

Case Study: True Nightmares of Authorization

By guest contributor Rob Spectre, DevRel at Oso.

It’s 5:45pm on a Friday. A small uptick in HTTP 400s and 500s pops up on an internal customer management tool. Within the hour, the entire engineering team at a hypergrowth startup scrambles to respond to a security intrusion – one that this technical leader will never forget. 

Oso kicks off a new series called “True Nightmares of Authorization” in interviews with engineering and product professionals about some of the worst moments of their careers. The details and identities are kept confidential, but the stories – and the months of pain that followed – are real. Read the first one – The tale of the Pwned Password Pilferer.

Case Study: JWT Validation & Unauthorized Payments 

Real-world incidents highlight why API security matters and can help to avoid repeating the costs and pains other API teams experienced as a result of a vulnerability. 

The RSAC article by Ravi Teja Thutari “Three Outages That Changed How We Think About API Security” does exactly that, similar to the Oso series, by focusing on impact and lessons learned.

In the first case, a payments API failed to properly validate JWT access tokens due to a misconfiguration in an API Gateway. It’s a classic example of how a simple change can expose a serious vulnerability and highlights why defense-in-depth is crucial. 

The second case involved an API bug that led to a service outage and denial-of-service (DOS).

While edge devices like gateways provide general rate-limiting, APIs often require more fine-grained protections tailored to the specific service they expose. For example, Auth APIs are often a target of brute-force attacks on login or one-time-password validation services, and benefit from tighter, API-specific restrictions. 

The article contains some really useful insights, worth a read!

Article: 23andMe Fined £2.3M over API Breach

Still on API rate-limiting: the Guardian reports that the UKs Information Commissioners Office (ICO) has fined genetic testing company 23andMe £2.3 million for a 2023 data breach.

A threat actor used a credential stuffing attack against a login API, using stolen credentials to exfiltrate the private data of over 155,000 UK residents. 

Delving into the ICO’s Penalty Notice, the company was primarily fined for inadequate security, lacking multi-factor authentication and, in particular, ineffective rate-limiting rules and alerts:

“organisations should ensure that they are rate-limiting or throttling the number and frequency of incorrect login attempts… limiting to a certain number per hour, day and month is a good idea.”

23andMe did apply IP-based rate limits, but this is (and was) easily bypassed using rotating IP addresses. More elaborate API security policies are needed, such as tracking login attempts per user and using device fingerprinting. 

Behavioral analytics can also help flag unusual activity, but this approach tends to only react after suspicious activity emerges over time, making it useful for long-term damage limitation rather than stopping an attack early in real time. 

Notably, 23andMe filed for bankruptcy protection in the US earlier this year.

Vulnerability: Bykea API Exposed by Classic BOLA Vulnerability

Strengthening the case for its top spot on the OWASP API Security Top 10, another Broken Object Level Authorization (BOLA) vulnerability has been reported, this time in an API belonging to ride-hailing and logistics company Bykea. 

The security researcher provides a clear and well-documented walkthrough of the vulnerability and exploit, setting up “victim” and “attack” accounts to show how an attacker can easily access a victim’s data when API developers fail to implement proper object-level authorization checks. 

In a nutshell, API developers must ensure that every request to access a resource includes a check to confirm the authenticated user has permission to access that specific object. 

BOLA, a post-authentication vulnerability, is one of the most common and dangerous API vulnerabilities. Reducing the risk means raising developer awareness of secure coding practices, and QA teams adding identity-based automated tests to catch these security issues before production.

One to watch out for.

Vulnerability: Asana’s MCP Data Exposure

Staying on the topic of resource-based authorization: in the last issue of APISecurity.io we looked at the expanding usage of Model Context Protocol (MCP) to extend the capabilities of AI agents and servers through APIs, and its inherent risks from authorization vulnerabilities. 

This week, Upguard reports a case of potential data exposure in Asana’s MCP server, where a bug may have exposed private data to other Asana users and organizations. As it is with API security, least privilege access will be a key concern when it comes to adopting and integrating MCP.  

The MCP specification recommends OAuth for authorization. A section on ‘Security Best Practices’ describes and illustrates authorization flows between MCP clients and servers, third-party APIs and Authorization servers. It also outlines potential attacks targeting MCP implementations and recommended security measures. 

The Asana incident doesn’t appear to be the result of an attack, rather an implementation bug that leaked unauthorized user data. Which may highlight the steep security challenges teams face with MCP adoption, including safe and secure implementation of OAuth-based flows. 

Resource: Cloud Native Data Security with OAuth

Finally, this week, here’s a valuable new resource for anyone working on API security: Cloud Native Data Security with OAuth. The book by the team at Curity describes steps to implement OAuth, and outlines how access tokens, scopes and claims can be used for secure, fine-grained API authorization. 

I’ve been referencing it recently while configuring authorization workflows and found it very useful, both as a refresher on core concepts and for understanding some of the more advanced aspects of securing cloud-native APIs across microservices or Kubernetes clusters. 

Authorization issues remain one of the most persistent challenges for API teams, and more so now as new protocols like MCP enter the picture. As highlighted again in The New Stack’s recent article, OAuth plays a foundational role in securing AI agents that interact with APIs and services via MCP. Without securely designed APIs and well-implemented OAuth flows, there’s a real risk of data exposure, especially as LLMs start to access sensitive organization data.

This book is certainly one I’ll be adding to my API security library, highly recommended. 

The post Issue 274: Authorization nightmares, API security case studies, 23andMe fined £2.3M, OAuth for Cloud Native APIs appeared first on API Security News.

Article: Heavy on artificial, light on intelligence

A recent report about Builder.ai, a startup alleged to have falsely marketed its product “Natasha” as an autonomous AI software developer, is a clear warning about the dangers of AI hype. Despite the company’s public claims of delivering an AI-driven software generation service, it was actually a team of 700 human developers behind the scenes doing the work.

The incident exposes a deep industry problem: the wildly unrealistic expectations placed on AI. Even leading AI companies are more realistic about AI’s limitations. For example, in a recent article “Anthropic’s AI is writing its own blog — with human oversight”, Anthrophic admits using experts to review AI output before publishing even a blog post!

So the idea that AI is ready to autonomously write complex production-ready software, or for that matter to automatically secure API transactions in real-time, without human oversight is, frankly, pure fantasy. 

AI can be a tool for developers, not a replacement for developers. As this incident shows, it’s time to ground discussions about AI in reality. 

Vulnerability: Mozilla API flaw allows malicious account deletion

A security researcher ethically disclosed a high severity vulnerability discovered in Mozilla’s account deletion API. The flaw allowed an authenticated user to delete other user’s accounts simply by substituting their email address in the API request. 

This is a textbook case of Broken Object level authorization (BOLA), the top-ranked issue on the OWASP API vulnerability list (OWASP API 01:2023). BOLA occurs when the developer fails to properly check if a user is authorized to access or manipulate a specific resource. 

For API authorization, it’s often not enough to verify the user’s authentication and role; developers must ensure the user is also authorized for the specific resource being requested. Without that important check in the API code, a threat actor can exploit the API by changing object identifiers in the API request, such as email addresses or user IDs, to point to another user’s resources. 

Mozilla awarded the researcher a $6,000 bug bounty, highlighting the importance of testing for proper authorization checks during API development. 

Vulnerability: 50,000 Azure AD users exposed via unsecured API

Researchers discovered an unsecured API endpoint exposing data on over 50,000 employees at a major aviation company. The API issued access tokens for Microsoft Graph without requiring authentication (OWASP API 02:2023), allowing anyone to query the company’s Microsoft Graph APIs and retrieve employee records and identity data. 

The vulnerable API was embedded in a public Javascript file, and developers may have assumed the API didn’t require authentication because it was only intended for use by a trusted web client. But as we previously highlighted for similar cases (Issue 270 “Unprotected APIs expose 33,000 employees”), it’s trivial for hackers to find these vulnerable APIs on websites and mobile apps, and exploit them. 

The key lesson is that all API endpoints must be individually secured, regardless of their intended use. Public-facing APIs are always discoverable and exploitable. API authentication, access control and server-side input validation are essential. Obscurity is certainly not security.

Vulnerability: Recruiter emails leaked in API response

A vulnerability in an API used by Naukri, a popular job search platform in India, exposed the email addresses of recruiters viewing job candidates profiles. 

Security researcher Lohith Gowda discovered that when candidate profiles were retrieved, recruiter emails were unnecessarily included in the API response; a classic case of excessive data exposure (OWASP API 03:2023).  

While leaking recruiters’ email addresses might seem low-risk, it does reveal sensitive context, such as which recruiters are interested in which candidates. This opens the door to targeted spam, social engineering, or spear phishing campaigns.

Developers are often advised to apply the principle of least privilege when coding an API’s response data, only returning the data strictly required and authorized for the client.

Industry Report: 78% of API attacks happen after authentication

A recent report by CDNetworks reveals that 78% of API attacks occur after successful authentication. Attackers are using valid credentials, whether through stolen API keys, hijacked sessions, weak passwords, or even newly created accounts, to launch their attacks from inside the target system.  

Once a user is authenticated and access is granted, the next line of defense is authorization and API data governance. 

Role-based authorization (RBAC) helps to limit what authenticated users can see or do. 

Resource-level authorization, such as protections against BOLA vulnerabilities, helps to prevent lateral movement within the system, ensuring users can only access resources explicitly tied to their account. This can significantly reduce the impact of attacks by authenticated users. 

The report also cites Gartner’s Market Guide for API Protection, which notes that the average API breach exposes at least 10 times more data than a typical security breach. This increased risk stems from the fact that every API exposes unique data properties, requiring tailored security measures at the API level.

This can be addressed with strong API design and runtime data validation, using developer-defined data schemas to reject unexpected or malformed data, and block common API logic abuse and injection attacks. 

Vulnerability: Does MCP pave over the cracks in API security?

The recent GitHub MCP server vulnerability highlights a growing and perhaps underappreciated risk: resource-based authorization remains a largely unsolved problem, at both the API layer and now at the emerging abstraction layer introduced by MCP (Model Context Protocol).

APIs have long struggled with Broken Object Level Authorization (BOLA), where attackers exploit insufficient authorization checks to access private resources. These vulnerabilities are inherently context-specific, and solutions must be customized for each API’s unique data structures, user roles, and business logic.

Just like APIs, authorization in MCPs will be highly context-specific. What an agent should be allowed to access in one scenario may be entirely inappropriate in another. This makes it unlikely that a universal, one-size-fits-all authorization model for MCPs will succeed, just as it doesn’t work for APIs. Instead, both layers will need fine-grained, customized authorization policies. There’s some work to be done by developers here.

As we scale the use of MCPs in AI-driven systems, the industry should ask: Are we solving API authorization vulnerabilities, or simply paving over them with a new surface of AI-native ones?

The post Issue 273: Dangers from AI Hype, Top OWASP Threats in Action, Emerging MCP Risks appeared first on API Security News.

Vulnerability: Volkswagen Authentication API Exposes OTP

A security researcher successfully hacked Volkswagen’s mobile app by launching a brute-force attack on an API used to validate a one-time password (OTP). Because the API was not protected by rate limiting, a hacker could send an unlimited number of requests to guess the correct 4-digit OTP code, circumventing the OTP security control for the mobile app to gain access to the target vehicle. 

Identifying this vulnerability prompted the researcher to investigate the other APIs used by the mobile app. The report also reveals:

• Sensitive data leaked in an API response, including plaintext passwords and secrets.
• Any vehicle’s detailed service history could be retrieved through an API request, requiring only the vehicle’s VIN (often publicly displayed on the windshield).
• The leaked service history data included personally identifiable information (PII) about the vehicle’s owner. 
• Telemetry data, driver credentials, and driver’s license numbers were also exposed via other APIs.

A previous Imperva report revealed that 44% of account takeover (ATO) attacks in 2024 targeted APIs. This finding is not surprising, as APIs are now widely used for authentication services, such as user credential validation and one-time password validation.

Network devices such as Gateways are often used to provide general protection against brute-force attacks, however Authentication APIs require more granular rate-limiting controls to protect against targeted API attacks.

Note that Volkswagen has now patched these vulnerabilities. 

Vulnerability: Users exposed by Instagram and Tiktok APIs 

Is your email address associated with an Instagram, Tiktok, or even a business account?

This type of information is valuable to threat actors, especially in bulk, where it can be used in mass credential stuffing or spear-phishing attacks. Returning to our previous topic on authentication APIs, a recent report highlights the use of malicious “checker” packages that automate requests to Instagram and Tiktok APIs to check which stolen email addresses were associated with an account on these platforms. 

A poorly designed authentication API can inadvertently reveal this information due to a discrepancy factor in the API’s response, such as the HTTP error code, the error message, or even the API’s response time.

HTTP 404 “account not found”  

HTTP 401 “invalid credentials”

These enumeration attacks are common enough that teams should pay attention to OWASP guidelines on authentication, which recommend APIs respond with a generic error message to avoid exposing a discrepancy factor that could be used to extract information about customers.

Vulnerability: API Expression Language Injection Attacks

Here’s another recent and interesting attack exploiting flaws in an API’s error response!

A watchTowr research team discovered an Expression Language Injection (ELi) vulnerability in the API of Ivanti’s mobile device management (MDM) product. The detailed report describes the team’s vulnerability discovery process, which I highly recommend if you’re technically inclined. 

My TL;DR version: the API unsafely handles malformed user input which is “evaluated” by the backend framework and returned in the error response. In the simplified example below, the user includes the arithmetic operation ‘7*7’ in the ‘format’ query parameter, and the API returns the calculated value ‘49’ in the error response.

Malicious API request:

GET /mifs/admin/rest/api/v2/featureusage?format=watchTowr%24%7b7*7%7d

Exploited API response:

"Format 'watchTowr49' is invalid. Valid formats are 'json', 'csv'."

This confirms that the API is vulnerable to ELi and could be exploited to execute malicious commands on the API server. 

This incident reminds API testers to be wary of APIs that include user input in the response, as they may be vulnerable to similar injection attacks. 

Developers can also avoid this vulnerability by designing APIs that return generic error responses to malformed or invalid user requests. 

Vulnerability: Malicious input bypasses Radware’s WAF 

Continuing on the topic of malicious user input, Radware’s Web Application Firewall (WAF) was found to be vulnerable to malformed input, either in the form of malicious payloads in GET requests, or by adding non-alphanumeric characters to bypass the WAF’s signature-based detection rules.  

“Notably, these flaws persist despite modern WAFs employing machine learning models for anomaly detection.”

This type of attack is commonly used by threat actors to automatically fuzz a web application or API with malformed input to detect any unexpected response from the target. An expected or undefined API response often reveals a vulnerability, such as a logic flaw or security misconfiguration, that can be further exploited. 

WAFs are useful in the web application space. However, APIs have an inherently larger attack surface than traditional web applications due to the numerous endpoints, data properties and parameters they expose. This can create blind spots for WAFs that weren’t designed for fine-grained API security. 

The report recommends implementing secondary input validation layers capable of blocking logically inconsistent traffic. In the API domain, a purpose-built schema or API contract validator can help to protect against these types of malicious input attacks.

Vulnerability: Cisco Platform API exposes privilege escalation flaw 

Finally, this week, further highlighting the importance of input validation for API security, a recent security advisory reports several vulnerabilities discovered in the Cisco Unified Intelligence Center platform, all due to “insufficient validation of user-supplied parameters in API requests”

All APIs require customized security because each has its own data properties and access control requirements. Most attacks against APIs are exploited via the API transaction, in the form of malicious request data or unenforced security controls, such as missing authentication or insufficient resource authorization (e.g. “this user is authorized to access this requested object”).

To be effective, API input validation must be fine-grained and enforce a data allowlist and security requirements tailored to the service provided by the API. This ensures that the API is designed to accept only valid requests and reject malicious or invalid requests by default.

The post Issue 272: Volkswagen API hacked, API flaws in Instagram & Tiktok, ELi attacks, Radware & Cisco API vulnerabilities appeared first on API Security News.

Industry Report: High numbers of API security incidents in APAC 

A new survey report on the costs of API attacks in the Asia-Pacific region revealed an average cost of US$580,000 per incident over the past year. Australia reported the highest frequency of incidents, with 96% of organizations affected, while China estimated the highest average cost at US$780,000.

The report also mentions that many causes of these API incidents could be identified by developers before the APIs are released. However, the report goes on to place more emphasis on production testing than developer testing, which I find odd because in production, vulnerabilities are already exposed, and the complexity of diagnosing and resolving issues related to production traffic is much higher for developers. 

The survey results indicate the top four likely causes of API security incidents as:

• API misconfigurations (22.3%)
• The network firewall didn’t catch it (20.8%)
• API gateway didn’t catch it (20.7%)
• Authorization vulnerabilities (20.6%)

API misconfiguration is a relatively broad category of API vulnerability. For example, among the various ways an API can be vulnerable to security misconfiguration, OWASP casts a wide net:

“Appropriate security hardening is missing across any part of the API stack”.

So, an API misconfiguration vulnerability (OWASP API8:2023) could be considered the root cause of other vulnerabilities, such as broken authentication (OWASP API2:2023), broken authorization (OWASP API1:2023), or excessive data exposure (OWASP API3:2023), depending on whether the vulnerability is categorized by root cause or impact. 

It’s an interesting survey, though perhaps lacks clarity on some key points. 

Vulnerability: Critical API security flaw in dating app ‘Raw’

TechCrunch researchers have revealed a security vulnerability in the dating app Raw, exposing users’ personal information and real-time location data. The flaw, an Insecure Direct Object Reference (IDOR), allowed unauthorized access to sensitive user details such as display names, birth dates, sexual preferences, and GPS coordinates accurate down to the street level.

We previously reported a similar issue in FeelD, another dating app, in issue 255 of APISecurity.io. These kinds of vulnerabilities are especially prevalent in applications designed for social networking, collaboration, or resource sharing, where APIs provide essential functionality to search for other members or for shared resources. 

These APIs must be carefully designed to enforce proper authorization and ensure that the data returned is filtered based on the requester’s permissions and context. For example, an API that fetches the current users own profile data will be different to an API that fetches other users profile data. Attempting to mix the two can further complicate the access control mechanism. 

Testing for authorization flaws in these scenarios is often complex. It typically requires simulating multiple user roles and permissions to fully assess authorization controls. However, this level of testing is essential for avoiding the top security risk in the OWASP API Security Top 10: Broken Object Level Authorization (BOLA).

Vulnerability: Unauthenticated API leaks OAuth credentials

A security researcher reported finding an API leaking OAuth2 credentials in plaintext. These credentials were part of a Client Credentials Grant flow, which is typically used for secure server-to-server communication. 

OAuth is widely recommended as a secure framework for API authorization. But not all OAuth flows offer the same level of security, and poor implementation can introduce vulnerabilities, such as credential leakage or authorization bypasses. In this case, the client credentials should remain strictly confidential, but were strangely returned in the response from an unauthenticated API. This may have been implemented intentionally by the developer for the sake of convenience.

The vulnerability was uncovered by inspecting network traffic from a web application. Unfortunately, it’s a common misconception among developers that APIs embedded in trusted applications are inherently secure or hidden from attackers. As the researcher’s detailed walkthrough shows, insecure web APIs are not only visible but also easily exploitable.

Vulnerability: xAI LLMs exposed to long term abuse 

Continuing on the topic of API credential vulnerabilities, a recent KrebsOnSecurity report reveals that a developer at Elon Musk’s xAI inadvertently exposed a private API key on GitHub. This key granted access to at least 60 private large language models (LLMs), including experimental and unreleased versions.

Some of these models were reportedly trained on proprietary data from SpaceX and Tesla, potentially exposing sensitive corporate information to anyone who came across the leaked key.

While the most critical failure was the exposure of the API key in a public repository, from an API security perspective, however, the situation was made significantly worse by the fact that the key remained active for two months after the issue was first reported. This demonstrates the risk of using long-lived API keys that lack an automatic expiration.

The recommended best practice is to use short-lived access tokens in place of static API keys. In the event of accidental exposure, these tokens limit the window of opportunity for attackers, helping to reduce the potential impact and the organization’s risk.

Article: API Sprawl and the case for governance

To wrap up this week, here’s an interesting article that explores the growing problem of API sprawl, where for example APIs are created and deployed without collaboration or oversight from security and operations teams.

As the author notes, API sprawl isn’t simply a matter of having too many APIs. The real issue lies in the way APIs are developed in silos, often without clear rules or shared standards. This leads to overlapping functionality, inconsistent documentation, and increased security vulnerabilities.

At the core of the problem is a lack of governance. Setting clear guidelines for how APIs are designed, shared, secured, and eventually retired, is the key. It means making sure that everyone is on the same page from the start and that there’s a process for keeping APIs consistent and manageable across the organization.

I noted one Ponemon report estimating that the average organization manages around 1,000 APIs, though in reality, I suspect the number is likely orders of magnitude higher for many organizations. A quick look through internal code repositories often reveals old API specifications, which can provide hints about the number of unmanaged APIs, as well as what an API does or what kind of security (if any) was added. These artefacts can serve as a useful view into past development practices, especially before any formal governance was put in place.

Meanwhile, without governance, APIs will continue to pile up fast and become hard to track or secure!

The post Issue 271: API breaches surge in APAC, ‘Raw’ dating app exposes users, API credential missteps & API sprawl appeared first on API Security News.

Article: AI Agents prompted to attack APIs

First up this week, an article by Facundo Fernandez on security vulnerabilities in autonomous AI agents highlights a growing concern for securing APIs from AI agents. The article provides examples of how an AI agent might be abused to launch common API authorization attacks, such as BOLA and BFLA from the OWASP Top 10 API security vulnerabilities list. 

Autonomous agents aren’t inherently malicious, but they don’t need to be. If you hand one an API token and let it loose with vague instructions, it might just exfiltrate data or perform sensitive actions purely by following what it thinks is a logical flow. The attacker doesn’t need to penetrate and exploit your APIs directly, they just need to socially engineer an AI agent.

At the end of the day, APIs are still gatekeepers to critical services and sensitive user data, and must ensure adequate and effective security on behalf of the user. So strong authentication and authorization will remain critically important API security controls. The bigger, or at least newer, challenge today seems to be fine-grained control over what agents are allowed to do via APIs, plus runtime validation that any API request from an AI agent aligns with expected behavior. 

The takeaway: if autonomous agents are becoming first-class API clients, they need to be governed as such. Trust, but verify. And preferably, constrain.

Article: Securing APIs for agentic access

As a counter to the security concerns raised in the previous article, Kristopher Sandoval of NordicAPIs recently shared his take on “5 Ways to Secure Agentic Access to APIs”.

Unsurprisingly, securing APIs against the relatively unpredictable behavior of AI agents calls for some advanced and, at times, novel solutions.

Among the recommendations, using an identity framework like SPIFFE to authorize API consumption, layering behavior-based access controls on top of attribute-based ones, and developing your own internal agents to intercept and manage API calls. 

But even for sophisticated clients, core API security policies and governance rules still need to be enforced by the API. If the baseline API security is lacking to begin with, any client, human or agent, can find and exploit API those gaps.   

Vulnerability: API flaw exposes agentic AI workflow tool

An API vulnerability was recently discovered in Langflow, a popular open-source tool for building agentic AI workflows. The flaw centers on an unauthenticated API that executes untrusted user input using Python’s ‘exec’ function. 

Researchers at Horizon3.ai published their findings after an exploit for the vulnerability was already made public. The issue allows an unauthenticated user to remotely execute malicious code on Langflow servers, effectively granting full control over the AI tool.

This incident highlights the importance of testing the exposed functionality of API endpoints that do not require authentication. Vulnerabilities can arise from two common errors: failing to enforce authentication when it should be required, or deliberately disabling authentication for an endpoint but unintentionally exposing sensitive data or privileged operations.

Open source tools like Langflow provide amazing value and the benefits of development velocity. But by adopting open-source tools and libraries, software teams inherit the burden of validating and securing that dependency. 

Vulnerability: LLM platform API undermines client-side security

A recent security advisory highlights an API authorization vulnerability in Dify, an open-source LLM app development platform. This vulnerability allows non-admin users to enable or disable applications via the API, despite the web UI restricting this functionality to administrators. 

The issue lies in the API’s failure to enforce proper authorization checks. While the UI correctly disables certain actions for non-admin users, the backend API does not validate the user’s role before processing requests to change application states. This discrepancy enables attackers to bypass frontend restrictions by directly interacting with the API.

APIs should never assume the frontend has handled authorization. Every API request must be authenticated and authorized independently to prevent unauthorized access or actions. Relying on the UI for security checks is insufficient, as APIs can be accessed through various tools or scripts, bypassing any client-side restrictions.

Vulnerability: Unprotected APIs expose 33,000 employees

In another recent report, unprotected APIs embedded in an internal web application were found exposing sensitive data of over 33,000 employees. These APIs returned names, contact details, device information, and internal project credentials, all without requiring authentication.

This incident is similar to the previous vulnerability discussed about the Dify platform: APIs servicing internal apps, whether web or mobile, are often deployed without proper security controls. In both cases, the problem wasn’t how users interacted with the application, but rather the lack of protection at the API layer.

Assuming APIs are internal or only accessible through a UI is a common mistake in API development. 

As more functionality shifts to microservices and APIs, every endpoint becomes a potential entry point. If it handles sensitive data or critical actions, it must be authenticated and authorized, no exceptions.

Discussion: Kickstarting an MCP server with OpenAPI

42Crunch founder and CTO Philippe Leothaud’s recent LinkedIn post has sparked an engaging discussion on the evolution of API design and its impact on automation and interoperability. Philippe suggests that well-crafted APIs, complete with a comprehensive OpenAPI Specification (OAS), can pave the way for automatically generating Model-Context-Protocol (MCP) servers. This approach could significantly streamline the development process, reducing manual coding and enhancing consistency across services.​

Several industry experts joined the conversation. Frank Kilcommins, Principal API Technical Evangelist at SmartBear, highlighted ongoing efforts to integrate MCP support into Swagger Codegen, referencing an open feature request on GitHub. Mark O Neill, VP Distinguished Analyst and Chief of Researcher at Gartner, pointed to potential challenges with using Arazzo in this context, specifically how to manage authorization across multiple APIs under a single MCP server. Erik Wilde from INNOQ also cautioned that automation doesn’t always produce optimal results, like generating OpenAPI specs from existing code.

Tools like Swagger Codegen already auto-generate SDKs and documentation from a well-crafted OpenAPI file, but the key to high-quality output lies in how precise and complete that description is. The richer the OpenAPI file, the more value you get from automation tools.

A timely and insightful discussion, well worth a read.

The post Issue 270: AI double agents, securing API access, OpenAPI-driven MCP, APIs expose 33,000 employees appeared first on API Security News.

Article: UKs NCSC promotes secure API development

The UK’s National Cyber Security Centre (NCSC) has published a detailed set of guidelines for the secure development of HTTP-based APIs. 

The guidance covers key areas including API design and threat modeling, documentation and asset management, and also secure development and testing practices.

A key recommendation is the use of standardized API specifications, notably OpenAPI, to fully document and describe APIs. OpenAPI enables clear and consistent documentation about the security controls required for an API, making it easier to test and verify whether those controls are implemented effectively. 

The NCSC also emphasizes effective API version management to prevent the use of deprecated or insecure versions, helping to maintain a strong API security posture.

Article: Expert tips for mastering OpenAPI design

In “OpenAPI: How to Handle File Management”, Lorna Mitchell shares practical tips for managing OpenAPI files as APIs grow in size and complexity. 

She highlights the value of a design-first approach and recommends using $ref syntax to reduce duplication and increase consistency. The article covers different ways to structure OpenAPI files, from the basics of shared components to more granular structures with one file per schema or operation. While each approach has trade-offs, the key takeaway is to find the right balance for your team’s workflow.

Increasingly, OpenAPI files play a central role in the API lifecycle. They power automated API testing, define runtime security requirements, and provide clear documentation for consumers.  

That’s why having a solid process, and the right editor tool, to manage and navigate OpenAPI files is crucial for effective API governance.

Article: Championing Security-Aware Developers in Australia

In a recent CyberDaily.au op-ed, “Paving a pathway to better Australian cyber security preparedness,” Pieter Danhieux highlights the need to prioritize security awareness across all roles, especially developers. Since developers can eliminate vulnerabilities before code reaches production, investing in their security training offers an effective first line of defense.

This aligns with the principle of developer-first security in API development, which embeds security early in the process. By integrating tools and practices into developer workflows, organizations can build secure APIs from the ground up, making them more resilient to being exploited from common attacks such as the OWASP Top 10 list of API vulnerabilities. 

Not incidentally, security expertise will remain crucial as code generation is offloaded to AI and the latest trends of vibe programming. LLMs are prone to vulnerabilities like prompt injection, so AI-generated code will still need to be reviewed by knowledgeable developers who can spot and correct vulnerabilities. 

Article: Steps to prevent data leaks from Postman collections 

A timely article on DZone emphasizes the importance of protecting sensitive information when using Postman for API development. It offers practical steps to prevent accidental exposure of credentials, API keys, and tokens. Some key recommendations include:​

• Running Postman’s Secret Scanner to detect and alert users to exposed secrets within their Postman workspaces.​
• Storing sensitive data in environment variables instead of hardcoding them into requests.​
• Using short-lived tokens and rotating them regularly to minimize the risk of unauthorized access.

These steps are particularly important in light of the CloudSEK report covered in an earlier issue of this newsletter, which uncovered over 30,000 publicly accessible Postman workspaces leaking sensitive data such as API keys, credentials, and tokens. 

Adopting the best practices outlined in the DZone article can help to mitigate these risks in your API development and testing environments. 

Vulnerability: Zabbix API exposes OWASP security flaws

Zabbix, a widely used IT infrastructure monitoring platform, recently patched several API security vulnerabilities, including SQL injection, user enumeration, and excessive data exposure.

The SQL injection and data exposure issues follow common patterns frequently seen in API-related incidents. OWASP provides well-established guidance for preventing such vulnerabilities, including enforcing strict schema validation on both request and response payloads, and using prepared statements or parameterized queries to mitigate injection risks.

The user enumeration flaw exploited a timing discrepancy in the login API. When a non-existent username is submitted, the API responds immediately with an error. However, if the username exists, the API performs an additional password check before returning a failure, introducing a measurable delay. This timing difference allows attackers to determine which usernames are valid, enabling a user enumeration attack.

OWASP again offers guidelines on secure coding practices, with examples, to mitigate the risk from timing attacks. Recommendations include adding protections against brute-force attacks, which help to prevent user enumeration attacks at scale, as have been seen in recent cases of mass data scraping through APIs at Trello, Facebook and LinkedIn. 

Vulnerability: Shopware API Vulnerable to SQL Injection

Another day, another API vulnerable to SQL injection! 

Shopware provides a self-hosted open-source e-commerce platform written in PHP. One of the platform’s APIs was discovered to be vulnerable to SQL injection. A team of penetration testers reviewed the original vulnerability along with the patch subsequently provided by Shopware, and concluded that the patch, in the form of a security plugin, was incomplete and that the platform remained vulnerable to SQL injection. 

The problem appears to be that the developer of the security plugin added security controls for the one property that was originally flagged as vulnerable, but didn’t check if other properties in the same API payload were also vulnerable to SQL injection. They were!

This is a good example of why secure by design is a better approach to the “firefighting” method of addressing vulnerabilities as they’re discovered. Rather than scrambling to patch individual instances of SQL injection vulnerabilities found in production, secure by design embeds security into the development process from the start, saving time and effort in the long run.

The post Issue 269: API Security Guidelines, Mastering OpenAPI, Security Flaws in Shopware and Zabbix APIs appeared first on API Security News.

Article: How HTTPS redirects can expose API data

In a March blog post, Cloudflare announced it will block all API requests made over unsecured HTTP at the network level, ensuring that all client connections use encrypted HTTPS.

Some API servers enforce HTTPS by redirecting HTTP requests to secure endpoints, this method still exposes sensitive data such as API keys or access tokens to potential man-in-the-middle attacks during the initial unencrypted request. 

Source: Cloudflare

Despite the widespread adoption of HTTPS, some web applications and APIs remain exposed to data leaks over unsecured HTTP connections. For example, research by automotive cybersecurity firm VicOne uncovered companies across the US, Europe, and Asia transmitting cleartext passwords from vehicle tracking systems over non-HTTPS connections, leaving sensitive data vulnerable to interception.

Disabling HTTP ports eliminates this risk, by ensuring that any attempt to connect over HTTP is blocked at the network level, before application-layer data or tokens can be exchanged.

If your server applications currently rely on HTTP-to-HTTPS redirects, it might be worth considering disabling HTTP ports altogether, to prevent exposure of sensitive API traffic.

Vulnerability: AI platform adds input validation to secure APIs 

Flowise is a popular open-source platform for creating AI agents and orchestrating LLM flows. A researcher recently uncovered an API flaw that allowed unauthenticated users to upload or overwrite arbitrary files on the platform. 

The researcher shared a detailed analysis of the API vulnerability. The API allows users to upload files to the platform. The request includes two user-supplied path parameters values. Those path parameters were later used in the code to construct a filepath to the location on the server where the file is stored. 

But the parameter values were not checked and validated by the API. This gives room for a malicious user to set malicious values, and when it comes to file uploads the path traversal pattern is a common tactic used to access unauthorized files and locations on a server. 

In this case the API vulnerability allowed a user to overwrite critical files on the server at unauthorized locations on the file system. Flowise have since fixed the API flaw to remove the vulnerability by adding proper input validation in the API code, ensuring the vulnerable user-supplied parameters can only be the expected UUID format.  

Teams can mitigate common API vulnerabilities by integrating robust input validation at the initial design and implementation phases for API development. This proactive approach helps eliminate weaknesses that attackers frequently exploit.

Article: The benefits of starting with an OpenAPI description

In a blog post on APIsYouWontHate.com, Phil Sturgeon makes a strong case for API first design. The post compares and contrasts the code-first and design-first workflows for API development, and describes some of the negative implications of rushing to the coding step as fast as possible.

One of the main pushbacks we hear from teams who are considering a design-first approach is all the extra time teams must invest in carefully preparing a detailed OpenAPI contract with enough specificity to clearly describe an API’s design intent.

However, as noted in his post, Sturgeon argues that this upfront investment during the early design phase reaps significant time savings throughout the rest of the API’s lifecycle. 

There is a long list of additional benefits to teams who adopt a design-first approach, such as leveraging the OpenAPI contract to automate functional and vulnerability tests, API code or mock services. Standardizing the API documentation quality also helps to reduce inefficiencies and improves the experience for API consumers to use and integrate an API. 

If you’re still on the fence about moving to design-first in your API team, this article must just tip the balance!

Vulnerability: Data whitelisting and API injection attacks

A researcher recently uncovered an API vulnerability in a WordPress plugin that exposed WordPress sites to SQL injection attacks against the site database.

The researcher shared an account of discovering the vulnerability in the plugin source code, where HTTP request parameters were passed unsafely to an SQL query. 

It’s worth noting that the API design allows users to select database table names. This is inherently insecure, as highlighted in the OWASP SQL Prevention Cheat Sheet:

“WARNING: Using user parameter values to target table or column names is a symptom of poor design and a full rewrite should be considered if time allows.”

The solution applied in this case was to enforce whitelist validation on the vulnerable parameters, so that only valid table names would be accepted by the API and malicious queries rejected by default. This helps to reduce the risk of vulnerability exploitation, but doesn’t remove the underlying vulnerability in the code. 

Using prepared statements or properly constructed stored procedures is the recommended way to safely handle user supplied data in database queries, though whitelisting and input validation also offers a defense-in-depth approach to secure APIs against injection attacks.

Article: DevSecOps with API Security by Design 

With the rise of frameworks, automation, and AI-powered tools, developers can now build and deploy APIs in a matter of hours, days at most. In teams following DevOps practices, developers often have full autonomy to deploy their own APIs with little to no oversight or security checks.

This rapid delivery model is great for meeting the ever-increasing demand for API-based applications and integrations. However, in software development, speed often comes at the cost of security. The result is APIs going live with critical vulnerabilities, exposing organizations to data breaches, remediation headaches, and compliance risks.

A recent DZone article highlights practical approaches to tackling these security challenges by embedding security into the early stages of API design, bringing the ‘Sec’ into DevSecOps. The article advocates for integrating threat modeling as a key design step, alongside reviewing API contracts and incorporating static analysis into the build pipeline.

These insights underscore the importance of shifting security left in the API development lifecycle. By proactively identifying risks before implementation, teams can significantly reduce security flaws while maintaining development velocity.

Vulnerability: Check the API Error Response for Leakage

This week I came across a security announcement for the Moodle LMS platform reporting an API vulnerability. According to the announcement one of the APIs on the platform was leaking user data in the API’s error response. A user did not need to be authenticated on the platform to view the leaked data of other users. 

The exposed user data included the user’s name, e-mail address, hashed password, last login IP, and some metadata. The term “some metadata” could of course mean many things, though leaking email addresses and hashed passwords is already a serious problem. 

A similar vulnerability made headlines last year involving a vulnerable API from the social media company Spoutible. We covered that case in an earlier newsletter.  In that incident similar user data was exposed in the API response, including hashed passwords and also codes and secrets for two-factor authentication. 

API security often focuses on protecting against malicious data on the inbound request. However as this case and previous cases highlight, API security must also include filtering data in the outbound request, to ensure all data returned in the API response is expected, valid and authorized. 

Schema validation on both the request and response payloads, including error response messages, can help to prevent painful data exposures from APIs.

Article: API Design Matters for Security

Finally this week, we highlight a recent post by David Biesack from APIDesignMatters on best practices for structuring query parameters in Web APIs.

David describes using query parameters to “parameterize queries”, by filtering API responses to return only relevant resources. He breaks down multiple design patterns for structuring query strings, whether handling single values, field-value pairs, or data ranges, offering practical guidance for API standardization.

The post also shares an example of defining query parameters formally using the OpenAPI Specification. Well-documented query structures not only improve consistency but also enable automated security testing. Attackers frequently exploit query parameters for injection attacks and business logic abuses, making strict design patterns a crucial defense.

By adopting consistent query conventions and enforcing valid input constraints, developers can make APIs more secure by design, another strong argument for why API design matters!

The post Issue 268: Cloudflare disables HTTP, Moodle and Flowise API flaws, DevSecOps & API secure design appeared first on API Security News.

Industry Report: Radware report highlights API vulnerabilities

Radware has published a new industry report analyzing attack trends in 2024. The section on “Web Application and API Threats” distinguishes API attacks primarily targeting API business logic or core functionality. 

This represents a unique challenge for API security, as attacks often target bugs specific to the functionality or data of each API. This makes it extremely difficult to apply generic security controls to effectively protect APIs against attacks. 

In the report, Radware noted a 41% increase in Web Application and API attacks since 2023. Vulnerability exploitation accounts for over a third of all malicious requests. 

The lack of proper API documentation is also highlighted as an indication of insufficient security or unmanaged APIs, which are frequently targeted by hackers. 

Vulnerability: Medical records exposed by unsecured API 

The UK’s National Health Service provides an electronic referral system through an ecosystem of online healthcare providers. According to a recent report, a whistleblower from Medefer, a company participating in the e-referral system, claimed that an unprotected API exposed medical records that were previously transferred to Medefer from the systems of the NHS.

“When a patient is referred to Medefer, the firm receives patient data from e-RS or the NHS Spine to make it available to medics, who provide online consultations”

Apparently the vulnerable API was accessible without any authentication. Although the company claimed to have fixed the issue within 48 hours, the whistleblower, a software testing contractor for Medefer, suggested the flaw in the company’s API may have existed for six years, according to reporting on ComputerWeekly.com.

The complexity of supply chains and ecosystems poses a major challenge for API security as threat actors will target the weakest link in the chain to compromise the entire system. At a minimum, access to private data via APIs should be protected by appropriate authentication and authorization controls. 

Medefer indicated that penetration tests conducted by a third party a few months earlier failed to uncover the API vulnerability. Either the API vulnerability was recently introduced, or the penetration tests left a lot to be desired!

Article: Will AI replace Pentesters?

Speaking of pentesters, an article on The Hacker News asks the question if AI is about to replace humans by fully automating penetration testing. 

A similar argument has been made about the impending demise of software developers at the hands of AI, although the quality of code generated by AI is not without its discontents.

Having reviewed hundreds of POCs and bug bounty reports while preparing the APISecurity.io newsletter each month, two impressive characteristics I notice in pentesters and hackers are persistence and ingenuity. 

While it’s easy to imagine an AI agent beating a human in terms of persistence, the ingenuity and instinct sometimes required to uncover a software security flaw are the result of years of experience probing and testing for signs of mistakes made by software developers. Which raises the question: can an AI know us better than we know ourselves?

Thankfully, the article concludes that rather than replacing pentesters, AI will be a very useful tool in the pentesters toolbox to automate tedious tasks, leaving humans to focus on the more high-brow tasks. It’s an interesting article and certainly worth a read! 

Vulnerability: Broken API Authorization exposes Zitadel IAM  

Zitadel is a popular open-source identity and access management solution. An authorization vulnerability was recently reported on 12 of the platform’s API endpoints used for administrative functions. 

Insufficient authorization checks allowed users with standard, non administrative privileges to use administrator level functions, including the ability to modify LDAP authentication settings to disable security controls and takeover other accounts.

API vulnerabilities that allow unauthorized access to privileged functionality are common enough to rank fifth in the OWASP API Security Top 10 list: API5: Broken Functional Level Authorization. 

Recommendations for prevention include denying access by default, and carefully implementing role-based access control. This is also the approach taken by the Zitadel team to address and resolve the API vulnerability. 

Article: API Security and OpenBanking in APAC

Open Banking leverages APIs to enable third-party providers (TPPs) like fintechs, payment services, and other financial institutions to gain authorized access to a bank’s customer data and provide value-added services.

To underscore the important role of APIs in OpenBanking, it’s worth taking a look at the UK Open Banking website which shares statistics on monthly API traffic for Open Banking transactions. For example, the site states that 1.9 billion successful API calls were made in the UK in January 2025 alone (approximately 61 million API calls per day). 

In Asia-Pacific, banks, payment gateways and fintechs also make extensive use of APIs as part of the expanding financial services ecosystem in the region. An article on The Register website discusses the challenges of securing a complex system consisting of thousands of interconnected APIs managed by many different API providers. 

“The security of the ecosystem is only as strong as its weakest link”

The article suggests several essential API protection mechanisms to deploy to strengthen Open Banking systems:

• Enforce multi-factor authentication and object-level authorization on every API request
• Block malicious data and injection attacks with API input validation
• Validate API response data to prevent unauthorized data leaks

These are good recommendations for any API that provides access to private resources, as the same API vulnerabilities and attacks occur frequently across all industries that use APIs.

The post Issue 267: AI to replace Pentesters, Radware Threat report, API bugs at Medefer and Zitadel, API holes in OpenBanking appeared first on API Security News.

Article: How Netflix and HSBC implement API Governance 

A recent article on The New Stack argues that API teams should establish a formal governance pattern early, before an informal one takes root. 

API governance provides a structured framework of policies and processes to guide API design, development, security, and maintenance. However, different organizations take different approaches, often influenced by their culture and operational needs.

The article reviews three key API governance patterns, analyzing their pros and cons through real world case studies of companies like Netflix, Paypal, HSBC and the Financial Times.

Some key takeaways:

• Netflix’s Central Design Authority (CDA) relied on manual API reviews by a dedicated team. While this ensured strong oversight, it quickly became a bottleneck as API development scaled. Automating design checks could have helped ease this burden.
• HSBC’s federated model of API governance introduced inconsistencies due to the varying levels of experience of API champions across the federated team. Here, increased  automation helped to bring more consistency and improve governance. 

For a deeper dive into API governance patterns and their real-world impact, this article is well worth a read!

Vulnerability: Lessons from India Post Office API Leaks

A security researcher recently uncovered an API vulnerability in the India Post Office website that exposed unauthorized access to sensitive Know Your Customer (KYC) information. The vulnerability highlights common pitfalls in API security practices, particularly around authentication and authorization.

One key takeaway from this case is how authorization was inconsistently applied. While the India Post website required users to log in to access their accounts, the underlying API calls to the backend did not require any credentials. 

This suggests the API developers relied on the website for authentication, potentially assuming that all API requests would originate from the trusted website and therefore additional authorization checks directly at the API level were unnecessary. 

Compounding the issue, the API was also found to be vulnerable to Insecure Direct Object Reference (IDOR). The API used a document ID parameter to retrieve KYC information:

GET /api/kyc/document?document_id=125678

If a malicious actor modified the document_id value to another customer’s document ID, the API would return the corresponding KYC information without verifying whether the requester was authorized to access that document. This lack of proper authorization controls made sensitive customer data easily accessible.

This case serves as a critical reminder for teams to enforce authentication and resource based authorization at the API, and never rely on client side security. 

Vulnerability: SQLi bug in Financial Services Platform API

Fineract is a popular open source platform for Financial Services, providing an Open API based core banking solution. A recent report revealed that some of the platform’s REST APIs were vulnerable to SQL injection exploits. Fineract developers addressed the vulnerability by introducing a SQL Validator component, which, according to the vulnerability report: “allows us to validate and protect against nearly all potential SQL injection attacks“ 

SQL injection remains a common API security vulnerability, despite the fact that effective preventative measures are well-documented and widely promoted. OWASP highlights that successful SQL injection attacks occur when two conditions are met:

1. An unintended data enters a program from an untrusted source.
2. The data is used to dynamically construct a SQL query

A defense-in-depth approach to API security would ensure that neither condition is met. API teams should follow secure coding practices to:

• Validate input and constrain API query parameters to only accept expected and safe values, rejecting all other input by default.
• Use recommended secure mechanisms like prepared statements or stored procedures to remove SQL injection risks.

By consistently adopting security best practices, API teams can mitigate their exposure to SQL injection as well as other injection-based attacks. 

Article: Best Practices in API Development

An article by NordicAPIs outlines key best practices for API development, emphasizing security, efficiency and building APIs that are easy to consume. Some of the recommendations include:

• adopting consistent naming conventions
• using HTTP methods appropriately
• adopting the Principle of Least Privileges
• planning for the full API lifecycle

In particular, the Principle of Least Privilege plays a crucial role in API security.  By ensuring that users, applications, and services only have the minimum permissions necessary, organizations can significantly reduce their exposure to Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA) – two of the most exploited API vulnerabilities.

This article is a great refresher on API security fundamentals!

Vulnerability: Authorization Bug in Gitlab Password Reset API 

I recently came across an interesting API security flaw on HackerOne. The original report dates back to 2023, but the vulnerability was only disclosed this week.  

The issue involved Gitlab’s password reset function. A user could intercept the underlying API request and modify the payload to add a second email address. This appears to be a feature rather than a bug, since Gitlab allows users to specify a secondary email address to receive password reset notifications.

However, the feature contained a fundamental flaw. The relevant Gitlab release notes provide more details about the vulnerability. 

The API failed to verify whether the second email address was registered and authorized for the target account. This error allowed an attacker to request a password reset for another user’s account, while adding their own email address as a recipient for a password reset link. 

This case highlights multiple ways APIs can be exploited, through business logic abuse as well as insufficient authorization controls at the object or resource level.  

Security testing can help to identify edge cases like these, where features could be exploited outside their intended use. 

The post Issue 266: API governance, KYC leak at the Post Office, SQL injection bug in Fintech API, API best practices appeared first on API Security News.

Industry News: OpenAPIs Overlays & Arazzo Standards

The OpenAPI folks have been busy! Lorna Mitchell, member of the OpenAPI Technical Steering Committee, shares her insights and some potential use cases for two new standards from the OpenAPI Initiative: Overlays and Arazzo. 

Both specifications open a range of new opportunities and potential solutions for API quality, security, testing and governance. Lorna describes a number of possible use cases for Overlays to automate quality checks and process updates on OpenAPI documents. The concept reminds me of working with XSLT stylesheets, eons ago, to transform SOAP messages; though thankfully using Overlays looks far more simple in contrast.

Likewise, Arazzo offers, among other things, many new ways to improve API security testing by constructing and validating real-world business scenarios in sequences of linked API calls. Also, my colleague Philippe Leothaud shared his observation on LinkedIn about how Arazzo has the potential to be an essential tool for building API infrastructure designed for AI consumption.

So, lots of exciting new capabilities and solutions in store for OpenAPI users!

Vulnerability: Leaky YouTube API nets Hacker $10,000

A researcher discovered vulnerabilities in YouTube and Google APIs that exposed the private email address of anonymous YouTube accounts. Just for good measure, exploiting an additional API vulnerability also ensured targeted users were not notified about the attack. 

First, the vulnerable YouTube API accepted a public channel ID in the request and returned an internal Google account ID (Gaia) in the response. This was the key vulnerability since it effectively verified a Google account ID for an anonymous YouTuber.

Next, the researcher found a vulnerable Google API to accept a Google account ID and return that user’s email address. This API was used by an older Google product called Pixel Recorder for sharing videos with other users. 

So in just two quick API requests, the private email address of an anonymous YouTuber was retrieved. Not so anonymous! 

One of the side effects of using the Pixel Recorder API was that it triggers an email notification to the targeted user whenever a video was shared, possibly alerting the user to the attack. The researchers found another API bug to prevent that email notification from being sent: setting an extremely long name for the title of the video. 

The API failed to enforce practical limits on the length of the title, which allowed the request to be processed and the email address retrieved, but also prevented the email notification from being sent due to the excessive length of the title.

This case underscores how hackers probe and test an API’s input and output properties for vulnerabilities. It also highlights the importance of setting practical constraints on API parameters to mitigate the risk from such attacks. 

Vulnerability: Excessive Data Exposure in Vulnerability Scanner

API security often emphasizes validating user input. However, the API response data should also be inspected and validated to prevent unauthorized leaks of private data.

A recent example of an API data exposure vulnerability was reported in ReNgine, an open-source reconnaissance and vulnerability scanner. The disclosure document provides a detailed breakdown of the bug, making it a valuable resource to learn about common API vulnerabilities. 

In this case, the API unintentionally returned excessive user information, including a password. This is similar to a previous case of API data exposure by the social media platform Spoutible.

One way to help avoid this is by consistently enforcing strict schema validation on API response messages. The task of defining a schema forces a developer to carefully consider what data should be allowed in the API response. This practice can help to uncover flaws and data leak vulnerabilities before APIs are pushed into production. 

Credit to the ReNgine team for setting clear guidelines for responsible disclosure and for quickly addressing the vulnerability. Credit also goes to the ethical hacker for documenting the issue in detail, providing the broader community with a valuable learning opportunity!

Vulnerability: API leaks Medical Records and PII 

A recent report highlights a case of medical records and patient PII (personally identifiable information) leaked through unprotected APIs. The API endpoints, along with security keys, were exposed in public Javascript files. If these are uncovered, since the APIs did not enforce authorization, a malicious user could leverage the APIs for unauthorized access.

In addition to lacking proper authorization checks, the vulnerable API was also designed to use sequential numbers to access patient records. This makes it extremely easy for a hacker to guess the IDs of patient records and use the API to perform mass data scraping. 

Why were the APIs to sensitive medical records left unprotected? It may be that the API developers assumed the APIs would only ever be used by a trusted client, with examples of the API requests “hidden” deep inside Javascript files that no one was likely to find. But as shown in the report, tools are available to scan public web assets and uncover a hidden attack surface, including API calls.  

This incident underscores a critical point for developers and security teams: even APIs intended for use solely by trusted clients must operate under the assumption that unauthorized actors will find those API endpoints and attempt to exploit them. API security should be baked into the API’s design with authorization and input validation, following principles of least privilege and zero trust.

Vulnerability: Unsecured Spring Boot API impacts Volkswagen 

The European ethical hacking group Chaos Computer Club reported how an unsecured Java framework API allowed them to access private keys that exposed location data of more than 800,000 Volkswagen vehicles, including vehicles used by law enforcement and prominent political figures. The vulnerability traces to the Spring Boot framework and an exposed actuator API endpoint. Actuator endpoints are provided for application developers to monitor and debug an application. These endpoints are unrestricted by default, which shifts the burden of ensuring proper configuration and security onto developers using the framework.

Here is a short summary of key points in the exploitation path.

• Researchers discovered an exposed Spring Boot actuator endpoint that required no authentication to access.
• This vulnerable endpoint allowed an unauthenticated user to access and download a snapshot of a Java application’s runtime memory, known as a heap dump.
• Within the heap dump, researchers found AWS credentials for an S3 storage bucket, containing 9.5TB of telemetric data, including detailed geo data (about 800,000 cars dumped their telemetry data every 24 hours).
• Additionally, the heap dump exposed client IDs and secrets, which could be used to generate JWT tokens and access other APIs to retrieve private user data.
  

Secure-by-default is an approach to technology development that advocates security being enabled by default, without users having to turn it on. This approach would ensure that security controls are enabled and properly configured out of the box. Unfortunately, this is not the case for many 3rd party dependencies, including frameworks, libraries and Cloud platforms, so users must review and ensure appropriate security controls are enabled.

Tip of the hat to 42Crunch’s Axel Grosse for contributing to the review of this case.

Webinar: API Security for the Connected Vehicle Ecosystem 

I’m thrilled to connect with automotive cybersecurity expert Darren Shelcusky to explore his deep expertise and valuable insights on successfully driving API security and DevSecOps programs in the automotive industry. Register for next week’s webinar

The post Issue 265: YouTube API privacy bug, Medical records leaked, OpenAPI News, Spring Boot API impacts Volkswagen appeared first on API Security News.

Industry News: Pwn2Own contest enhances automotive security 

By guest contributor Ling Cheng, Sr. Product Marketing Manager at VicOne Inc.

As software-defined vehicles (SDVs) become more prevalent, concerns over vulnerabilities and the risks of cyberattacks are increasing. By identifying zero-day vulnerabilities through contests like Pwn2Own Automotive, VicOne aims to strengthen security measures, promote cyberattack prevention, and lay the foundation for the future of vehicle security. These events allow zero-day vulnerabilities to be identified early, before they circulate in underground markets, enabling swift countermeasures to mitigate damage and enhance product security.

This is why VicOne’s collaboration with Trend Micro’s Zero Day Initiative (ZDI) vulnerability research community, to host Pwn2Own Automotive is so impactful. World-class security researchers conduct real-world testing of the latest automotive technologies to uncover zero-day vulnerabilities before they can be exploited. In just three days, 49 unique zero-day vulnerabilities were identified— exceeding the total discovered in 2023. By bringing these issues to light, Pwn2Own Automotive plays a key role in improving cybersecurity and building safer, more resilient vehicles. As the industry evolves, proactive risk management like this must be a priority for every automaker.

Read our blog for firsthand insights on the discoveries made during these three days.

• Day 1: 16 automotive zero day vulnerabilities uncovered read more  
• Day 2: Tesla EV charger exploits take the spotlight read more
• Day 3: New master of Pwn crowned and other day three highlights read more

Article: Vehicle cybersecurity skills are in demand

Vehicle electrification and connectivity are in high demand, with projections showing that by 2030, “95 percent of new vehicles sold globally will be connected”. However, this connectivity also expands the attack surface and increases the risks to vehicle owners from cyber attacks.

Meanwhile, regulations such as the US Cybersecurity Improvement Act and UNECE WP.29 in Europe are driving the need for automotive cybersecurity experts. In his article, CISO Luciano Ferrari makes the case for upskilling in vehicle hacking techniques as a critical career path.

Another key area offering a path into the automotive industry is API security, essential for safeguarding connected vehicles. With APIs now pervasive across the automotive ecosystem, skills in secure API design and development are crucial to preventing unauthorized access and cyber threats, and protecting drivers and their connected vehicles. 

Vulnerability: Researchers exploit API design bugs at Subaru 

Security researchers Sam Curry and Shubham Shah recently discovered critical API vulnerabilities in an employee website of automobile manufacturer Subaru. These flaws allowed unauthenticated users to remotely control vehicles in the United States, Japan, and Canada. 

The attack leveraged two key API vulnerabilities. The first step involved identifying a valid Subaru employee email address. These could be guessed with a simple LinkedIn search, but verification was possible through an auth API endpoint that returned an error message if the address was invalid, but a different response if it was valid. This behavior enabled attackers to systematically guess email addresses until they found one that was valid, a classic account enumeration vulnerability. OWASP provides useful guidelines for error messages.

Once a valid employee email address was identified, the researchers exploited a second flaw: the password reset endpoint. This endpoint allowed attackers to request a password reset for any registered email address without requiring any user verification. 

This vulnerability is another well-documented security issue flagged in OWASP guidelines:  “In order to allow a user to request a password reset, you will need to have some way to identify the user”.

By exploiting these two vulnerabilities, the researchers obtained employee credentials, granting them access to the Subaru employee portal. From there, they gained remote administrator privileges over customer vehicles.

Basic security controls can be defined during the API design phase and documented as part of the development lifecycle. Security teams can use the documentation as a foundation for testing and validating API security before deployment. Such collaboration between security and development can help to prevent blatant security vulnerabilities in production APIs.

Article: What vehicle safety can teach us about API security

In her article “Building a Secure by Design Ecosystem”, CISA Director Jen Easterly draws parallels between the evolution of automotive safety in the 1960s and the current state of software security, noting that we are in the “before seat belts” era of software development.

Much like the auto industry’s shift to safety features like seatbelts and anti-lock brakes to prevent accidents, Easterly argues that the software industry must prioritize secure design principles to prevent vulnerabilities. Drawing from her own software development experience at the US Army, the Intelligence community and Morgan Stanley, she reports the “undeniable” results from investing in secure software design and development practices. 

“We don’t have a cybersecurity problem; we have a software quality problem”

Strict regulations for functional safety govern the development of automotive software, with the goal of minimizing bugs and producing high quality and predictable (i.e. safe) software. That outcome is achieved through mandated software engineering practices like requirements verification, traceability, and testing.

The same principles apply to API security. The vulnerabilities and preventive practices are well documented. The challenge now is embedding security into the fabric of API development, from the first line of code to deployment, making it, as Easterly puts it, “a core identity for software developers.”

Webinar: API Security for the Connected Vehicle Ecosystem 

I’m thrilled to connect with automotive cybersecurity expert Darren Shelcusky to explore his deep expertise and valuable insights on successfully driving API security and DevSecOps programs in the automotive industry. Register

The post Issue 264: Pwn2Own Automotive 2025, Subaru APIs hacked, DevSecOps for the connected vehicle appeared first on API Security News.

Article: Universities are vulnerable to API attacks

APIs are the backbone of integrations between diverse systems and applications, providing a standardized framework for data sharing. 

This article explores the risks associated with API integrations in the education sector. It talks about APIs consolidating data from multiple sources into a single unified experience, to benefit students’ productivity. But, poorly implemented integrations can introduce vulnerabilities. 

The education sector has increasingly become a target for cyberattacks. A 2023 Malwarebytes report revealed a 70% rise in attacks on educational institutions, underscoring the growing need for robust cybersecurity measures.

One of the key vulnerabilities discussed in the article is a common oversight in API design. When APIs are intended for direct consumption by external users, such as third-party developers, the need for strong security controls is often apparent. However, when APIs are designed for consumption by trusted, authorized users, developers often make the mistake of omitting those essential security controls, because they assume, incorrectly, that all incoming requests are valid.

Our research at APISecurity.io frequently highlights this issue, particularly with mobile applications. Developers often assume that requests come only from trusted clients. However, attackers can easily bypass client-side security controls and directly exploit vulnerable APIs.

The article emphasizes that secure APIs must be inherently self-protective. All user input should undergo rigorous inspection and validation within the API itself. API security should never be offloaded to the client.

Vulnerability: API bugs in Trellix Enterprise Security Manager

A recent disclosure on the HackerOne platform highlights two API vulnerabilities in the Trellix Enterprise Security Manager (ESM). These vulnerabilities were ethically reported by a researcher and addressed by Trellix in a November software update.

The first vulnerability involves a path traversal flaw, enabling attackers to manipulate the API path to access internal APIs on the server without authorization. By inserting a directory traversal pattern into the URL, like ..; ,  attackers can redirect the API to an unintended endpoint, exposing sensitive functionality.

The second vulnerability stems from improper input validation in JSON requests. The API accepts malicious commands injected into a name property, allowing attackers to create a reverse shell to their machine and gain full control of the API server.

These API vulnerabilities could be exploited to fully compromise the Trellix security platform. To mitigate such risks, API developers should strictly define and enforce precise API input paths and property values, reducing the attack surface for these types of exploits.

Breach: Hackers deliver Malware via insecure Aviatrix API

Another platform with reported API vulnerabilities, the Aviatrix Controller is a widely used platform for managing security and encryption policies across multiple cloud environments. According to one report, attackers are already exploiting these vulnerabilities.

Researchers analyzing the platform’s code discovered that while many API input parameters were sanitized using the PHP escapeshellarg, some were not, leaving certain APIs exposed. This oversight enabled attackers to inject malicious input into the Aviatrix platform.

In their proof-of-concept, the researchers exploited the unsanitized parameter to send a curl request to the API server. The server processed the unsafe input and inadvertently executed the attacker’s curl request, establishing a callback to the attacker’s server. This test confirmed that an unauthenticated malicious user could execute arbitrary commands on the Aviatrix Controller through the vulnerable API.

This type of API vulnerability is very similar to the Trellix API vulnerability described earlier. A lack of validation of all input paths and parameters creates opportunities for attackers to exploit APIs.

To mitigate these risks, developers should follow best practices for input validation. The OWASP Input Validation Cheat Sheet provides valuable guidance to prevent such vulnerabilities in API code.

Article: Lessons learned from API misconfigurations

A recent article on the Nordic APIs website highlights the risks associated with API misconfiguration vulnerabilities, which can lead to serious security breaches.

The article provides a list of common misconfigurations that often arise during the API development lifecycle. It also delves into a recent incident involving Microsoft Power Pages, where default roles and access rights created a security vulnerability. This case study underscores the critical importance of addressing misconfiguration bugs.

The OWASP framework also identifies how APIs can be vulnerable to security misconfigurations, such as missing or disabled security controls, exposing sensitive information in error stack trace messages, or forgetting to apply software patches and updates.

Some of the recommended prevention strategies include:

• Ensuring all APIs are secured with HTTPS.
• Whitelisting only the HTTP methods that the API is intended to accept and process
• Restricting error response messages to avoid exposing sensitive information

These measures can significantly reduce the likelihood of API-related security incidents.

Article: Coding practices to remove common API vulnerabilities 

Finally, this article provides a straightforward summary of common REST API vulnerabilities, along with practical guidance on mitigating risks in your APIs. 

Vulnerabilities like BOLA (Broken Object Level Authorization), broken authentication, and insufficient input validation are often responsible for API exploits, data breaches, and leaks.

By understanding the root cause of these issues, and implementing the appropriate mitigation measures in the earliest stages of API development, you can proactively eliminate entire classes of vulnerabilities from your codebase.

You can use this article as a reference to security test your own APIs against common threats.

The post Issue 263: Trellix & Aviatrix API exploits, API risks in education, API configuration bugs & secure coding practices appeared first on API Security News.

Breach: Black-listing fails to block SSRF attack

A research team from Pretera has identified a critical server-side request forgery (SSRF) vulnerability in the popular invoicing software, Invoice Ninja. 

The root cause of the issue lies in the use of a blacklisting approach to mitigate such attacks. Specifically, the vulnerable code attempts to identify and strip out malicious strings from user input. For instance, the code aims to block SSRF attempts by detecting patterns like “file://” in user-submitted data.

However, by simply changing the input to use a different case, such as “File://”, researchers successfully bypassed the application’s security measures and executed the attack. This underscores a fundamental weakness of blacklisting: it cannot account for all possible variations of malicious input, making it a flawed and unreliable security mechanism.

I spent some time examining the underlying API traffic behind the Invoice Ninja application, and also found the API documentation online, which includes a schema definition for the API endpoint that processes the vulnerable data. If the API developers tighten the schema to explicitly define and allow only valid and expected data formats, then all other inputs including this SSRF attack could be blocked by default. 

This alternative method of input validation (white-listing) significantly reduces the API attack surface, making it much harder for attackers to exploit vulnerabilities like SSRF, SQL injections, and path traversal attacks.

Breach: Unauthorized API access to McNuggets

This detailed writeup by a security researcher highlights API authorization vulnerabilities discovered in McDonald’s India’s online delivery system. These vulnerabilities allowed unauthorized users to view and modify the orders of other customers, exposing critical flaws in the API design. 

The underlying vulnerabilities, BOLA (Broken Object Level Authorization) and BOPLA (Broken Object-Property Level Authorization) are included in the OWASP API Security Top 10 list.  These vulnerabilities typically arise from poor API security design, where developers fail to verify if a logged-in user has the necessary permissions to access a specific object (e.g. a food order) or to change an object’s properties (e.g. updating the delivery address or price of an order). 

To prevent such issues, authorization requirements must be explicitly defined and thoroughly documented early in the API development process. Also these requirements should be rigorously tested throughout the API lifecycle to ensure the authorization mechanisms are working as intended.

Fortunately for McDonald’s, this API vulnerability was ethically reported and fixed before the news got out about the potential for unlimited McNuggets at $0.01 USD!

Vulnerability: URL validation flaw in the Truecaller mobile App

A bug bounty report on HackerOne demonstrates how the Truecaller mobile app was vulnerable to XXS and SSRF attacks due to improper API input validation. 

The targeted API was designed to accept a URL as input, making it an attractive target for hackers. By injecting a malicious URL, hackers could manipulate the API to execute unintended actions or expose sensitive data.

In this specific case, a security researcher crafted an input by appending a valid URL to a malicious one. The API’s validation mechanism only checked the valid portion of the input but still processed the malicious segment, leading to the vulnerability.

Similar attack patterns that misuse URL path endings have been observed in other cases. For instance, a reported vulnerability in the Apache Solr platform API allowed attackers to bypass authentication by exploiting poorly validated input.

These incidents underscore the critical need for robust input validation as a cornerstone of API security best practices. 

The collaboration between the Truecaller team and the security researcher who reported the vulnerability highlights the value of open communication in identifying and resolving API security issues. Even if you don’t have a formal bug bounty program, it’s essential to provide a clear and accessible channel, such as a dedicated contact page, for ethical reporting of discovered API vulnerabilities. 

Industry report: APIs matter to software developers

JetBrains recently released their “State of Developer Ecosystem” report, providing a comprehensive look at what mattered most to developers in 2024. The survey gathered insights from over 23,000 developers worldwide.

The report highlights interesting statistics on developers’ preferred programming languages, the testing methodologies they use, and the growing adoption of AI tools to streamline development tasks.

From an API perspective, the findings reveal that 49% of developers focus on writing code to integrate with APIs and services (API consumers), while 41% develop code to provide APIs and services (API producers). This data underscores the central role APIs play in modern software development.

A notable implication of this trend is the expanding attack surface as developers create and integrate more APIs. Each API serves as a potential entry point for attackers, so developers must take ownership of API security by incorporating best practices during the design and development phases to safeguard their systems.

For those seeking more insights, the raw data from this research is available for download and further analysis.

Vulnerability: Improper use of Postman Workspaces

A research team recently spent a year analyzing publicly accessible Postman workspaces and uncovered over 30,000 instances of leaked sensitive data, including API keys, credentials and access tokens. 

We’ve previously covered similar incidents in this newsletter where teams inadvertently leaked private API keys and access tokens on other platforms like DockerHub,  Gitlab and Dropbox. So the issue isn’t so much the platform, but rather the development teams’ insecure practices for handling sensitive API information.  

The report provides some practical recommendations to secure your Postman workspaces which should help API teams to improve their security posture and avoid exposing APIs and services to unauthorized access. 

Given the prevalence of leaked API data, it’s also recommended for teams to carefully evaluate  the security implications of their chosen API access control methods. API keys and access tokens come with different trade-offs between ease of implementation and the level of security provided. 

For example, API keys are often simpler for developers to implement but typically lack expiration dates, leaving APIs more vulnerable to persistent attacks if compromised. In contrast, JWT-based access tokens usually expire automatically, reducing the risk from leaked tokens.  

For more information on token management best practices you can read this article.

The post Issue 262: API incidents in Invoice Ninja, McDonald’s & Truecaller apps, Jetbrains survey, Postman data leaks appeared first on API Security News.

Before we dive into this week’s newsletter, the entire team at APISecurity.io extends our warmest wishes for a successful and fulfilling new year in 2025, both personally and professionally. To those of you taking some well-deserved time off this holiday season, we hope you enjoy a peaceful and restful break, free from API security incidents! Happy New Year!

Article: Why API Security is a top priority for 2025

A recent article on TechTarget explores potential trends shaping the API ecosystem in 2025. Will we see a transformative shift in API development powered by AI-driven services and integrations? Will the adoption of GraphQL and AsyncAPI continue to accelerate? And how might emerging specifications for REST APIs influence development?

These evolving trends and technologies will drive the conversations around API security in the coming year. As the article notes, teams still relying on traditional centralized security approaches will find themselves struggling to manage the increasing complexity of API-based integrations and supply chains. 

Moreover, with the surge in API breaches reported across critical industries—ranging from finance and telecommunications to healthcare and automotive—the call for secure-by-design  initiatives is likely to grow louder. This shift will place the responsibility for addressing security vulnerabilities squarely on API producers, alleviating the burden on users and customers.

Article: API Security skills paramount for FinTech in 2025

In an interview earlier this month, Mastercard’s Olivia Leonard shared her insights on the anticipated technical skills that will be in demand for the financial sector in the coming year.  

As in many other industries, the opportunities and challenges created by AI will be top of mind for organizations in 2025. Leonard highlighted the importance of building a workforce that is “comfortable using AI-powered tools” to stay competitive in the evolving digital landscape. At the same time she also noted that cybersecurity expertise will be paramount due to the rapid expansion of digital payments and services. 

Open banking is another trend driving the rapid expansion of digital financial services and is expected to increase the demand for skills in API security. In the UK, organizations such as NatWest have already seen the benefits of open banking this year, which will help drive the deployment of more API-based services. Meanwhile in the US, new consumer financial protection rules introduced this year create a requirement for open banking and the sharing of financial data through secure and reliable API services.

All of this comes at a time when APIs are already a prime target for threat actors, which should place a premium on API security skills and expertise. 

For technical professionals looking to stay ahead in the financial sector, a worthwhile New Year’s resolution might be to enhance their understanding of API security best practices. 

Article: 2025 breach predictions in AI, API, and OpenSource 

Nanhi Singh, General manager of application security at Imperva, shares her predictions for the major security headlines we can expect in 2025. 

A rapidly evolving AI industry brings with it a host of new risks, including prompt injection attacks. It also lowers the barrier to entry for novice hackers, enabling them to execute sophisticated attacks using immensely powerful AI tools.

The article also calls out how a growing reliance on insecure open-source software is likely to trigger a significant incident next year. As software supply chains become increasingly complex, developers are placing greater trust in third-party components, which can be the source of malicious data and attacks.

While APIs are predicted to be a primary attack vector for applications leveraging large language models (LLMs) and will likely continue to attract the attention of hackers, there is a silver lining in the prediction. The heightened risk may drive more teams to adopt a DevSecOps approach, embedding API security practices directly into the development process to address vulnerabilities at their source.

An interesting article, though a little foreboding in its predictions.

Article: Avoid OWASP insecure design vulnerabilities

Many API security incidents and vulnerabilities are caused by a relatively small set of root causes. We can often track those causes back to mistakes in API design or implementation.   

For example, a common mistake in API design is to assume security checks are performed on the client side, and so failing to enforce those security checks at the API level. We see this regularly in incident reports for mobile apps and single-page applications. It allows hackers to easily circumvent client-side security checks and attack an unprotected API directly. This leads to all manner of vulnerabilities and exploits, including authentication by-pass, escalated privilege and account takeover attacks.  

This technical article on the Hackerone website delves into more insecure design vulnerabilities. It’s a very useful educational piece to understand the underlying causes of security breaches, and how adherence to API best practices and principles can help to prevent them. 

Vulnerability: Private files exposed on Mitel platform 

A vulnerability was discovered in a URL path for Mitel’s communications platform MiCollab, that allowed arbitrary files to be read from unauthorized parts of the platform.

The path in question (/npm-pwg) was vulnerable to a path traversal attack, which allows an attacker to access other unauthorized paths or directories in the system (e.g. /npm-admin).

GET /npm-pwg/..;/npm-admin/ HTTP/1.1

The researchers who discovered and reported the vulnerability provide an in-depth technical analysis. In it, they describe how using a special sequence of characters in the URL path ..;/ can be used to trick a vulnerable server into traversing out of the proper context and inadvertently giving access to private resources.

Path traversal attacks are similar to other common attacks like SQL injection, whose success depends on APIs that fail to adequately validate user supplied input. 

In this case, the vulnerable input was the request path, which should always be carefully validated to ensure an exact match for any exposed endpoint.

Vulnerability: Path Traversal vulnerability in Sailpoint IdentityIQ 

In another example of a path traversal vulnerability, a recent report on The Register website describes a bug discovered in Sailpoint’s identity and access management platform IdentityIQ. 

The vulnerability received a severity rating of critical 10/10 from the National Vulnerability Database where it’s described as allowing “HTTP/HTTPS access to static content in the IdentityIQ application directory that should be protected.”The article describes how path traversal vulnerabilities have previously been described as “unforgivable” and “embarrassingly easy to exploit”.

These incidents serve as a reminder to incorporate recommended security practices into API design to avoid being embarrassed by similar exploits of path traversal vulnerabilities. It’s also one to watch out for during API security testing.

The post Issue 261: API Security in 2025, OWASP insecure design, path traversal flaws for Mitel and Sailpoint appeared first on API Security News.

Article: How secure is your API SDLC?

API teams can produce secure and reliable APIs through rigorous design, coding and testing. However, this recent article highlights how every phase of API development is now at risk, forcing API teams to take a broader view of API security beyond just the code they produce.

Some common sources of SDLC vulnerabilities mentioned include:

• granting excessive access rights to outsourced development teams
• poorly configured CI/CD pipelines
• OAuth phishing
• mismanaged development teams with lax security practices

This means that API security requires a broader perspective and must encompass not only core secure development practices, but also rigorous cybersecurity awareness across the API team and organization. 

Vulnerability: Malicious API injected in Solana Javascript SDK

The Solana JavaScript SDK, a widely used package on NPM with over 350,000 weekly downloads, enables developers to interact with the Solana blockchain via API requests.

A hacker reportedly injected malicious code into the SDK, turning it into a tool for stealing private keys in a classic supply-chain attack. The compromised code allowed the hacker to extract private keys from any application built using the infected SDK and send them to an API endpoint under the hacker’s control. Possession of a user’s private keys allows a hacker to drain their digital wallets. 

The report suggests that the attacker may have compromised the SDK’s developers through social engineering or phishing tactics, to gain unauthorized access to the package. If true, it demonstrates why API security training should extend from secure coding practices to include general practices for good cyber hygiene. 

Vulnerability: Laravel security flaws expose API developers 

Staying on the topic of SDLC vulnerabilities, a recently discovered critical vulnerability could compromise the security of APIs developed with the Laravel framework. 

Laravel is a popular web application framework and is also used for API backend development. 

The bug manifested itself at the request handling stage and allowed an attacker to gain unauthorized access by using malicious user input passed in a request as URL query strings. 

This is a reminder that the frameworks that API developers choose to use in their projects can inadvertently introduce security vulnerabilities into APIs and applications. It highlights the importance of carefully choosing and configuring frameworks and libraries, many of which are not secure by default, and the need for extensive API security testing to identify issues early on.

Teams are also advised to monitor advisory updates for all dependencies used in API development for prompt notification of new security issues and critical updates.

Vulnerability: Python AI packages disguise malicious API 

From PHP to Python, another gotcha for API developers to watch out for is the use of malicious third-party packages. 

A report on the Dark Reading website describes how developers, keen to jump on the AI bandwagon, can be duped into installing malicious packages with hidden malware. 

In this incident developers were offered a quick and free way to add AI functionality into their projects by installing a Python package. The package claimed to provide API access to GenAI platforms, but behind the scenes the package also injects the developer’s project with malware. Notably, the package appeared to function as expected, making it easier for developers to miss the danger during testing. 

“They committed the extra effort to make it look legitimate”

Leveraging open-source software can significantly reduce development time and effort, but it also comes with inherent risks when the security of the code is essentially unknown. To mitigate these risks, development teams should adopt a zero-trust approach to open-source dependencies. This involves thoroughly reviewing, auditing, and testing any package before integration to ensure it meets security standards. 

Article: Node APIs done right

Moving from vulnerabilities to best practices, the “9 Principles for Doing Node.js Right in Enterprise Environments” guide shares essential tips and recommendations for building secure and reliable APIs using the popular Node.js framework. 

It includes recommendations by industry experts to  focus on defensive testing, including negative testing and security testing. It also devotes a section to error handling, a common source of API vulnerabilities and a major topic of our previous issue of this newsletter.

The guide also describes the benefits of using API specifications in a multi-team environment. 

“By defining your API’s structure, data types, and operations, you can ensure that different teams can work independently while maintaining compatibility and avoiding misunderstandings”.

Similarly, API specifications help to clearly define and share the security requirements of an API, a practice we have been advocating for a long time in this newsletter.  

This guide contains a lot of very useful information. Recommended reading!

Vulnerability: How a bug bounty hunt reveals API IDOR flaws

The methods used by penetration testers and hackers can provide valuable insights to an API team on how to eliminate the risk from common API attacks.

This report from a bug bounty hunter shows how an attacker can probe and test your API for an exploitable vulnerability. In this case, the bounty hunter focused on manipulating the API user input to attempt to invoke unexpected behavior or response from the target API, a common tactic used by hackers. 

By changing a user_id parameter in the API request, the bounty hunter discovered that the API would return a resource that did not belong to the authenticated user. This revealed that the API has a well known authorization vulnerability called Insecure Direct Object Reference (IDOR). 

The relative simplicity of the test to uncover this severe API authorization flaw demonstrates why IDOR, also known as Broken Object Level Authorization (BOLA), is the top risk in the 2023 OWASP API Security Top 10 list. 

Steps to prevent successful BOLA attacks against your APIs are shared here. 

The post Issue 260: Attacking the API SDLC, lessons from an API bounty hunter, Node APIs done right and news of recent vulnerabilities appeared first on API Security News.

Vulnerability: 4,000,000 WordPress sites vulnerable to improper API error handling

A research team at Wordfence recently discovered a vulnerability in the REST API of a WordPress plugin called the Simple Security plugin. This vulnerability allows a hacker to log into the site as any other registered user without providing a valid security token, effectively bypassing API authentication. 

WordPress is a hugely popular web content management system. It’s estimated that this API vulnerability impacted over 4 million WordPress sites.  

When an API detects an error condition, such as a missing token in a request, the API should always catch the error and respond in a controlled manner, typically returning an appropriate status code and a message describing the cause of the error: 

HTTP 401 { “message”: “invalid credentials”}

However, if a hacker can cause an error that is not expected or handled by the API, this flaw in error handling can cause the API to behave in unexpected ways, such as bypassing authentication. This appears to be the root cause of this incident.

Interestingly, the report indicates that this vulnerability was created in the plugin code while it was being upgraded with new security features. It is possible that the development team was so focused on delivering a working security feature that they neglected to consider error handling during API design and testing, when the vulnerability could have been prevented, or at least discovered before it went live and impacted 4,000,000 sites.

This incident highlights why API error handling is an important component of API security and should be standardized as a security requirement in API design. For reference OWASP provides helpful information and code examples for recommended error-handling practices. 

Article: The benefits of governance rules on API Error messages

Still on the topic of API error handling, this article from NordicAPIs shares examples of well-crafted API response messages from Stripe, Instagram, and Salesforce. 

These are great examples of how APIs should be designed from the perspective of the API consumer. Clear, consistent, and self-describing error messages make the API easier to understand and use, which in turn makes it easier to integrate the API and provides a better developer experience for the API consumer. 

Also, by carefully designing the shape of an API error response up front, the API team defines rules and constraints on the type, format, content and size of data that the API should return. Incidentally, OpenAPI can be used to precisely describe the structure of response messages.

This has obvious security benefits. Bugs in API error-handling code can easily lead to unauthorized data leakage, especially when error-handling code receives less attention during API development and testing. 

We’ve covered real-world examples of this in previous issues of this newsletter, such as incidents at Life360 and Cox Communications where private data was inadvertently leaked in error response messages. 

It’s no surprise then that hackers would attempt to intentionally invoke errors in an API as part of early reconnaissance, since error handling is considered a point of vulnerability. 

On the other hand, well-designed and consistent error response messages can help create APIs that are easier to use and also resilient to attacks. 

Article: Leaking Open Source Intelligence with API Error Codes 

When my youngest son comes to me asking for chocolate biscuits before dinner, I can respond in one of two ways: “Those biscuits are forbidden before dinner” HTTP 403, or “There are no biscuits to be found” HTTP 404. 

If I respond with 403 instead of 404, the result is essentially the same (he doesn’t get the biscuit), but I’ve inadvertently given him a crucial piece of information he didn’t need to know…there are chocolate biscuits in the house. This information leak will undoubtedly trigger a flood of persistent followup requests. I should have responded with 404 Not Found! 

This is essentially the point of a recent Cyber Security News article on API error codes. 

When an API returns an error response to deny a request, the choice of status code returned by the API can reveal useful open source intelligence (OSINT) to a hacker. 

For example, HTTP error codes 403 and 404 both indicate that access is denied, but they can also confirm the presence or absence of a requested resource. This is called a discrepancy factor. A hacker can use a discrepancy factor of a vulnerable login API, for example for a mobile app or SaaS platform, to check whether an account exists or not for a given email address. 

And if the vulnerable API has no usage limits, a hacker can easily launch an account enumeration attack and identify millions of registered users on your application or platform. 

My opinion is that 403 is an appropriate response if a user requests access to a resource that they do not have access to, but could potentially be granted access to. Otherwise, if a user should never have access to the resource, the API should behave as if that resource doesn’t exist for that user and always return 404. 

You can read more tips on handling error codes in this OWASP article. 

Article: Making a case for API-First

In an article on The New Stack, Frank Kilcommins makes a strong case for adopting API-First principles to promote better API interoperability, consistency, and reuse, especially as the number of APIs skyrockets to meet the voracious demands for input from AI-driven systems.

The article outlines the core principles of API-First and describes the typical drivers and benefits of this approach to API development, both from a technical and business perspective. 

When it comes to building an “AI-ready” API, the API must be easy to understand and consume automatically. This requires designing the API with the needs of the AI consumer in mind, which is one of the defining principles of the API-First approach. Additionally, using formal specifications like OpenAPI can help create a design process for producing high-quality, AI-ready APIs:

“Specifications allow you to enforce consistency, define data structures, and provide clear constraints, all of which help machine consumers interact confidently with your APIs”

Back to this week’s main theme, the benefits of an API-First approach also help to solve the challenges of implementing secure API error handling. 

A carefully considered design of the API error response, with consistent structure and format for messages and a shortlist of expected status codes, will make it easier for an AI agent to predictably consume the API and gracefully handle error conditions. 

This is a very informative article on API-First that I highly recommend. 

Vulnerability: Account TakeOver of Cloud-connected IOT devices 

The Claroty research team discovered critical API vulnerabilities in the OvrC platform, a cloud-based platform for remote management of smart devices in homes and businesses.  

One vulnerability allowed a user to retrieve the status of any device registered to the Ovrc cloud, regardless of ownership. A user simply sends a valid device MAC address to the API, which can easily be guessed, and the API effectively confirms the existence of the device by returning a JSON response with the latest device status. 

By iterating over the vulnerable API with different MAC addresses, the research team was able to enumerate all devices connected to the cloud platform. The team estimates that over 10 million devices worldwide were affected by the vulnerability. 

Additional API vulnerabilities were discovered that allowed the team to take ownership of any device. The API responsible for registering ownership failed to enforce and authenticate a required device ID property in the request, allowing a user to bypass authentication and claim ownership and control over any device. Vulnerable devices included surveillance cameras used in homes and business premises.

According to an industry report from Imperva, 44% of account takeover attacks recorded last year targeted authentication APIs to exploit vulnerabilities such as authentication bypass. API teams must be vigilant in designing and testing authentication APIs with security firmly in mind.

The post Issue 259: API flaw exposes 4 million WordPress sites, API error handling bugs, a case for API First appeared first on API Security News.

Article: Vodafone’s journey to API Governance

First, Dimitris Maimaris shares Vodafone’s experience in adopting an API-first approach to API development and creating an effective program for API governance. 

Vodafone’s API team consists of 100 developers and QA engineers, supported by 16 solution architects, managing a growing ecosystem of over 250 APIs. As the number of APIs grew, the team sought to adopt standardized policies and practices to govern how APIs are developed, deployed and used. 

Standardizing practices across the API lifecycle creates consistency in how team members operate, as well as consistency in how API security policies are reliably enforced across all APIs. Vodafone reports benefits in terms of improved API integration, reduced redundancy and enhanced reusability, as well as reduced dependency between front-end and back-end teams to accelerate API development and service delivery.

Recommended reading for API teams. 

Article: Create API prototypes using OpenAPI

OpenAPI provides a formal, widely accepted format for describing an API. You can use it to define the paths and operations that an API supports, the headers and parameters that it requires or accepts, and the schemas of the data that are passed in request and response messages. You can also use OpenAPI to define the authentication or authorization information that an API requires.

So, an OpenAPI description can provide a complete and detailed design of the expected behavior of an API. However, sometimes it is necessary to test something to get a real idea of ​​how it works. So how do we quickly and easily convert an API design from a static OpenAPI document into something functional that we can test?

In his recent article, Bruno Pedro explains how he achieved this by building his own API prototyping solution from a selection of useful VSCode extensions. With this tool, he is able to simulate an API server and generate a useful API client, both by leveraging the OpenAPI description of the API.

According to the OpenAPI initiative, an API description file should “strive to be as complete and fully-detailed as possible…the more unambiguous it is, the more useful it becomes”. 

This is certainly true when it comes to automatically generating mock API clients and responses, as a detailed and complete API description will help create a more realistic API simulation. Therefore, auditing an OpenAPI file for correctness and completeness is an important step in creating useful API prototypes.

Great article by Bruno Pedro, a must read.

Industry News: OpenAPI releases 3.0.4 and 3.1.1

New updates to the OpenAPI specification have been released for versions 3.0 and 3.1.

According to the release notes, there are no changes to the requirements in the 3.0.4 or 3.1.1 patch releases. Instead, the updates focus on improving the text of the specification, with clarifications and additional examples provided for a number of sections.

Information has been added to better explain data types and query parameters. There is now a separate section describing headers. Additionally, more examples have been added in 3.0.4 and 3.1.1, which really help illustrate and clarify some of the text.

If your team is currently using older versions of 3.0 or 3.1, you should consider updating your documentation links to point to these newer versions.

Also check out this video of Erik Wilde interviewing OAI Technical Steering Committee member Lorna Mitchell about these latest patch releases, as well as a status update on versions 3.2 and 4.0 (aka “moonwalk”).

Breach: Fortinet devices exposed by broken API authentication

FortiGate network firewalls can be exploited via a vulnerable API in FortiManager, a network management platform used to centrally control multiple firewall deployments.

According to a report, the API implements the FortiGate to FortiManager (FGFM) protocol. A security bug in the API allows commands to be sent to networked devices without any authorization. This allows attackers to remotely take control of the FortiManager device and connected FortiGate firewall devices within vulnerable enterprise networks.

Network devices now commonly offer APIs to facilitate integration with other devices and services, as well as provisioning or configuring device settings. We have previously reported API vulnerabilities found in Cisco and Trend Micro network devices that also allow an attacker to access and compromise other connected devices. 

This is a reminder that APIs are frequently deployed with critical security vulnerabilities, whether these APIs are used in web applications, mobile applications, or critical network devices, and must be thoroughly tested to uncover such vulnerabilities.

Vulnerability: Multiple OWASP Vulnerabilities found in Cyberpanel 

Cyberpanel is a free, open-source web hosting control panel. A researcher has discovered two API vulnerabilities that together expose the platform to command injection attacks.

In the case of the first vulnerability, the API was developed to enforce authentication separately on each individual API route, and in some cases, developers forgot to enforce the necessary authentication. For the second vulnerability, the API was developed to explicitly handle HTTP POST requests, but also accepted and handled other HTTP verbs such as PUT and PATCH by default, causing unexpected execution paths in the API code.

For security reasons, it is strongly recommended to apply authorization on an API level rather than at the individual route or operation level. This ensures that authorization is applied as the default behavior for all new routes or paths added to an API. On the other hand, applying authorization on each individual route is an error-prone approach, as it is easy for developers to forget to include essential security checks when adding a new route or operation to an API. This appears to have happened repeatedly with the Cyberpanel API. Adopting best practices could help reduce the risk of the same security bug recurring.

For the second issue, the OWASP Top 10 API security guidelines recommend explicitly disabling unnecessary features, including HTTP verbs, to avoid security misconfiguration vulnerabilities in APIs. This means that an API should only accept and process HTTP verbs that are expected for an operation. For any other verbs received, the API should respond with an HTTP 405 “Method Not Allowed” response. 

The detailed research to uncover vulnerabilities in this case provides an opportunity to address root causes, implement best practices, and prevent future security incidents.

The post Issue 258: API governance at Vodafone, OpenAPI updates, APIs with OWASP vulnerabilities appeared first on API Security News.

Vulnerability: Key Lessons at the Internet Archive

Since early October, the Internet Archive, home of the popular Wayback Machine web archive, has suffered a number of high-profile attacks by groups credibly claiming to have breached Internet Archive’s systems and platforms.  

According to one report, the attacker initially gained unauthorized access after discovering an exposed Gitlab authentication token on an Internet Archive development server. The token was reportedly exposed for over two years, yet it still allowed the hacker to access Internet Archive’s source code on Gitlab. From this source code, additional tokens were discovered, including an API token for the company’s Zendesk support system. 

The Zendesk API token allowed the hacker to access over 800,000 support tickets. Many of the tickets were submitted privately by users and included identifying information. It’s worth noting that two weeks after the issue was reported to Internet Archive, the Zendesk API token could still be used to access their admin account. 

Both the original Gitlab token and the Zendesk API token appear to be long-lived tokens or to have no expiration date. A thread on Zendesk support also indicates that Zendesk API tokens (really API keys) do not limit the scope of access by role or resource. 

This type of token management isn’t the root cause of the breach, but it can certainly increase the likelihood of persistent attacks and compound the damage by granting all-or-nothing access to systems and resources. 

API keys are particularly prone to this type of abuse when used for purposes other than identifying an API client. You can read more about best practices for API token management in this (still very relevant) 2018 article.

Industry Report: Is your API Gateway Secure by Default

Secure by default is a product development approach that shifts the burden of security from the user to the product manufacturer. According to the U.S. Cybersecurity and Infrastructure Security Agency (CISA):

“Secure-by-Default” means products are resilient against prevalent exploitation techniques out of the box without additional charge. These products protect against the most prevalent threats and vulnerabilities without end-users having to take additional steps to secure them.

In contrast, a recent report from Trend Micro examines the default settings of two popular API gateway solutions, APISIX and Kong, and identifies a number of critical vulnerabilities that could be exploited to compromise the API gateway platform, including:

• Use of default admin passwords
• Passwords stored on the platform in clear text 
• Security tokens exposed in log files
• Platform administration access exposed on all network interfaces

In addition to the insecure defaults, some API gateways support community plugins to extend the functionality of the platform. Installing a community plugin can introduce new vulnerabilities into the API gateway and compromise the protections it’s designed to provide for your APIs. 

For example, API gateways typically implement authorization protocols such as OAuth and OpenID Connect. API teams can offload the burden of implementing these protocols to an API gateway, allowing the team to simply configure authorization flows for their APIs instead of coding from scratch. 

However, if the API gateway itself is vulnerable to an attack due to insecure default settings or from installing a vulnerable plugin, the authorization controls protecting your APIs may be affected. 

The report examines these and other security issues with the APISIX and Kong gateways in particular, though it can serve as a useful guide for reviewing your own API gateway deployments, which may suffer from similar vulnerabilities. 

Industry News: An RFC for GNAP

Speaking of OAuth, have you heard of GNAP? 

GNAP (the Grant Negotiation and Authorization Protocol) was recently published by the IEFT as RFC9635. According to one of its authors, Justin Richer, GNAP is the result of an investigation into the shortcomings of the popular OAuth protocol for delegated authorization, and is already used in scenarios such as online payments and key management. 

Reading some of the documentation, it looks really promising. Appendix A provides the TL;DR you’re looking for to understand the use cases where GNAP can be better suited than OAuth.

The section on ‘consent and authorization flexibility’ caught my attention.

“OAuth 2.0 generally assumes the user has access to a web browser. The type of interaction available is fixed by the grant type, and the most common interactive grant types start in the browser… GNAP allows a client instance to list different ways that it can start and finish an interaction, and these can be mixed together as needed for different use cases. GNAP interactions can use a browser, but they don’t have to”

I recently worked on building a set of APIs for a demo application, and wanted to add an OAuth delegated authorization flow. Figuring out which grant type to use quickly became a challenge. In the end, nothing really fitted neatly (among other things I wanted to avoid using a browser). 

The kind of flexibility that GNAP claims to offer could be a great benefit to API developers, and simplify the building of bespoke authorization solutions.

Vulnerability: Injection attacks on Palo Alto Expedition platform

Palo Alto Networks Expedition is a tool that allows users to migrate firewall configurations from other vendors, such as Checkpoint or Cisco, to a Palo Alto Networks PAN-OS firewall. 

Two critical vulnerabilities were recently discovered in the platform API that allow both command injection and SQL injection attacks. 

A detailed report from Horizon3.ai includes an account of their research as well as a proof of concept demonstrating how to manipulate API input parameters to gain unauthorized database access or execute malicious commands on the Expedition system.

Injection attacks are a common way for threat actors to find and exploit API vulnerabilities, by sending malformed data in parameters or headers that are not properly validated by the API. 

SQL injection, command injection, and path traversal are all examples of injection attacks.   

Palo Alto Expedition users are advised to update to v1.2.96 or later. Also, all firewall usernames, passwords, and API keys processed by Expedition should be rotated after updating.

Vulnerability: API Incident on Trend Micro’s Cloud Edge

Cloud Edge is a unified threat management solution from Trend Micro. According to a report from Cyber Security News, a vulnerability was discovered in a Cloud Edge REST API that exposed the appliance to command injection attacks. A successful attack allows a hacker to execute malicious code on the appliance in the context of root. 

Similar to the Palo Alto vulnerability mentioned earlier, the vulnerable Cloud Edge REST API accepts user-supplied input without proper validation and uses the input to execute a system call. The lack of input validation creates a vulnerability through which the attacker can control the commands executed on the appliance.

Cybersecurity agencies such as CISA and the FBI in the United States are urging software development teams to adopt secure-by-design principles to prevent common vulnerabilities such as command injection during the design and development phases. 

Trend Micro strongly encourages users to update to the latest version of the product.

Vulnerability: How to identify SSRF vulnerabilities

I recently noticed two incidents of server-side request forgery (SSRF) that are worth looking at to illustrate how the vulnerability can occur in your API code and how to avoid it.

An API can be vulnerable to SSRF if it retrieves resources from a remote location based on a user-provided location (e.g., a URL, hostname, or subdomain). The API should carefully inspect and validate user input to ensure that it does not point to an unexpected location.

PostHog

PostHog is an open source product analytics platform used by product development teams. A security advisory reported a Server Side Request Forgery vulnerability discovered in the PostHog platform API, which was quickly patched by the team. 

The root cause and subsequent fix can be seen from the associated code changes. The ‘subdomain’ property is set by user-supplied data in an API request. A malicious user could set an invalid subdomain value and cause the API to access resources in an unexpected location. 

The fix, as demonstrated by the code change, was to set constraints on the input value, thereby blocking invalid or malicious input with a HTTP 400 response.

Plane

Plane is an open source project management tool for running development cycles and managing product roadmaps. An SSRF vulnerability was recently reported on an image retrieval service on the platform. A POC demonstrates how an overly permissive wildcard pattern (“**”) on a ‘hostname’ input property was the root cause of the vulnerability. This allowed a user to set any value for the hostname. 

This SSRF vulnerability was fixed by removing the permissive pattern and preventing resource retrieval from arbitrary remote sources. 

Watch out for similar SSRF issues in your own APIs.

Webinar: Mitigate OWASP API Risks through Security by Design

The OWASP Top 10 API Security Risk list provides a clear roadmap of the most common and dangerous vulnerabilities that can compromise your APIs. I’ll be demonstrating in this webinar how to incorporate the OWASP guidelines into your security initiative to help build secure, resilient APIs by design.

Register

The post Issue 257: Internet Archive under attack, API Gateways insecure by default, OWASP injection attacks appeared first on API Security News.

Also this week we celebrate APISecurity.io’s 6th anniversary! Since publishing Issue #1 on October 11, 2018, the newsletter has become a trusted resource for staying up-to-date on the latest threats, best practices, innovations, and solutions in the API security space. Thank you to all subscribers for your continued feedback and support as we work to provide timely and valuable content to drive the conversation around API security. 

Industry News: NIST updates the rules for password security

In the latest revision of Special Publication 800-63 Digital Identity Guidelines, the U.S. National Institute of Standards and Technology (NIST) updated the rules for password security, including changing the guidelines for password complexity and composition from recommendations (should, should not) to requirements (shall, shall not).

Forcing users to create complex passwords that include letters, numbers, and special characters can be counterproductive when it doesn’t result in strong and unpredictable passwords (the infamous “Password1!”). This was acknowledged in the original NIST publication in 2017, but the latest update now establishes clear requirements that password verifiers must not impose these composition rules on users.

You can read the rationale behind the changes to password strength in the Appendix. One point from the summary I think is worth noting for development teams: 

“Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.”

So while the burden of complexity is being lifted off the end user (a good thing), these changes put an additional responsibility on development teams to ensure robust protections against brute force attacks on the functions and APIs that perform password verification.

Vulnerability: Kia vehicle’s insecure partner API hacked 

A report by researcher Sam Curry describes how a team of ethical hackers discovered vulnerabilities in Kia’s APIs that allowed them to take over user accounts and remotely control vehicles. In issue 253 we referenced an industry white paper from VicOne on this very topic.

The main weakness was a dealer registration endpoint without any identification or verification checks, so any online user could register as a Kia dealer. A dealer has an elevated role, or partnership, with the vehicle manufacturer, and so is granted privileged access to systems and API services. 

So once registered as a fake Kia dealer, the research team was able to use Kia’s dealer APIs to query vehicle owner’s personal information, add an attacker as the primary owner of the vehicle, and ultimately execute remote commands to control the vehicle. A video demonstration is included in the report.

Partner APIs typically provide privileged access to services and data and so need additional layers of security, and testing, around the registration process. Imagine how much harder it would be to hack this system if dealer registration was limited to a whitelist of approved email domains?

Or better yet, use mutual TLS so that dealer registration is only possible from a particular office or terminal. Don’t make it easy for hackers. If they want unauthorized access to partner APIs, force them to break glass and climb through some windows!

The report also highlights that obfuscation offers little protection. Just because your APIs and endpoints are hidden and undocumented doesn’t mean hackers won’t find them. The process by which this team discovered the dealer registration endpoint is a valuable lesson for API teams to heed.

Great writeup by Sam Curry. Essential reading for API teams.

Vulnerability: Broken Authorization in Cisco Nexus Platform APIs

Continuing on the topic of privileged access and vulnerable APIs, a Cisco security advisory highlights several REST API vulnerabilities that allow a low-privileged user to access administrator-level services on the Cisco Nexus Dashboard.

Cisco Nexus Dashboard is a centralized management platform for provisioning, managing, and operating data center networks. According to the advisory, the vulnerabilities involve missing or insufficient authorization checks on the REST API, which could allow an attacker to upload malicious files and read or delete sensitive data.

Incidents of attackers gaining privileged access to API services are often exploits of broken function level authorization (BFLA). According to OWASP, BFLA vulnerabilities are common and easy to exploit and can lead to data disclosure and service disruption.

The guidelines to prevent BFLA suggest adopting a zero-trust approach where access is denied by default, and requiring specific roles or permissions before access is granted. BFLA specific tests can also be run as part of automated continuous testing, to check if non-authorized users can gain access to privileged APIs.

Vulnerability: Privilege escalation flaw in e-filing platform API

A recent article in SecurityWeek describes how cybersecurity researcher Jason Parker claims to have discovered critical vulnerabilities in a number of public platforms used in the United States’ justice systems.  

In one report, the researcher describes an API vulnerability discovered in the Granicus e-filing platform that allows a regular user to elevate their access levels. The e-filing system is used to submit legal documents to state courts. 

According to the researcher’s disclosure document, the vulnerability is exploited by sending an API request to the platform with a special “TypeCode” property in the payload. If the TypeCode matched a value for a privileged account on the system, like a court or administrator account, the user’s access level was escalated.

This has the typical characteristics of an API mass assignment vulnerability, or a Broken Object Property Level Authorization (BOPLA) vulnerability in the OWASP API Security Top 10 list. 

BOPLA exploits can cause a range of different adverse effects, from crashing a server to escalating a user’s role and access permissions. 

An API should be securely designed to constrain the properties it accepts to only those that are expected. Additional properties should be rejected by default, to avoid unexpected behavior in the API. 

Industry Report: 30% of public APIs are completely unprotected

F5 recently published a supplemental report titled “The Secret Life of APIs” summarizing the views of API decision makers, primarily C-level, on their current API security posture.

From what I’ve read, the results range from suspiciously optimistic to shockingly pessimistic. 

On the optimistic side:

• 80% of organizations claim to begin API security in the API design phase
• 59% say they incorporate security at every stage of the API lifecycle

Security-by-design is the recommended approach to API security. However the devil is in the details, and some of the other statistics that emerge from the report suggest that teams are struggling to get some of the basics right:

• More than 30% of public APIs use the unsecure HTTP protocol
• Two-thirds of organizations leave their operational workflow APIs unsecured

The report also highlights how AI solutions are enabled by API-based integrations, so AI solutions will continue to be vulnerable until APIs are secured. 

The take-away message from the report is that organizations must adopt a zero trust model for API security, to be implemented throughout the API lifecycle from development to operational phases. This is a recurring conclusion in industry reports for achieving effective API security.

Webinar: Mitigate OWASP API risks through security-by-design

The OWASP Top 10 API Security Risk list provides a clear roadmap of the most common and dangerous vulnerabilities that can compromise your APIs. In this webinar, you will learn how to incorporate the OWASP guidelines into your security initiatives for software development to help build secure, resilient APIs by design. This session will offer practical insights to enhance the security of your applications.

Key takeaways include?

• Why adopt security by design?
• How to leverage OWASP guidelines for API development
• How to get developers invested in the security of their APIs

The post Issue 256: Privilege escalation bugs in Kia vehicles, Cisco and Gov APIs, NIST’s new rules for password security appeared first on API Security News.

Vulnerability: Networks exposed to Versa Director API flaw

According to a report by The Cyber Express, a vulnerability was recently discovered in Versa Director, a platform used by service providers to manage network configurations. The vulnerability is caused by improper input validation in a REST API exposed by the platform.

APIs must be developed with secure coding practices to properly validate all user input. Without this basic security check, an attacker can carefully craft input that is not expected by the API and can lead to unintended consequences.

In this case, an attacker could inject an invalid property into a GET request to the vulnerable API, which would cause an unintentional leak of authentication tokens of other users logged into the system. Armed with the valid tokens of other users, the attacker could then send additional API requests with the permissions and privileges of those other users.

A recommended workaround is to use a WAF or API gateway to block all traffic to vulnerable API endpoints. However, a more granular API firewall would only block API requests that include invalid properties, to protect the system from malicious requests without impacting all users.

Vulnerability: BOLA undermines privacy in Feeld dating app

The Fortbridge research team has discovered a series of API vulnerabilities in the dating app Feeld, demonstrating the real-world consequences of broken object-level authorization (BOLA). 

BOLA tops the OWASP Top 10 ranking for API security. It is an extremely common vulnerability in API development and it is also easy to exploit.

These BOLA vulnerabilities allow a malicious user to access other users’ private photos and chat groups. In one example, the team demonstrated how they were even able to modify other users’ chat messages. 

To find these vulnerabilities, the research team was able to monitor the API traffic sent by the mobile dating app. They noticed that the app sends unique IDs to the API server whenever they accessed a resource such as a photo or chat message.

By manipulating the ID sent to the API server, the team was able to gain unauthorized access to other user’s photos and chat messages. This showed that the API was not checking whether a logged-in user was authorized to access a particular resource. In other words, the API’s authorization is broken at the resource or object level. 

Mobile apps are particularly vulnerable to BOLA attacks if frontend and backend development teams are not clued in to the risks. For hackers who know how to look inside a mobile app to monitor and manipulate API traffic, BOLA is often a very effective method of attack.

Article: How hackers access the APIs behind your mobile app

I recently read an interesting article by Dana Epp on how to hack mobile apps and APIs. It’s basically a step by step technical guide on how to connect the Burp Suite tool with an Android device in order to access and manipulate a mobile app’s API traffic. It also explains how to circumvent the latest Android security features as part of the setup. 

The guide is technically detailed and well illustrated, making it easy to follow and set up your own mobile hacking environment. So it’s a great share for the benefit of other API enthusiasts. 

One thing that stood out to me while reading this guide is that even though security is continually improving in mobile devices, software and hardware, hackers (ethical or otherwise) will always find a way to gain access. 

What does this mean for mobile app development and security teams? 

Teams must assume the app’s API traffic will be exposed and manipulated by hackers to probe and test for vulnerabilities. For that reason, API developers should follow secure API coding practices to remove or mitigate common risks, and consistently authorize all user requests to return only data that the user is specifically authorized to access. 

Also, API testers will need to be just as creative and diligent as hackers to find ways to uncover API vulnerabilities, before mobile apps go into production and become prime targets.

Article: API Discovery – How to Achieve a complete API Inventory

In a recent article, Axel Grosse of 42Crunch discusses the challenges enterprise security teams face in establishing a comprehensive inventory of their API estate. API discovery is often misinterpreted as being API security and not just a facet of a bigger picture as this article explains. 

In the rush to find quick fixes, teams often overlook the fact that existing API knowledge and records are already available within the organization. It’s just a matter of knowing where to look and who to contact for directions.

Luckily, Axel has you covered! The article provides guidance for security teams on how and where exactly to begin API discovery. And, most importantly for API security, it asks the question, “now what?”

If you’re starting on the API discovery journey, or if you’re struggling with the “now what?” question, this article will give you some food for thought. 

Report: API vulnerabilities costing companies up to $87 billion

An industry analysis of over 161,000 cybersecurity incidents reveals some interesting statistics about the risks and potential costs associated with API vulnerabilities. 

The report published by Imperva estimates the average annual cost of API-related incidents worldwide is between $35 billion and $87 billion. 

These losses associated with API incidents somewhat offset the benefits of API adoption, such as reduced operational costs and increased revenue. And as organizations expand their adoption of APIs, the cost and risks of API incidents also increase.

“On average, organizations have 613 API endpoints, providing many potential entry points for attackers.”

Some of the top API vulnerabilities identified in the report include BOLA, broken authentication, undocumented APIs, and automated bot attacks.

Organizations are advised to invest in comprehensive API security strategies to address these API vulnerabilities and their associated costs. 

Article: How small mistakes create big API risks

In this article, Katie Paxton-Fear describes three different API security incidents she has encountered in her role as an ethical hacker.

One of the incidents involves broken authentication that could have led to a plane crash. Katie describes how her role often involves learning about the logic of an API and the functionality it’s supposed to provide in order to uncover vulnerabilities. Understanding how a relatively simple development mistake can lead to potentially serious real-world consequences is part of the role of an experienced ethical API hacker.  

An important takeaway from the article is the importance of involving developers in finding and fixing API security issues, despite an already heavy workload. I completely agree that for teams to be successful in securing APIs, developers need to be invested and enthusiastic about the security of their API code, and organizations need to foster a culture of security.

I also recommend watching the full video presentation for more detail on API vulnerabilities.

By the way, I think the images in the article of vulnerable and not-vulnerable code may be  accidentally reversed. 

Report: API security a top priority for digital businesses in Asia

A survey of over 200 technology leaders at digital native businesses (DNB) across Asia highlights the top security concerns in 2024. API security tops the list of cybersecurity investment priorities, surpassing web application and anti-phishing security.

The report links the need for DNBs to deliver more services to customers, faster and at scale, to the growing adoption of APIs to create a system that can meet these needs. This increased reliance on APIs is driving technology leader’s urgency to improve their API security posture.

The survey highlights why the need for API security is more acute for DNBs that are heavily invested in cloud-based technologies. APIs are widely used to support interconnected microservices running in the cloud, and also to support integration of cloud and on-premise systems and applications. 

The report concludes that API security must be integrated into every step of the development process to protect against the various threats and methods used by hackers, including: 

• API path parameter fuzzing
• malicious JSON payloads
• unauthorized API access

Secure API design, rigorous API testing, and a robust governance process for API lifecycle management are some of the essential and recommended steps to help mitigate the risk of API vulnerabilities.

The post Issue 255: Versa Director API flaw, Feeld BOLA vulnerabilities, logic flaw risks aircraft disaster appeared first on API Security News.

Vulnerability: WhatsApp client-side security flaw

A research team at Zengo has discovered a flaw in WhatsApp’s View Once privacy feature. This feature allows a WhatsApp user to send photos, voice messages, or videos that disappear from a chat after the recipient downloads and opens them once. The feature also prevents a recipient from saving, sharing or even screen-capturing a photo or video on their device. 

The discovered vulnerability is an example of inappropriately offloading privacy or authorization checks to the client-side that should actually be performed at the API server.  

Basically, the way WhatsApp has implemented this privacy feature involves the recipient’s WhatsApp client sending a request to the WhatsApp API server to download a photo, for example. The client includes a property in the request called “viewOnce” which will be set to true if the original sender has enabled the View Once privacy restriction. 

The problem is that it is easy for the recipient to change the viewOnce property from true to false if they know how to bypass the client and call the WhatsApp API server directly. In this case the photo is downloaded without its View Once restrictions, overriding the privacy set by the sender and original owner of the photo.

This is a fairly common mistake made by developers who offload authorization or privacy checks to the client. We previously reported on similar incidents, such as a vulnerability found in an app by Siemens.

For more technical details, I recommend the Zengo team’s in-depth report, which includes a video demonstration of the exploit.

The key is to always apply authorization or privacy checks at the API, not at the client level.

Vulnerability: Critical bugs in IBM’s WebMethods platform

This month, IBM released a security bulletin describing critical and high vulnerabilities discovered in its WebMethods Integration platform. 

According to a report by PRNewswire, IBM acquired WebMethods from Software AG earlier this year. WebMethods is widely used for service integration and API management. 

The reported vulnerabilities allow a malicious user to upload and execute arbitrary files on the platform, or grant escalated privileges to a malicious platform account. WebMethods is also vulnerable to path or directory traversal attacks, where a malicious user injects path traversal patterns into the input (“../..”) to trick the platform into sharing access to unauthorized parts of the file system. 

Security vulnerabilities in a trusted API management platform can be exploited by hackers to gain unauthorized access into other parts of the API infrastructure.

IBM strongly recommends that affected users apply the provided patch to fix these issues. 

Article: Unsafe API consumption and LLM integrations 

Many tech companies are excited about enhancing their products by integrating AI solutions. According to one analyst, in the near future “at least 70% of any software product you touch is going to have an AI component to itself”.  

For teams considering deploying and managing a large language model (LLM), OWASP has launched a new Top 10 project to raise awareness of LLM-specific security risks. This is a timely reminder to consider the potential security implications of using LLMs.

AI platforms provide their own sets of APIs to allow developers to integrate AI services into their own products. These AI platforms also consume other third-party APIs, creating a complex supply chain of API producers and consumers. This can expose teams to vulnerabilities from unsafe API consumption.

A recent article by Art Anthony of NordicAPIs highlights the security risks of integrating with third-party APIs, including security issues caused by over-reliance on LLMs.

For teams with projects underway to integrate and leverage an LLM or other third-party platforms, this article provides important food for thought.

Article: How to implement fine-grained API access control 

Four of the top five OWASP API security vulnerabilities involve access control; specifically authentication or authorization. This indicates a broad consensus that access control vulnerabilities represent the most critical risk to APIs. 

For example, Imperva reported that 44% of all recorded account takeover attacks in 2023 specifically targeted APIs, so hackers are certainly focusing on APIs as vulnerable access control points. 

In addition to managing this security risk, API development teams must also implement increasingly complex access control policies. Product managers are tasked with delivering services and features at a fine-grained level, often based on customer requests or sales strategies. The challenge for API teams, then, is how to deliver more complexity with less vulnerability.

In this article, Michal Trojanowski from Curity describes the concept of Attribute-Based Access Control (ABAC) for APIs. His proposed solution combines the security of a well-implemented Oauth-based authorization flow with the fine granularity of claims-based policies, which can meet the needs of enterprises to provide more access options to product services and features in a secure manner.

Given the importance of access control vulnerabilities to API security in general, this article is definitely worth reading.

Article: Promoting secure practices for API developers

A recent article from Cyber Security News explains why developers play such an important role in an organization’s cyber defenses and outlines practices a team can adopt to help prevent common vulnerabilities. 

Secure coding practices and regular security testing can go a long way in preventing API vulnerabilities from leaking into production environments and being exploited by hackers. It’s worth noting that many of the API incidents we report in this newsletter are often a direct result of mistakes and oversights during the API development process. Secure development practices, implemented consistently, can remove entire classes of vulnerabilities from the API code. API developers and testers have a responsibility in this regard, and awareness is essential.

Aside from secure coding and testing, the article also encourages developers to take on leadership roles by staying informed about emerging threats and to be active in promoting security awareness within the team. 

With this goal in mind, consider sharing APISecurity.io with your API development and testing teams as a resource to stay informed about emerging threats and vulnerabilities in the API security space.

Webinar: When GenAI Meets Risky APIs

As Generative AI adoption grows across the enterprise, so does the risk surface for potential data breaches and attacks. API security is a must have if you want to enable the responsible and effective deployment of GenAI technology.

Join my colleagues from 42Crunch as they demonstrate how GenAI can be used to exploit unsecured APIs to gain unauthorized access, inject malicious prompts and manipulate data. Also, learn how to prevent your APIs from being undermined by adopting a proactive API security as code approach to defending your APIs.

Register here

The post Issue 254: WhatsApp and IBM WebMethods vulnerabilities, 3rd-party API and LLM risks, API access controls appeared first on API Security News.

Article: Costly Breaches at National Public Data and T-Mobile 

National Public Data (NPD) in the US has been in the news recently due to a massive data breach. A report by BiometricUpdate.com indicates a breach that includes 272 million Social Security numbers. While the cause of the breach remains unclear, a recent update from KrebsOnSecurity suggests that a sister site to NPD may have accidentally published its own site passwords in a publicly accessible file.

The company is now facing multiple class action lawsuits claiming that NPD: “failed to properly secure and safeguard the PII that it collected and maintained as part of [its] regular business practices.”

In addition to the allegation of failing to protect customers’ PII, the company has also been criticized for its lack of transparency and failure to notify victims of the risk in a timely manner. This is another potential pitfall for companies, as different industries, from finance to healthcare, have different reporting requirements, and some are more stringent than others. For example, under the HIPAA Breach Notification Rule, organizations that handle U.S. citizens’ health data must notify affected individuals within 60 days. Companies that delay notifying their customers can face additional penalties.

Meanwhile, T-Mobile is facing its own data breach issues. According to a report in The Cyber Express, the Committee on Foreign Investment in the United States (CFIUS) recently fined T-Mobile $60 million for “not taking adequate measures to prevent unauthorized access to sensitive data and reporting incidents in a timely manner”.

So, once again, a company is being penalized both for its lack of adequate cybersecurity and for failing to report the incidents to regulators and the victims of the breach. 

Both cases should encourage companies to review existing cybersecurity controls to protect customer data, as well as the tools and processes in place to report incidents to the right people in a timely manner.

Vulnerability: Blind SQL Injection discovered in Cisco APIs

A Cisco security advisory highlights multiple API vulnerabilities discovered in Cisco’s Identity Services Engine (ISE) product, exposing the tool to blind SQL injection attacks. 

In a traditional SQL injection attack, the API is tricked into leaking unauthorized data directly from the SQL database. But in a blind SQL injection attack, the API doesn’t leak data directly. Instead the attacker sends carefully crafted true or false questions to the database to brute-force the data leak. 

This means that it takes a bit more work for an attacker to pull off a blind injection attack. Rate-limiting the API can also help mitigate the risk by limiting the number of true or false questions an attacker can submit.

However, for both types of SQL injection the vulnerability often occurs due to insufficient validation of user-supplied input. It is the responsibility of API developers to adopt secure development practices and validate user input to ensure that only expected API data is accepted.

The vulnerable Cisco ISE product is described as “the industry-leading tool for ultimate visibility into every device on your network”. Critically, API attacks against this kind of network management device can expose other parts of the system to attacks. Similarly, SQL injection vulnerabilities have also been discovered in the F5 Big IP Next device.

You can read more technical details about the issues and solutions in our in-depth analysis in this article: The Scourge of SQL Injection for APIs. 

Vulnerability: API flaw exposes Traccar GPS system to remote attacks

According to a report by Cyber ​​Security News, a critical API vulnerability has been discovered in the open-source GPS tracking system Traccar. A new API endpoint allowed users to upload image files to the Traccar system. However, user input was not properly validated or sanitized, exposing the API to path traversal attacks.

The vulnerability report outlines the potential impact of an exploit:

“Attackers have full control over the file contents, full control over the directory where the file is stored, full control over the file extension, and partial control over the file name”.

A path traversal attack typically tricks a vulnerable API into uploading or downloading a file from an unexpected location on the API server file system. The attack works by injecting special patterns into the API input, such as “../”. This causes a vulnerable API to switch to a parent directory on the server, giving the malicious user control over where the API accesses files from. 

A path traversal vulnerability occurs when an API does not properly validate user input and allows malicious patterns. In the case of Traccar, the vulnerability could be exploited through two parameters in the APIs request: a device uniqueId property and a content-type header.

Reliance on open source software (OSS) carries the risk of security vulnerabilities. The Traccar team is certainly to be commended for devoting time and effort to developing and sharing its source code. However, any individual or company that chooses to leverage OSS to provide services to their customers should take extra precautions to verify, and if necessary implement, adequate security.

Too often, OSS risk is measured by CVEs found in the code. This is helpful but does not cover the full range of API vulnerabilities that may be latent in the code. Development teams relying on OSS should be required to perform a thorough review and audit of the APIs defined and implemented by OSS, to locate and remove vulnerabilities.  

Something to watch out for in your own API development. 

Article: Safely integrating APIs in the automotive ecosystem

Nowadays all kinds of technologies and services are integrated using APIs to provide exciting new features and capabilities. The security of these systems depends heavily on the integrity of the data transmitted between trusted API connections. A single weak point can expose the entire system to a breach.

One of the most recent API vulnerabilities introduced in the OWASP 2023 API Top 10 list is “Unsafe Consumption of APIs”. From the OWASP release notes:

We added “Unsafe Consumption of APIs” to address something we’ve started seeing: attackers have started looking for a target’s integrated services to compromise those, instead of hitting the APIs of their target directly. This is the right time to start creating awareness about this increasing risk.

This risk from integrated services is widespread in the automotive industry. A recent article by Ling Cheng of Trend Micro subsidiary VicOne describes the complexity of API connections powering modern vehicles, including between embedded subsystems, mobile apps and SaaS applications from the auto manufacturer and various component suppliers. 

Each of these API connections represents a potential weak point that an attacker can exploit to compromise any other part of the system. Ling’s article shares recommendations for managing API security risks in such an expansive automotive ecosystem. VicOne has also published a white paper on the topic that includes real world examples.

Definitely worth a read.

Article: How APIs facilitate financial regulatory compliance

The term “financial grade security” is synonymous with the highest standards in API security. It is also used outside of the financial sector, and in fact the working group formerly known as “Financial Grade API” was renamed FAPI to reflect the fact that API security frameworks from the financial sector can be positively applied in other industries.

One reason why financial security is considered a gold standard is that financial institutions must comply with strict regulations regarding cybersecurity, consumer data protection, and data access. APIs play a vital role in this compliance.

The Financial Data Access (FiDA) framework mandates the sharing of customer data between institutions, and APIs provide the standard interfaces to facilitate this data sharing. This brings APIs within the scope of other financial regulatory frameworks such as Digital Operational Resilience Act (DORA) which mandates resilience to cyberattacks. 

If you’re interested in learning more about the role of APIs in the financial sector, I recommend this recent article by David Roldán Martínez on LinkedIn. In it, he calls APIs the “backbone of compliance” and describes in detail how APIs help organizations meet the stringent security and integration requirements of FiDA and DORA.

Great insights from David on the topic of financial APIs. 

The post Issue 253: Breached companies face litigation, SQL injection in Cisco APIs, API Security for Automotive & Finance appeared first on API Security News.

Survey: API security insights from APAC

A survey of 297 professionals across various industries in Asia-Pacific highlights the top concerns around API Security. Here are some of the insights that caught our attention in this report.

Internal APIs are the most commonly used APIs by organizations in the Asia Pacific region, but the biggest concern when it comes to API access control is the risk posed from external users.

This may indicate that API security is still viewed through a traditional lens of “perimeter security”, where a WAF or Gateway appliance deployed at the ingress/egress point centrally controls external user access to on-premise applications.

However, internal APIs present new security challenges. Without authorization and access control policies between internal APIs, a single breach at a benign entry point can quickly escalate into lateral attacks on more critical back-end systems.

So for organizations in the Asia Pacific region that primarily use internal APIs, access control policies for east-west traffic must also be a major concern. Protecting traffic between internal APIs requires security controls deployed closer to the API than the traditional edge perimeter.

Organizations in the Asia Pacific rank the OWASP API Top 10 vulnerabilities in different order than the standard list.

The top three vulnerabilities on the APAC list are:

• #1: Broken Authentication (API2:2023)
• #2: SSRF (API7:2023)
• #3: Security Misconfiguration (API8:2023).

Interestingly, priorities also differ across countries. For example, Malaysian organizations report that API3 (Broken Object Property Level Authorization) is the top risk, while New Zealand is more concerned about API10 (Unsafe Consumption of APIs).

So while OWASP API Top 10 list is a useful and relevant model, API security solutions must be both comprehensive and flexible to cover the different needs and priorities of organizations in the Asia Pacific region.

Data leakage is the top priority for API runtime protection

Previous incidents discussed in this newsletter, such as the Spoutible API incident, demonstrate why data leakage is such a critical concern, and why authorization checks should be performed on both API request and response messages.

API security often focuses primarily on threats from inbound requests. But even if you do all the work to harden and protect your APIs from outside attacks, those APIs can still leak sensitive data in very damaging ways, through development errors or  inadequate authorization policies.

So this is a positive sign that organizations in the Asia Pacific region are recognizing and prioritizing risk on both sides of the API transaction, to address both inbound malicious attacks and outbound data leakage.

Article: Salutary lessons for management teams everywhere 

Crowdstrike has been in the news for all the wrong reasons recently. On July 18, a software update containing a critical bug was distributed globally by Crowdstrike, causing millions of Windows machines worldwide to crash and fail to restart. Some media reports have called this incident the largest outage in the history of information technology.

As the fallout continues for affected customers and for Crowdstrike, there are important lessons to be learned for management teams who want to avoid testifying before the U.S. Congress about their internal software testing and deployment processes…or lack thereof.    

As this article by The Register reports, in response to Crowdstrike’s promises to begin implementing practices like canary testing to prevent future disasters, angry investors were quick to point out that the company should have done canary testing in the first place. A class-action lawsuit filed by investors against Crowdstrike soon followed.

If you’re not familiar with the term, “canary testing” (sometimes called canary deployment) is the practice of releasing a new software update to a small subset of users initially, and then gradually releasing the update to all users. The benefit of this approach is that it allows users to test the latest version of the software, and in doing so catches critical flaws before the updates are released to a wider user base. If flaws are discovered and reported during the initial canary testing, damage is significantly limited to a small select subset of users. 

This process of course also applies to pushing out updates to your API. So if your team hasn’t implemented this practice yet, don’t wait for the canaries to come home to roost.

Vulnerability: OWASP API vulnerabilities in Solar Platforms

As concerns about the impact of climate change continue to grow, we could expect to see increased investment and reliance on alternative energy sources around the world. Worryingly, the security of those new energy systems and their potential vulnerability to cyberattacks is being called into question by this report from a research team at BitDefender.

The report describes how critical API vulnerabilities were recently discovered in products from two of the world’s largest solar management platform manufacturers. The vulnerabilities discovered correspond to the top three vulnerabilities in the OWASP API Top 10 list:

• API1:2023 Broken Object Level Authorization
• API2:2023 Broken Authentication
• API3:2023 Broken Object Property Level Authorization

We should not be surprised to learn that APIs are being used in these safety-critical systems, as APIs facilitate interoperability between solar platforms and connected equipment from various manufacturers.

However, the security and reliability of critical systems should be paramount, and it is disconcerting that these platform APIs are vulnerable to authentication and authorization attacks that could potentially impact millions of people. 

The Bitdefender team should be commended for ethically discovering and reporting the API vulnerabilities to both vendors. However, the incident raises serious questions about regulations, standards, and practices for developing API for solar power devices. 

Other industries such as the Automotive industry have already established standards mandating cybersecurity and API protection for vehicle manufacturing. Similar standards are clearly needed to protect our critical energy infrastructure in the future. 

Vulnerability: Siemens React app missing API authorization

A research team recently discovered a vulnerability in a React app from Siemens which allowed them to bypass the app’s client authentication and retrieve unauthorized data from the API. 

According to the team’s report, the API failed to enforce authorization on the applications requests, trusting instead that the app had already authenticated and authorized the user on the client side before making the API requests. This is a critical error in API development.

A React single page application (SPA) is typically developed as a combination of a client-side UI component that renders a display in the user’s browser, and a server-side API that provides data to the client UI as needed…and hopefully as authorized.

It is important to note that data returned by an API to the client can be exposed, even if it is not displayed in the client UI. For example, an attacker can easily bypass the client and interact directly with the API. For this reason, SPAs should never perform client-side authentication or authorization. Instead, all data requests should be authorized by an API, and an API should only return necessary and authorized data to the client-side application.

This is a fairly common mistake made by app developers, and can expose an organization to unauthorized access to data. We recently reported on a similar case in the newsletter, where two curious students from Santa Cruz managed to hack into a national network of washing machines. API hygiene indeed!

To protect against similar vulnerabilities in your Angular or React applications, test APIs directly to ensure that a valid credential or access token is always required by the API before returning private data. Additionally, limit the data returned by the API to what is necessary and authorized for each client request, to avoid exposing excessive data to the client. 

Report: Cost of data breaches rises to USD 4.88 million

A Ponemon Institute study of 604 organizations affected by data breaches between March 2023 and February 2024 found a 10% increase in the average cost of a data breach over the past year. The average cost to an organization is now USD 4.88 million.

One of the biggest factors that influences the cost of a breach is the time it takes to identify and contain the breach. We noted the following statistics from the study:

• The mean time to identify a breach is 194 days
• The mean time to contain an identified breach is 64 days

This suggests the greatest opportunity to reduce the overall cost of a data breach lies in early identification, and the report also indicates which actors typically identify a breach: the organization, the attacker, or an ethical third party. 

It is therefore worth noting that it is in the best interest of organizations to facilitate a formal process and communication channel so that external researchers can disclose vulnerabilities in an ethical manner. This is not always the case, and some researchers have in the past expressed frustration when trying to disclose their findings to an organization.

Something as basic and relatively inexpensive as a dedicated contact address or secure channel that is easy for researchers to find and quick in response, could save an organization millions of dollars by leveraging the help from external parties to reduce the mean time to identify a data breach.

The study also found that stolen credentials were the most common attack vector in 2024, used by attackers in 16% of all data breaches. This is an important point for API teams, as an Imperva report from this year also found that 44% of all automated attacks aimed at  compromising user credentials target APIs. 

APIs therefore remain a prominent target for attackers and require reliable and effective API security to avoid the costs of data breaches.

Breach: Tencent incident highlights consequences of data leaks

A hacker has released the account information of more than 1.4 billion users, claiming that the data came from Chinese tech company Tencent. Researchers at Hackread.com believe the data may have come from a massive data breach discovered in January this year.

In this latest report, the research team lists the potential consequences that companies can face if customer data is stolen and exposed. This list can be a useful resource for a security professional looking to convince the management team to increase the security budget. 

The list of negative consequences for an organization includes:

• privacy violations
• reputational damage
• financial impact
• regulatory scrutiny
• increased cybersecurity risks
• impact on users 

Are there any other potential implications not mentioned here? You can email your ideas or suggestions to editor@42crunch.com

The post Issue 252: API Security in APAC, Crowdstrike and canary tests, API vulnerabilities in solar platforms and React apps, Costs of a data breach appeared first on API Security News.

Report: FCC weighs in with API security requirements

The U.S. Federal Communications Commission (FCC) has established a list of API security controls as part of a mandatory information security program at Tracfone, a wireless service provider. The company was also fined $16 million in connection with a series of data breaches that exposed its customers’ personal information.

The details of the mandated security program are included in a consent decree issued by the FCC, which specifically emphasizes the paramount importance of API security. Some of the highlights include:

• All input and output data validated and sanitized to prevent injection vulnerabilities
• All output data validated and authorized to avoid excessive data exposures
• All data securely communicated over an encrypted channel (e.g. TLS sessions)
• Numeric identifiers generated to be unpredictable (helps to avoid BOLA exploits)
• Check for the vulnerabilities listed in the OWASP API Security Top 10 List 

The list of security controls compiled by the FCC can be a useful reference for other API teams who wish to implement a security program to prevent costly API vulnerabilities. 

Vulnerability: Dating Apps highlight risk of client-side data filtering

An article on the Dark Reading website reveals how popular dating apps leak sensitive user information in API response messages, drawing a contrast between the filtered data displayed in the app UI and the unfiltered, more sensitive data returned by the API.  

An example given in the report describes a user choosing to display their age in the app, while the API returns the user’s full date of birth to the app. This exposes more information than the user intended if you know where to look (hint: hackers know where to look).  

APIs should only return data that is necessary and authorized for a request. Some API developers return data generically and leave it up to the client to determine what data to show or hide based on, for example, the end user’s privacy settings. 

This is a mistake because it is often easy for an attacker to bypass a client-side application and access the raw data returned by an API. The golden rule is to never rely on the client to filter sensitive data. Instead, make sure the API only returns necessary and authorized data.

The OWASP documentation on broken object property level authorization recommends a number of API development practices to avoid excessive data exposure:

• When exposing an object using an API endpoint, always make sure that the user should have access to the object’s properties you expose.
• Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism, define and enforce data returned by all API methods.
• Keep returned data structures to the bare minimum, according to the business/functional requirements for the endpoint.
  

Breach: Life360 API leaks personal data of 400,000 customers

Continuing on the topic of APIs leaking sensitive data, a recent article in CPO Magazine describes how login attempts on the mobile tracking app Life360 returned excessive data in the API response, including the name and mobile phone number of unauthenticated users. 

A hacker exploited this vulnerability to compile a list of personal information on more than 400,000 Life360 customers. The method used to exploit the vulnerability appears to follow a similar pattern to other industry cases we have covered recently, such as mass data scraping at Authy and Trello. In each of these incidents a hacker iterates through a list of stolen email addresses, sending each as input to the API one by one. If an account exists for a given email address, the vulnerable API returns personal information about the user.  

The article states that the exploit occurred while “attempting” logins. This suggests that the API response containing the sensitive data was actually an error response (e.g. HTTP 401), which should remind API teams to continually test and validate the contents of API success and error responses, since both can be vulnerable to leaking sensitive information.

The article also highlights how the exposed information was not visible to a user through the mobile app’s UI, but could be found behind the scenes in the API response (sound familiar?). The fact that hackers can so easily bypass the app UI and delve into the API traffic, highlights again the importance of testing our APIs directly to ensure that developers apply appropriate constraints to the API response. 

Validating users’ personal information at the app UI level is not sufficient, as it can hide the leakage of unauthorized information that occurs from the API.

Vulnerability: Docker AuthZ plugin and unsafe API consumption

According to a report by The Register, a vulnerability in Docker’s AuthZ plugin allows users to bypass authorization using a specially crafted API request with Content-Length set to 0.

The authorization process involves a sequence of API calls between a client, the Docker daemon, and the AuthZ plugin. A client sends an API request to the Docker daemon, which in turn sends an API request to the AuthZ plugin. The AuthZ plugin uses content in the API request body to decide whether a user’s request should be allowed or denied.

The vulnerability occurs when the body of the request to the AuthZ plugin is empty and does not contain any authorization information. In this case, the AuthZ plugin apparently authorized the request from the Docker daemon by default; which is strange behavior for a security control. 

I think the AuthZ plugin API was probably implemented to always expect valid authorization content from the Docker daemon. An unsafe assumption if that is the case, since the Docker daemon was vulnerable to a malicious API request from the client, which it then passed on to the AuthZ plugin. 

The OWASP guideline for the “unsafe consumption of APIs” vulnerability highlights that this is a common mistake developers make when the input data comes from a well-known source: 

“Developers tend to trust data received from third-party APIs more than user input. 

This is especially true for APIs offered by well-known companies”

All input data processed by an API, regardless of its source, must be validated before use to ensure it conforms to expectations of functionality and access control. Or, to put it more succinctly, verify don’t trust. 

The post Issue 251: FCC mandates API security, API vulnerabilities in dating apps and Docker plugins, Life360 API data leak appeared first on API Security News.

As this is a significant milestone for 42Crunch and APIsecurity.io, namely our 250th issue, we are starting a new initiative. We’re inviting readers to share articles you’ve read that you feel merit inclusion in the newsletter. You can submit suggestions via email here.  This week we feature two interesting articles from our APISecurity.io readers.

Breach: Another unsecured API vulnerable to mass data scraping 

In a report released earlier this month, Authy, a provider of two-factor authentication (2FA) solutions, confirmed how a threat actor used an unauthenticated API to verify millions of users’ phone numbers registered with Authy to generate one-time passwords. 

This incident is similar to another recent case of mass data scraping via Trello’s API, which I covered in depth in a recent 42Crunch webinar. Both incidents have common characteristics to avoid in your own API development: 

1. An API that does not require authentication. This means a malicious user can easily abuse the API without first creating an account.
2. An API that does not enforce authorization. So, a user can retrieve account information about other users.
3. An API that accepts an identifier like a phone number or email address and, if found, returns the user’s account information. This allows a malicious user to verify the existence of a user account for a given identifier.
4. An API that does not enforce rate limiting, or where rate-limits can be bypassed. This puts the mass into mass data scraping!

An API that returns user account information should apply authorization and rate-limiting controls, to limit the information to authorized users and use cases only. 

Vulnerability: Injection attacks prompt calls for ‘secure by design’

In a recent alert, leading security agencies in the United States are urging teams to adopt the ‘secure by design’ principle for software development as a more effective way to prevent injection vulnerabilities. This follows a number of successful OS command injection attacks that have targeted and compromised network edge devices. 

OS command injection is similar to other injection vulnerabilities, such as SQL injection, XPath injection and cross-site scripting, all of which involve the injection of malicious input causing unexpected or unauthorized behavior in the target. These vulnerabilities are also commonly found in APIs and are the cause of significant API breaches.

Recommended solutions to prevent injection attacks focus on limiting, sanitizing, and properly validating user input. The goal is to distinguish between good and bad input, and ensure only the good input gets through.

The benefit of a secure-by-design approach is that it enables teams to define in advance the type, format, structure and range of valid values that can be expected from user input. This early definition ensures that reliable security rules can be built into the code, verified by testing teams, and monitored for compliance by security and operations teams as the code is deployed to production.

Secure by design is the most effective way to protect software, including APIs, from injection vulnerabilities that constantly expose organizations to cybersecurity attacks. This also appears to be the conclusion of major US security agencies.

Vulnerability: API Security raising the “steaks” for IoT

A broken authorization vulnerability in the API of a Traeger Grill (yes, you can now cook your steak by API) allowed a malicious user to remotely control other users’ grills. 

That’s the discovery of Bishop Fox’s Nick Cerne, who explained how his team managed to hack a grill registration API to remotely take control of a grill belonging to a colleague and then adjust the grill’s temperature to maximum setting. 

In this case, ownership was identified only via a grill ID that could be retrieved from a sticker physically located on the grill. Additional security measures included a device-generated certificate, but this was not enforced by the API and so the ID alone was sufficient to control the device.

Using a grill ID as the sole means of authorization is comparable to using API keys for the same purpose. This assumes that the legitimate holder of the key (or grill sticker) has the motivation and means to keep it private from other users; despite a long history of API keys being hardcoded into apps, transmitted without encryption, or accidentally pushed to Github.  

So, although the potential impact here was limited to burnt food and some frustrated grillers, this case highlights the importance of sufficient and effective authorization controls in APIs. 

Hopefully the report will provide your API team with some food for thought.

Reader’s Share: API Security and the Circuit Breaker pattern

This informative blog post describes the circuit breaker pattern for APIs and the options for its implementation.

Circuit breaker is a design pattern for APIs that protects backend infrastructure from a flood of API requests when a component such as a database or remote service temporarily goes down. Essentially, this pattern prevents API requests from overloading the backend and allows the failing component the opportunity to recover and resume service. 

When backend infrastructure fails, it can also expose vulnerabilities in an API’s error handling. If infrastructure details are unintentionally disclosed in the API’s response to the client, a malicious actor can launch more targeted attacks on a system. Again, the circuit breaker pattern could potentially prevent such leaks by temporarily separating the API and its response from the failing backend component.

Thank you to Nevatek’s Andrew Slivker for the share!

Reader’s Share: Deactivating an API, One Step at a Time

In this article, Bruno Pedro presents a process for decommissioning APIs, taking into account the impact of changes on API consumers.

Deactivating a public API can be a delicate balancing act between a product engineering team that wants to sunset an aging API, and a customer success team that needs to communicate and manage change with API consumers who may be reluctant to make the necessary changes.

Importantly, this type of governance process also has significant security benefits by preventing zombie APIs. The recent zombie API breach at Optus, reported in our previous issue of this newsletter, highlights the risk when teams fail to properly manage an end-of-life process for their APIs.

Thank you to 42Crunch’s Fyodor Loenko for the share!

Events: Black Hat Summit, Las Vegas

The 42Crunch senior leadership and technical teams will be at Black Hat Summit next month in Las Vegas.  We will also be demoing our API security technology on the Microsoft Stand #1240 on Thursday on the main conference floor. If you’d like to schedule a meeting please reach out. 

The post Issue 250: Authy API breach, US agencies push secure by design, APIs grill IoT devices, shares by our readers appeared first on API Security News.

Breach: API Governance and PII data exposure at Optus

A recent report from The Register explains how a coding error in an API’s access controls exposed the personal identifiable information (PII) of millions of Optus customers. We originally reported on this breach in Issue 203, from October 2022.

Importantly, the coding error was discovered and fixed for the API in one domain but was missed for another unused domain. This unused and vulnerable domain allegedly remained publicly available on the Internet for years, where it was eventually exploited by a malicious user to steal millions of customer records, including passport and driver’s license numbers and birth certificate information.

In this case, the target API was not in use and should have been decommissioned. API discovery tools are sometimes offered as a solution to finding unknown or forgotten APIs. However, how do you automatically discover an API that is both forgotten and unused? Additionally, most APIs use HTTPS where the API path is encrypted until TLS is terminated, so you need to know exactly where to look to find evidence of an unexpected API endpoint. With API discovery, you can’t find what you’re not looking for, let alone what you can’t see.

Forgotten “Zombie” APIs are often the result of a lack of collaboration between development, operations, and security teams. Organizations that want to avoid legal action due to these types of API breaches should have explicit API governance processes in place to ensure that no API goes into production without the knowledge of the security team, and that an appropriate end-of-life process is implemented for every API. 

Vulnerability: Millions of devices impacted by Cocoapods software supply chain vulnerabilities

Researchers at EVA Information Security have discovered major vulnerabilities in Cocoapods ecosystem, with potentially devastating consequences for millions of iOS users and devices. 

Some of the vulnerabilities in this case were a direct result of flaws in API security. For example, ownership of Pods could be claimed by unauthorized users through an API that does not require authentication or authorization. The unauthorized user could then modify the Pod and affect all dependencies downstream in the supply chain, including major technology vendors, their applications, and devices. 

Researchers also discovered a flaw in an API used to generate a session validation URL. The API code failed to properly validate input on HTTP headers, allowing a spoofed X-Forwarded-Host (XFH) header in the API request. This header was then used to set the domain of a session validation link, effectively passing the session validation under the control of an attacker.

While these API vulnerabilities are worth considering, the most significant issue revealed is modern software development’s deep reliance on third-party and open-source software components. Vulnerabilities in these components, and even in the systems we depend on to manage these components such as CocoaPods, have profound consequences for dependent applications and APIs.

A recommended step to help manage software supply chain risks is the adoption of a Software Bill of Materials (SBOM), to provide an inventory of all components used to create an application or API. Evaluating risks can also help teams make informed decisions to avoid unsafe consumption of third-party APIs, which makes the list of OWASP Top 10 API Vulnerabilities.

Vulnerability: Logging utility found vulnerable to API DoS attack

Fluent Bit is a logging utility used by many major global companies such as Google, Cisco, and Walmart. Recently, Tenable reported a vulnerability in a Fluent Bit monitoring API that could be exploited to corrupt memory and crash the service.

A common playbook used by hackers is to send corrupted input to an API in order to invoke an unexpected response and reveal an exploitable vulnerability. An API vulnerable to this attack will accept and process input data, without first performing the appropriate checks and validations to ensure the input is safe to use. This is typical for example of APIs deemed vulnerable to SQL injection or Path Traversal attacks.

With Fluent Bit, the API code was developed to assume that the input type was always a string, a pretty dangerous assumption by the developers as it turned out. When strings were replaced with integer values, the API blindly treated the input as the expected string types. The researchers were then able to exploit the discovered vulnerability and crash the system.

Your API testing team can adopt the mindset of a hacker and probe the API for vulnerabilities using malformed input and invalid data types. For example if an APIs input field is defined as a string, then test the APIs behavior when the input is a boolean, or an integer, or null. You can automate and scale these tests by leveraging an API’s OpenAPI file to read the expected data type for each input field. Then automatically fuzz the data type and verify the API’s response (anything other than a ‘400 bad input’ response likely indicates a security vulnerability).

If you want to learn more about this topic, be sure to check out the upcoming 42Crunch webinar mentioned below.

Report: How Bad Bots are targeting authentication APIs

In a 2024 industry report on “bad bots”, Imperva recorded that 30% of API attacks were automated attacks, often seeking to exploit vulnerabilities in business logic. Additionally, nearly half of all account takeover attacks target authentication APIs, using credential stuffing and brute force attacks.

Business logic vulnerabilities can be discovered through APIs by various means. As we saw in the previous article, hackers often send corrupted data in the API request in order to invoke unexpected behavior or response from the API.

It is therefore important for API developers to ensure proper input validation of all incoming API requests, including the request payload, parameters, and headers. This can help limit a hacker or bot’s ability to probe an API with corrupted data to discover a vulnerability.

Additionally, even with reliable input validation, APIs can also be vulnerable to excessive data leaks. Again, API developers must ensure proper inspection and authorization of the API response to ensure additional business data is not unintentionally exposed.

Targeting authentication APIs also raises the need for rate limiting at the API level. Traditionally, businesses are well aware of the need to protect websites and applications against denial of service and brute force attacks. But as software teams move toward more API-centric development, security controls must also be applied specifically to protect API endpoints that might otherwise be vulnerable to account takeover attacks.

Webinars:
Navigating the Depths of API Security with Microsoft & 42Crunch
July 10, 2024 | 10am PDT | 6pm BST

42Crunch and Microsoft give a deep dive on API security testing as part of the Reactor spotlight on GitHub Advanced Security. From scanning OpenAPI specs to dynamic testing, they’ll equip you with practical strategies to harden your APIs against attacks.

Register here

Review of Major API Security Breaches from H1 2024

July 11, 2024 | 9am PDT | 5pm BST

I’m joined by my colleague Heshaam Attar as we review some of this year’s high-profile API vulnerabilities and breaches including the F5 Big-IP Next device and the Trello and Spoutible APIs. 

Register here

The post Issue 249: Major API breach at Optus, CocoaPods exposed, Bad Bots and API DoS attacks, Webinar: 2024 API breaches appeared first on API Security News.

Before we dive in, I’d like to introduce myself, Anthony Lonergan Developer Relations Lead with 42Crunch and the new Editor of your APIsecurity newsletter. I’d like to thank my colleague Colin Domoney for his great work over the past few years curating and editing the newsletter and wish him every success with his new book, Defending APIs. I will strive to maintain the editorial quality and adhere to the principles you’ve come to expect from one of the API security industry’s leading sources of relevant news.

Breach: UC Santa Cruz students use vulnerable APIs to penetrate the largest laundry network in the US

First, this Techcrunch article about two UC Santa Cruz students who discovered API vulnerabilities that allowed them to remotely control washing machines for free, and add millions of dollars in credit to their laundry accounts (non redeemable, unfortunately for the students).

The APIs in question lacked proper authorization controls. The important checks that should have been performed at the API, such as checking if the user has enough credit before starting a laundry service, were instead assumed to be performed by the client-side app. 

This is an all-too-common mistake when teams move from MVC to SPA. You cannot continue to rely on the client to put in place the necessary security checks, since a hacker can simply go directly to the APIs and by-pass the client.

When it comes to designing, implementing and testing APIs, careful consideration should be given to the function or service provided via the API, and whether or not authorization controls need to be applied. This calls to mind the OWASP Top 10 API Security vulnerability: Unrestricted Access to Sensitive Business Flows. 

OWASP recommends a two-tiered approach to mitigating your risks from this API vulnerability:

• Identify the business flows to protect
• Select the appropriate protection mechanism

I would also include adding authentication and authorization tests to your API test suites, to verify that those controls are implemented correctly and consistently. 

Notably, the students in this case made numerous attempts to ethically report the vulnerabilities to the vendor. For more technical details, I also recommend this blog post which explains the step by step process for uncovering and verifying the API vulnerabilities.

Breach: API vulnerabilities exposed millions of Cox modems to remote hacking

Securityweek recently reported a case of API vulnerabilities discovered in Wi-Fi modems of American telecommunications giant Cox Communications. The vulnerabilities, ethically reported by researcher Sam Curry, allow an unauthenticated user to send commands to the Wi-Fi modems of millions of residential and business customers, to extract PII data and change modem settings.

One of the key revelations that opened the door to the whole system was that the API response went from unauthorized to authorized, simply by making the exact same API request over and over again. This appears to be an unusual case of broken authorization.

“Insanity is doing the same thing over and over again and expecting different results”… except for hacking APIs apparently.

Although the underlying cause of the vulnerability is unclear, the example presented in this article once again raises the importance of testing APIs for authorization vulnerabilities such as BOLA and BFLA. They occupy the top spots in the OWASP Top 10 lists due to their prevalence and potential impact.

Curry was also able to identify information about the API server infrastructure based on the structure and format of the APIs error response. This type of security misconfiguration vulnerability can unintentionally help hackers (ethical or otherwise) strategically probe an API for other vulnerabilities. 

If you’re interested in a technical deep dive I highly recommend this blog post from Sam Curry.

Article: Why, after 6 years, I’m over GraphQL

The pros and cons of GraphQL will no doubt continue to be discussed and debated over water coolers and in Slack channels for some time to come. We’ve certainly covered the topic from a security perspective several times in this newsletter.

However, this recent article by Matt Bessey, a self-described former GraphQL champion, has certainly generated some more discussion and debate.

The takeaway is that for projects where greater emphasis is placed on non-functional factors, such as security, performance, and maintainability, the perceived merits of GraphQL are quickly outweighed by the difficulties. 

You can read more in the followup online discussions here.

Article: The vital role of APIs in modern supply chain logistics

Modern supply chains demonstrate both the opportunities and risks associated with integrating complex systems via APIs.

APIs facilitate essential automation of data flows and coordination of processes across disparate technology platforms that modern supply chains depend on. However, this Forbes article highlights some of the security risks that should be considered before adding third-party APIs to a supply chain.

In the event of excessive data exposure, it is the responsibility of the API producer to ensure that only necessary and permitted data is returned in any API response. If too much data is returned by the API, and especially when that data is sensitive in nature, it can cause security incidents and undermine trust in the supply chain system.

The other vulnerability discussed in the Forbes article concerns unsafe consumption of APIs. Here, the onus is on the API consumer to securely integrate any external API into the supply chain and not automatically trust third party data, even if it comes from a trusted partner or a reputable organization.

OWASP recommends the following steps to help create secure API integrations: 

• When evaluating service providers, assess their API security posture.
• Ensure all API interactions happen over a secure communication channel (TLS).
• Always validate and properly sanitize data received from integrated APIs before using it.
• Maintain an allowlist of well-known locations integrated APIs may redirect yours to: do not blindly follow redirects.

Article: API security for the connected vehicle

Best practices in software development are a key requirement in producing reliable software in the automotive industry, codified in industry standards such as Automotive Spice and ISO-26262. 

Many of these same rigorous practices also apply to API development. Security requirements must be carefully captured, implemented, tested, and verified to ensure that running APIs are secure by design.

As the requirements of modern vehicles evolve towards more complex functionality, as well as more sophisticated connectivity to external clouds, applications and backend systems, APIs are increasingly leveraged to power these connections.

And it is in this digital evolution towards increasing adoption of APIs that the automotive industry has recognized and responded to the growing cybersecurity risk on automotive software.

This month, Trend Micro subsidiary VicOne announced a new partnership with 42Crunch to address growing API cybersecurity challenges for the automotive industry, together offering a comprehensive solution to help automakers comply with new regulations and standards for API protection.

The post Issue 248: API penetration of apps and modems, GraphQL and its discontents, API security for supply chain and automotive appeared first on API Security News.

Breach: Dropbox users in major data breach

The first breach this week was a potentially large-scale one suffered by Dropbox. Dropbox disclosed a data breach affecting its Dropbox Sign (formerly HelloSign) users. The company filed a breach disclosure with the US Securities and Exchange Commission (SEC) and posted a blog alerting customers about the incident on April 24th, 2024.

Unauthorized access was gained to the Dropbox Sign production environment, compromising customer information such as emails, usernames, phone numbers, hashed passwords, account settings, and authentication information (API keys, OAuth tokens, and multi-factor authentication). This breach is important from an API security viewpoint since many corporate users are potentially using Dropbox as a storage vault, which may contain critical authentication credentials. 

The breach was limited to the Dropbox Sign infrastructure, and other Dropbox products were not impacted. There is no evidence that customer account information, including contract agreements, templates, or payment information, was accessed.

The threat actor used a compromised service account to escalate privileges within the Sign’s production environment and access the customer database.

Dropbox is contacting impacted users with instructions on how to protect their data. The company has reset user passwords, logged users out of connected devices, and rotated API keys and OAuth tokens. Dropbox is working with outside forensic security investigators, and law enforcement has been notified. 

Breach: Dell API abused to steal 49 million records

The next breach is the scraping attack successfully launched against Dell. A threat actor known as Menelik abused a partner portal API to scrape the information of approximately 49 million Dell customer records. The stolen data included customer names, order numbers, service tags, installed locations, and more. It appears no financial information was included in the breach.

According to the threat actor, they could easily register multiple fake partner accounts to gain access to the portal. They then created a program to generate service tags and submit API requests, scraping customer data at a rate of 5,000 requests per minute for three weeks in March 2024 before Dell detected and stopped the activity. 

The threat actor claims they emailed Dell about the vulnerability in April before putting the data up for sale on a hacking forum. However, Dell states they were aware of and investigating the incident before receiving the actor’s email.

This incident highlights the risk of companies having easily accessible APIs without proper rate limiting and verification processes, which threat actors are increasingly abusing to conduct large-scale data scraping and breaches. Implementing stricter controls around API access is critical for preventing such incidents.

Vulnerability: Critical Next.js vulnerability allows server compromise

Next, we have news of a pair of vulnerabilities in Next.js, a popular web development framework. These vulnerabilities have been assigned CVE-2024-34350 and CVE-2024-34351, both with a severity rating of 7.5 (High).

CVE-2024-34350 is a vulnerability that can lead to response queue poisoning when exploited by threat actors. This vulnerability is caused by an inconsistent interpretation of crafted HTTP requests, which are meant to be treated as a single request but are instead treated as two separate requests. To exploit this vulnerability, the affected routes must use the rewrites feature in Next.js. This vulnerability has been patched in Next.js versions 13.5.1 and newer, including 14.x.

CVE-2024-34351 is a Server-Side Request Forgery (SSRF) vulnerability that exists in a vulnerable API endpoint _next/image, which is used to locate an image in the backend. This endpoint is a built-in component and is enabled by default in Next.js. The vulnerability arises when a server action is called, and the response is a redirect, with specific parameters used in the redirect. If the redirect starts with a /, the server will take the result of the redirect server_side and return it to the client. The server_side was found to be taking the host header from the client, which can lead to SSRF if the host header is pointed to an internal host. This vulnerability has been patched in Next.js version 14.1.1.

Assetnote has published a proof of concept for CVE-2024-34351, providing detailed information about the exploitation, source code, and other relevant information. It is recommended that Next.js users upgrade to the latest versions to prevent these vulnerabilities from being exploited.

Demo: Microsoft Build – Navigating the Depths of API Security Testing

Our newsletter publisher, 42Crunch, the API Security platform vendor, recently appeared on stage at Microsoft Build showcasing the integration of their API Security testing services with the Microsoft Defender for APIs. Microsoft Build is the annual conference event for the community of developers and software engineers to discover the latest innovations in code and applications. Following their recent partnership with 42Crunch, Microsoft Product Managers Haris Sohail and Preetham Naik teamed up with 42Crunch’s own Heshaam Attar to explore how best to navigate the depths of API security testing. The session offered a packed audience insights into various API breaches and also a demo by Heshaam where he showcased the end-to-end use case for both 42Crunch Audit & API Scan. Full recording available here – enjoy!

Article: API growth causing cybersecurity concerns

Next, we have an article on a recent survey commissioned by Fastly, Inc., which found that despite APIs’ critical role in the digital economy, most commercial decision-makers ignore the growing security risk they pose for businesses. 95% of respondents said they had experienced API security problems in the last twelve months, with 84% admitting to not having advanced API security in place. The lack of action is attributed to insufficient budget and a lack of expertise.

The survey also revealed sector-based and regional variations in attitudes towards API security. Heavily regulated sectors dealing with sensitive data, such as financial services, were found to be some of the worst culprits regarding API inaction. The UK was marginally ahead of the pack regarding the importance placed on API security, but there was still a tendency not to translate thoughts into actions. The survey suggests that single-provider security solutions and AI could provide answers to the complexity of the API landscape.

Article: The menace of unknown APIs

The next article summarizes key insights from the recent Imperva State of API Security, which discusses the security risks posed by unknown APIs in modern software development. 

Shadow APIs, which are undocumented or undiscovered APIs operating outside official channels, can pose security risks if exploited by threat actors. According to the report, there are 29 shadow APIs per account. Deprecated API endpoints, specific routes, or URLs within an API marked for removal but still accessible often contain security vulnerabilities. An average of 16 deprecated endpoints per account were found. 

Unauthenticated endpoints, which are API routes that do not require authentication or authorization, can potentially expose sensitive data. Imperva’s API discovery process revealed an average of 21 unauthenticated API endpoints per account. The article stresses the importance of a proactive, comprehensive API security strategy that includes continuous monitoring, risk assessment, and protection of sensitive data to safeguard against the risks posed by these unknown APIs.

We frequently discuss the criticality of unknown or shadow APIs; this article is a timely reminder of their importance to API security.

Guide: Updates to Awesome API security guide

For recent subscribers, it would be good to share a perennial favorite with readers. André Rainho curates a good list of API security resources on GitHub. This list references API security tools, cheat sheets, checklists, conferences, books, deliberately vulnerable APIs, and other design resources. 

I’m happy to see my debut book on Defending APIs included in the list of reading resources. Thanks to André Rainho for maintaining this resource for our community.

The post Issue 247: Dropbox and Dell breaches, vulnerability in Next.js, API growth causing concerns appeared first on API Security News.

Vulnerability: Critical flaw in API portal allows SSRF attacks

This week, we have news of a critical vulnerability in the Perforce Akana Community Manager Developer and API portal. The flaw could enable malicious actors to perform server-side request forgery (SSRF) attacks. 

Community Manager is a sophisticated tool that helps enterprises build an API portal to attract, manage, and support developers who create applications using their APIs. Organizations commonly employ it to develop and maintain developer portals for their APIs.

Server-side request Forgery (SSRF) is a vulnerability that allows an attacker to induce a server-side application to make HTTP requests to an arbitrary domain chosen by the attacker. In an SSRF attack, the attacker abuses functionality on the server to read or update internal resources.

The attacker can request internal services within the organization’s infrastructure that are not intended to be publicly exposed. This can lead to unauthorized access to sensitive data, performing actions on behalf of the server, or even enabling the attacker to execute arbitrary commands.

This critical severity vulnerability (tracked as CVE-2024-2796) has a CVSS base score of 9.3 and was disclosed by Jakob Antonsson. It affects versions 2022.1.3 and earlier.

It is recommended that organizations using the Akana Community Manager Developer Portal update to one of the patched versions immediately.

Article: How to secure GraphQL 

While REST APIs still dominate as the primary API architectural style used in modern digital platforms, GraphQL is becoming increasingly popular due to its query-based approach. This approach allows clients to request specific data through a single endpoint using a flexible query language. GraphQL can be more efficient in data retrieval but may have a steeper learning curve compared to REST. GraphQL also presents some unique security challenges, and our next article covers many of these challenges and the best practices for overcoming them.

GraphQL can be more challenging to secure compared to REST APIs for several reasons:

• Complex queries: GraphQL allows clients to construct complex queries, potentially leading to resource-intensive server operations. Malicious actors might craft queries that cause performance issues or even bring down the server.
• Lack of built-in security: Unlike REST, which can leverage standard HTTP security mechanisms like authentication and authorization on a per-endpoint basis, GraphQL does not have built-in security features. 
• Overfetching and resource exposure: GraphQL’s flexibility allows clients to request any combination of fields, including sensitive data. If not properly secured, clients might be able to access data they shouldn’t have access to, leading to data leaks or unauthorized access.
• Query depth and complexity: GraphQL queries can be deeply nested and complex. Without proper validation and limits, clients might send too deep or complex queries, causing performance issues or even crashing the server.
• Batched queries: GraphQL supports batching multiple queries into a single request. If not handled carefully, this can be exploited to bypass rate limiting or perform denial-of-service attacks.
• Schema introspection: GraphQL allows clients to introspect the schema, which can expose sensitive information about the API’s structure and available data types. 

The authors recommend the following best practices for security engineers:

• Build an inventory of APIs to understand the full attack surface.
• Perform GraphQL API threat modeling.
• Talk with developers to understand their implementations.
• Implement best practices throughout the API lifecycle, including API gateways, secret scanning, testing every API release, and proper security monitoring.

For developers, they recommend the following:

• Limit access using authentication and authorization.
• Input validation.
• Rate limiting to block brute force attacks.
• Depth limiting to avoid DoS-style attacks.
• Schema whitelisting
• Limit the cost of GraphQL queries.

For further reading, we have covered GrahpQL in this newsletter here, here, and here.

Live Broadcast: Navigating the Depths of API Security Testing 

On the back of their API Security partnership announcement last year, experts from 42Crunch and Microsoft take a dive deep into the underbelly of APIs and explore the vulnerabilities in your codebase. Join them in person in Seattle or online at Microsoft Build where they explore scanning OpenAPI specs to dynamic testing, to equip you with practical strategies to harden your APIs against attacks. 

Register online for free

Article: Building bulletproof APIs 

The next article is a well-articulated guide to building bulletproof APIs. By bulletproof, the author means meeting a broader range of non-functional requirements (NFRs) that go beyond pure security to encompass smooth operation, security, and scalability.

The author suggests four core principles for scalable systems, namely:

1. Focusing on Resources: Simplify your API design by treating data as resources with unique identifiers rather than relying on complex methods. 
2. Self-Discoverable APIs: Enable clients to explore and discover available actions and resources within your API by incorporating HATEOAS principles. Include links in API responses that guide clients to related resources and actions. 
3. Managing API Evolution: Implement a well-defined versioning strategy to plan for future changes and enhancements to your API and ensure that updates don’t break existing integrations. 
4. Self-Contained Requests: Design your API in a stateless manner, where each request contains all the necessary information for processing. This means the server doesn’t need to retain any session state between requests. 

To optimize performance and scalability, implement the following:

• Pagination and Filtering: For large result sets, use pagination to allow clients to retrieve data in smaller blocks and use filtering to limit data returned.
• Caching: Use caching mechanisms to store common data on the server side. This significantly reduces backend load and improves client performance.

To ensure reliability and security, implement the following:

• Error Handling and Response Codes: Design a consistent and accurate error-handling approach using standard HTTP response codes.
• Rate Limiting and Throttling: Implement safeguards to limit the rate of API calls to prevent abuse and being overwhelmed by excessive traffic. 

Finally, the author identifies the following vital NFRs that should be addressed in robust systems:

1. Performance
2. Scalability
3. Security
4. Reliability
5. Usability

The article emphasizes that considering NFRs alongside core design principles is crucial for building exceptional APIs. By adhering to these principles, developers can create robust, scalable, and secure APIs that deliver a seamless user experience and provide a solid foundation for future growth.

Guide: Damn Vulnerable RESTaurant 

I am always pleased to see new tools in the API security space, and this week, I am happy to cover a new deliberately vulnerable API application entitled Damn Vulnerable RESTaurant. The project is the brainchild of Krzysztof Pranczk, who describes the goals as follows:

“I wanted to create a generic playground for ethical hackers, developers, and security engineers where they could identify, exploit, or fix vulnerabilities. Furthermore, security engineers could implement new vulns and test their detection tools because the Python FastAPI framework allows quick development,”

The vulnerable API service is designed specifically for educational and training purposes, catering to developers, ethical hackers, and security engineers. The project aims to create an environment that can be easily expanded with new vulnerable endpoints and mechanisms, facilitating hands-on training in detecting and exploiting identified vulnerabilities.

This training playground offers unique opportunities for various professionals:

• Developers: Engage in a dedicated game where you can interactively identify and fix vulnerabilities, enhancing your skills in secure coding practices.
• Ethical Hackers: Put your skills to the test by exploiting vulnerabilities manually or using automated tools. Approach it as a Capture the Flag (CTF) challenge, starting as a low-privileged API user and escalating to a root user. There is one path to achieve this goal, and API documentation is provided to guide your hacking adventure.
• Security Engineers: Utilize a range of security automation tools, such as Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Infrastructure as Code (IaC), to assess and refine vulnerability detection mechanisms.

The project can be found on GitHub and be easily deployed in Docker or directly into GitHub Codespaces.

Thanks to Krzysztof for the exciting project; I look forward to experimenting shortly.

Article: API security and fraud detection must converge

The next article explains why API security and fraud detection should converge to provide optimal protection against emerging threats. These two disciplines have traditionally been treated as separate entities, but the evolving threat landscape demands a more integrated approach.

Bots have revolutionized the fraud landscape, with APIs becoming their primary target. These automated tools enable fraudsters to carry out account takeovers, credential stuffing, and fake account creation by exploiting vulnerabilities in API systems. The article highlights real-world examples of API-centric fraud, such as inventory manipulation and scalping, loyalty and reward program API abuse, and gift card balance fraud.

The article advocates for a converged approach to API security and fraud detection to combat these threats effectively. This involves sharing data and insights between security and fraud teams to gain a more comprehensive understanding of risks. Behavioral bot detection systems that analyze API interactions and device fingerprinting are crucial in unmasking sophisticated bots mimicking legitimate users. 

Silos between fraud and security teams create dangerous blind spots, leaving businesses vulnerable to API-based attacks. Fraud detection often lacks visibility into API-level attacks, while API security tools may overlook fraudulent behavior disguised as legitimate traffic. By integrating fraud detection, API security, and advanced bot protection, organizations can create a more adaptive defense capable of swiftly responding to threats and mitigating vulnerabilities.

In conclusion, a holistic strategy that combines fraud detection and API security is essential for safeguarding data, customers, and reputations in today’s API-centric world.

Article: Using Bruno as an alternative to Postman

Finally, we have news of another potentially exciting tool for API developers and their security teams. Bruno is a new open-source API client with the following goal:

“Bruno is a Fast and Git-Friendly Opensource API client, aimed at revolutionizing the status quo represented by Postman, Insomnia and similar tools out there.”

As one would expect, Dana gives this new tool a thorough walkthrough. In his in-depth review, he highlights several issues he encountered and offers his views on Bruno’s future. In meme form, here’s his conclusion:

Likewise, I am ready for a new API client and will soon take Bruno for a test drive and buy a license to support the project. 

The post Issue 246: Critical flaw in API portal, securing GraphQL, building bulletproof APIs appeared first on API Security News.

Vulnerability: Delinea patches API vulnerability

This week’s first vulnerability comes courtesy of SC Media, who report that Delinea, privileged access management (PAM) provider, confirmed a critical vulnerability in its Delinea Platform and Secret Server Cloud products on April 15, 2024. The vulnerability, identified as a flaw in the SOAP API, could allow attackers to bypass authentication, gain administrative access, and extract sensitive information if left unpatched.

Delinea has addressed the issue by patching the vulnerability in its cloud-based service and providing a remediation guide for its on-premises customers. They stated that they found no evidence of compromised customer data or attempts to exploit the vulnerability.

Security professionals emphasize the importance of immediately updating on-premises installations of Delinea Secret Server Cloud to mitigate the risk of potential network compromises and data breaches. If exploited, the vulnerability could grant attackers significant control over the network, enabling them to move laterally, escalate privileges, deploy malware, and launch ransomware attacks.

The article also highlights API security’s importance, as attackers know that most organizations lack adequate protection for their internal API assets:

“Attackers are well aware that most organizations do not have API security solutions protecting their internal API assets”

Vulnerability: API vulnerability in Palo Alto devices

This week’s second API vulnerability comes courtesy of Security Boulevard, covering a remote code execution (RCE) vulnerability in the Palo Alto PAN-OS devices. The vulnerability potentially allowed attackers to execute commands on the devices, which ultimately could have led to device takeover. The vulnerability (tracked as CVE-2024-3400) has already been addressed by Palo Alto, which recommends that customers immediately update their devices to a version of firmware greater than 10.2. There are no indications that this vulnerability was exploited in the wild.

The exploit itself was surprisingly simple, involving the injection of code into an XML RPC request as shown:

<cmd code="ping">OS command exploit is there</cmd>

This type of attack can be prevented by using well-tuned WAFs, while dedicated API protection solutions offer excellent defenses against injection attacks of this type. 

An interesting side note about this vulnerability was that GitHub responded quickly to remove copies of proof-of-concept and exploit code from their repositories. Despite their efforts, the code spread rapidly in the cybersecurity community. Fortunately, in this case, Palo Alto rapidly released a patch.

Article: How to fix API design

The next article comes via The New Stack and covers API design, why they consider it to be in a poor state, and how this impacts, among other things, API security. The fundamental issue with API design concerns the long lifetime of APIs, which means that poor decisions often exist longer than ideal to maintain backward compatibility and legacy systems. 

Some of the impacts of poor API design include the following:

1. Limited scalability: Poorly designed APIs can hinder a business’s ability to scale effectively, leading to performance issues, slower response times, and downtime during high-traffic periods. Backward compatibility is also a concern, as older clients using outdated API versions can negatively impact overall system performance.
2. Increased costs: Maintaining and managing poorly designed APIs can consume significant resources, leading to increased operational costs. If an API is not designed to scale, it may require substantial resources to fix as the business grows, further impacting the organization’s bottom line.
3. Security risks: Developers often overlook security when designing APIs, focusing more on functionality. This can lead to vulnerabilities, such as buffer overflow attacks, which can be exploited by attackers. If API security vulnerabilities are exploited, it can result in significant financial and reputational damage to the business.

The author then describes five steps in which API design can be improved, namely:

1. Prioritize API design from the start: Focus on designing the API correctly, considering scalability, security, and long-term maintenance. A well-designed API can minimize future costs, reduce security risks, and ensure the API can help the business scale its digital operations.
2. Adopt API design best practices: Use RESTful principles, consistent naming conventions, and API description languages like OpenAPI or RAML. Adhering to the OpenAPI Specification can provide a framework for planning, designing, building, testing, and documenting APIs, reducing the likelihood of design errors and improving overall API quality.
3. Understand and prepare for security risks: Design APIs to handle potential security threats, such as buffer overflow attacks and SQL injection. Validate and sanitize input data, implement rate limiting, and use secure protocols like HTTPS. Implement API security tools to monitor and protect against automated and zero-day attacks.
4. Regularly audit and update APIs: Conduct regular reviews and updates to identify and rectify design issues before they become major problems. Test APIs for performance and security vulnerabilities, gather user feedback, and create new API versions when necessary, following a proper versioning strategy.
5. Plan for API evolution: Design APIs to accommodate future changes and additions without breaking existing functionality. Plan for deprecating old versions, communicating changes to users, providing clear migration paths, and supporting old versions for a reasonable period. Establish a clear deprecation policy and communicate API changes well in advance.

From my perspective, security should be a first-class class citizen in the design process. Too often in this newsletter, there is evidence of vulnerable APIs due to poor design decisions, such as a lack of rate limiting or information leakage. By considering these issues at design time, the API can be designed to be secure at the outset.

Article: Seven ways to better manage risk

In the last two quarters, we have seen a steady increase in the number of leaked API keys and tokens. I would be inclined to say that this is most likely the top threat vector-facing API currently. The team at ReversingLabs has put together a helpful guide on better ways to manage your supply chain risk in the event of credential leakage. The report highlights the magnitude of the problem — GitHub reported a 28% increase in 2023 over the preceding year and also reported a 22% increase in the number of repositories. 

The report lists seven ways to manage risk resulting in leakage, as follows:

1. Swift mitigation is crucial after an exposed secret is discovered.
2. Developers need guidance, not just alerts, to rectify their mistakes effectively.
3. Certain file types, such as .env files, are more likely to leak secrets.
4. Automated detection is necessary but insufficient on its own.
5. DMCA notices can be used to stop leaks but have limitations and risks.
6. AI tools like ChatGPT cannot be relied upon to block leaks effectively.
7. Compromised secrets must always be revoked, as merely hiding the leak is ineffective.

From my own perspective, prevention is always better than cure when it comes to secret leakage. Easy wins can be achieved by using a good secrets manager or vault and by preventing inadvertent long-term storage of credentials (for instance, by preventing them from being committed to GitHub). The other key piece of the puzzle is to detect a leak as early as possible and then have a robust process to revoke and re-issue credentials. 

This is a hard problem to solve, but one I’m optimistic we as an industry will crack.

Article: Will OpenBanking transform the future of finance?

I have recently written about addressing API security regulations in financial services, and our next article discusses how OpenBanking will transform the future of finance. The report focuses on recent growth figures relating to OpenBanking in the UK, where over 11.4 million payments were processed in July. This reflects a 102% year-on-year growth, suggesting an increasingly rapid adoption. The article rightly highlights the concern around the exposure to risk that may result from this growth via the proliferation of open APIs. As the sector shifts to an API-first approach, scaling without a clear security strategy can harm the entire UK financial sector’s progress toward API growth. Many organizations lack full visibility into their existing APIs, which are proliferating faster than DevOps teams can release patches or keep up with their API inventory.

The article recommends that financial institutions implement a proactive API security and governance strategy to ensure the success of open banking. This strategy should be centered around three fundamental building blocks: 

1. API governance for visibility.
2. Improving cross-team collaboration between development and security teams.
3. Taking a multi-layered approach to protect against both external and internal threats.

The authors conclude along similar lines to my own views, namely the need for a multi-layered approach to API security, as a perimeter-only approach is insufficient. This approach should include measures such as multi-factor authentication, enhanced monitoring, privilege management, and application-level controls to identify threats beyond the perimeter.

Guide: Breaking APIs with “naughty strings”

Finally, this week, we conclude in the time-honored manner by featuring Dana Epp’s guide to breaking APIs with “naughty strings.” The article describes an attack technique that uses a large list of strings, which are problematic for APIs with poor input validation. Using such strings can elicit unexpected behaviors from APIs, often resulting in information leakage or injection attacks through access control bypasses. 

Dana covers the following topics in the guide:

• Obtaining a suitably large list of “naughty strings.”
• Using the strings in Postman
• Using the strings to crack a login form in the crAPI application

Thanks to Dana for another top article.

The post Issue 245: Delinea patches API vulnerability, API vulnerability in Palo Alto devices appeared first on API Security News.

Article: Security threats to enterprises in the cloud

In the first article this week, Forbes discusses the various security risks companies face when moving their operations and data to the cloud. While cloud service providers invest in security measures, businesses should avoid assuming their data is fully protected. The article presents insights from 20 members of the Forbes Technology Council on the top security threats and how to address them.

The article identifies several threats, such as image-based phishing, human error, added risks from homeworking, shadow IT, and insider threats, mostly attributed to human error or shortcomings. The most interesting revelation for me was that for the technical threats, most, if not all, impacted APIs. Firstly, API security itself is identified as a threat, namely:

API vulnerabilities present a growing threat. Regularly assess and secure APIs, implement proper authentication mechanisms, and conduct thorough security testing to identify and rectify potential vulnerabilities.

However, many of the ancillary threats impact the security of APIs, namely:

• Misconfiguration: Although not specifically mentioned in the context of APIs, misconfigurations in cloud settings can lead to unauthorized access. Misconfigured APIs can expose sensitive data or allow unauthorized actions to be performed.
• Unsecured Apps and Data in Development: Many cloud platforms also serve as development environments where users can build apps and automation. If these apps and their associated data are not properly secured, it can lead to vulnerabilities. This point implies that unsecured APIs in development environments can pose a risk.
• Vulnerabilities In Third-Party Software: Supply chain attacks can target vulnerabilities in software and infrastructure, and APIs, as they are externally facing and visible, are particularly vulnerable to such attacks.
• Secrets sprawl: API keys, encryption keys, and other secrets are often used to authenticate and authorize access to APIs. If these secrets are not managed securely, it can lead to unauthorized access and data breaches.

This is quite an eye-opening read for anyone operating modern infrastructure. 

Article: API security threats looming

We have another illuminating article on the threats to API security courtesy of Infosecurity Magazine. The article describes many of the findings in a recent Fastly survey of 235 key IT professionals, including the following statistics:

• 79% of surveyed companies place a high importance on API security, as APIs have become crucial assets in multi-cloud environments.
• 95% of respondents experienced API security problems in the last 12 months and 79% delayed application rollouts due to API security concerns.
• However, 84% admitted to not having advanced API security in place, mainly due to insufficient budget and lack of expertise.
• The study suggests that AI-powered cybersecurity systems could help secure APIs on a limited budget, but only 14% currently prioritize using AI for API security.
• However, 58% anticipate that generative AI will significantly impact API security over the next 2-3 years.

As Fastly commented, too many organizations are doing too little to counter the threats posed to their APIs.

Article: Utilities and energy companies a prime target for API threats

Our third article is another thought-provoking read, this time on the impact of API security incidents on the utilities and energy industries. As companies in this sector strive to digitize and modernize their services using APIs, they face challenges such as aging technology stacks, lack of interoperability, and poor security hygiene, which create vulnerabilities and make them prime targets for cyber attacks.

Recent research surveyed over 100 CIOs, CISOs, and CTOs from the energy and utilities sector. The findings revealed that 78% of businesses were affected by API security incidents, and there are no signs of the issue abating. The impact of API security incidents can be substantial for energy and utility companies, including loss of employee goodwill and productivity and potential penalties and fines due to the sector’s highly regulated nature. Over half (57%) of global respondents in the energy and utilities sector have suffered a loss of employee goodwill, while 53% have cited a loss of productivity due to an API security incident.

Energy and utility companies should be increasingly concerned about the prevalence of API-related incidents, given their legacy infrastructure and systems and adversaries’ increased focus on attacking critical infrastructure.

Guide: Generating SDKs for your APIs

One of the biggest challenges for a design-first approach to API development is how to transition from well-designed and validated API contracts to well-formed and valid code in the form of SDKs or API server stubs that honour the API contract. In the real world (and in my experience), this translation is most often performed by hand, but this has obvious disadvantages, including:

• Time-consuming: Even for a relatively simple API, getting a working implementation will require a lot of code to be generated, which will be time-consuming. 
• Wasteful of developer resources: While code generation is time-consuming, it is also wasteful of valuable developer resources that would be better employed to write business functionality.
• Error-prone: Any manual code translation process is going to be prone to errors being introduced.
• Non-repeatable: Different developers will implement the same API definition differently, and this can lead to a very fragmented code base. It would be preferable to use a standard implementation pattern that can be easily understood by the entire team.

Most API developers are probably familiar with Swagger Codegen to perform automated client and server stubs for API contracts. Still, it may come as a surprise that Kristopher Sandoval was able to find at least another nine such tools covered in his excellent piece for Nordic APIs. Although I recently researched this space for my book, I was surprised at how many seemingly capable and powerful tools are available in this space — it bodes well for the future of design-first APIs. 

For my money, I’m a fan of OpenAPI Generator, with its open-source model and strong foundations via its roots in Swagger Codegen. I’ve used it with great success for .Net and Python code, and while it’s not always perfect, it can easily be customized to achieve the desired result.

Thanks to Kristopher for the great contribution.

Guide: crAPIs walkthrough using AI

We have previously shared Edward Lichtner’s views on using AI for API security testing, and this week, we again feature Edward discussing how to use AI to assist in a walkthrough of the crAPI vulnerable application.

I’ve seen quite a few write-ups about crAPI and the ever-popular vAPI vulnerable APIs, but I’m always struck by the diligence that Edward shows in capturing every nuance of detail, and this write-up is a great case in point. If you’re relatively new to API security, this would be my go-to recommendation to start your learning journey. If you’re unfamiliar with Postman or Burp Suite, he makes no prior assumptions about the reader’s ability and shows exactly how to use these as he takes you through all fifteen of the exercises.

Thanks for sharing this fantastic resource, Edward!

Event: “Building a rugged API security program”

I have the great pleasure of speaking at the upcoming APISec Conference on 22nd May 2024, where I will discuss “Building a Rugged API Security Program.” While the API security community is increasingly appreciative of and expert in securing their APIs using authorization and authentication or secure coding, they still face challenges in achieving real change at a program level. 

As a veteran of several large-scale AppSec programs at Fortune 500s and currently engaging with some of the world’s largest organizations, I am well-placed to bring my expertise and experience to the topic of securing APIs at scale. In this 20-minute session, I’ll discuss API security ownership (it’s more complex than you think), common anti-patterns, how to define a strategy, and how to take the first steps toward success. Join me on the 22nd of May.

EVENT: API Security Workshop  “DEFENDING APIs” – New York, May 1, 2024

42Crunch and their partner, EPAM Systems, will run a complimentary API security workshop on May 1 at the EPAM offices on 7th Avenue, New York City.

This 2-hour long workshop “Defending APIs” provides a mix of educational sessions on the latest API threats and vulnerabilities with practical hands-on tutorials and drills using the 42Crunch API Security platform testing and runtime protection tooling.

Topics covered include:

• Introduction to API Security
• API Security Testing
• Securing APIs on GitHub
• API Runtime Protection

Find out more and register

The post Issue 244: Threats to enterprises in the cloud, looming threats to APIs, API SDK generation tools appeared first on API Security News.

Article: The economics of API attacks

First up this week are the thoughts of The New Stack on the economics of API attacks and how developers can stop these attacks. According to the author, APIs have become a prime target for hackers, with 80% of internet traffic flowing through them. Attackers employ an economic model to assess the cost of an attack against the potential returns, which can include data theft, fraud, or the deployment of ransomware. Traditionally, organizations have prioritized securing infrastructure and end-user web applications, inadvertently leaving APIs vulnerable. The rapid pace of development and the shift towards microservices have further emphasized the need for an API-focused security posture.

The report suggests that organizations implement an active, persistent, and consistent discovery and inventory process to map applications and maintain an up-to-date list of APIs, as unmanaged APIs present the highest risk. The author also cautions against the unsafe consumption of third-party APIs and emphasizes the importance of API security across various domains, including mobile, Internet of Things (IoT), and Operational Technology (OT) applications.

Organizations can leverage tools such as API inventory products and API compliance products to identify and assess APIs within their footprint, while API threat detection response solutions can help block API attacks in real time. By investing in comprehensive API security strategies, regular security audits, and continuous employee training, organizations can proactively defend against the ever-evolving landscape of API threats.

Article: API solution wishlist for developers

The second article this weeks comes courtesy of Forbes and features the thoughts of Steve Rodda (CEO of Ambassador Labs) and emphasizes the importance of selecting the right API solutions for modern enterprises, particularly those operating in complex development environments such as those using Kubernetes.

Rodda’s viewpoint is that traditional generic API solutions may not be adequate to meet the unique demands of these environments, as they often have limitations such as poor performance, lack of customization, scalability issues, suboptimal security, limited monitoring and analytics, and reduced flexibility in policy enforcement. According to him, traditional solutions present the following problems to organizations, specifically to development teams:

• Poor performance
• Lack of customization
• Scalability issues
• Suboptimal security
• Limited monitoring and analytics
• Reduced flexibility in policy enforcement

Given these challenges, Rodda suggests adopting specialized API solutions that can provide critical features such as:

• Stronger performance
• High customization
• Advanced security features
• Comprehensive monitoring and analytics
• Flexible policy enforcement

However, before making the shift to developer-first solutions, Rodda advises considering potential challenges. These include integration issues with existing technology stacks, the need for thorough security assessments, and conducting a detailed cost analysis. It’s crucial to involve all relevant stakeholders in the decision-making process, including developer team leads, CTOs, product managers, support heads, technical writers, and business representatives.

A very interesting read, and I’d strongly recommend curious readers to explore the likes of Ambassador Labs, Solo.io, and Traefik Labs to see the state of the art in API management platforms.

Article: Understanding CORS 

In my recent experience of writing a book on API security, I found that one of the least well-understood concepts around API (and web) security is cross-origin resource sharing (CORS). I’m pleased to be able to include this well-written guide to this seemingly challenging topic.

Simply put, CORS is a security mechanism that regulates communication between different websites and APIs. To understand how CORS works, let us consider a typical flow:

1. Before any API call to a server, the browser sends a preflight request to check if the requesting website is allowed to access the server’s resources.
2. The server responds with CORS headers, which act as permission slips, specifying the allowed origins, methods, headers, and credentials.
3. CORS configuration is done on the server side, where developers specify the allowed origins, methods, headers, and credentials.
4. Postman, a standalone API client, does not enforce CORS policies, allowing requests to any server without considering the CORS policy.
5. Web browsers strictly enforce CORS policies to prevent unauthorized access to sensitive resources.

In conclusion, CORS errors mostly occur in browsers when one domain tries to access resources from another domain. CORS plays a crucial role in ensuring secure communication between websites and APIs while preventing unauthorized access to sensitive data. CORS is one of those security configurations that should be simple to implement, but often trips up organizations — make sure you test your CORS regular as part of your testing regime.

Article: Securing APIs to block compromised tokens

One of my predictions for 2024 was that API token leakage or theft would continue to proliferate, and there has been no shortage of high-profile incidents in 2024 already. The next article from Security Boulevard discusses four different approaches for dealing with compromised tokens.

Government bodies are clamping down heavily on institutions that handle sensitive customer data. Tokens are used to authenticate users for APIs. Companies with 10,000+ employees have at least 250 APIs actively deployed, and this number is set to increase by 100% by the end of 2027.

The author recommends the following approaches:

• Token Revocation Lists (TRLs) are central repositories of invalid tokens and are used to deny access to compromised tokens. They require diligent management and careful consideration to avoid operational burdens.
• Token blacklisting involves a mechanism where compromised tokens are blacklisted within an authentication system or server and prevent further usage.
• Token Expiration and Renewal: For organizations with limited IT resources, setting expiration dates for critical tokens is recommended. This forces users to periodically renew tokens to maintain access, preventing unauthorized control.
• Token-based Access Control: Token-based access control systems enhance security by adding a layer of protection beyond token validation. Users are authenticated and issued new tokens granting ecosystem-wide access, which can be easily revoked to prevent misuse.

This is not an easy problem to solve at scale, but this is certainly a good starting point.

Article: Using Nuclei any good for API hacking?

In the first of two articles from Dana Epp, he looks at using Nuclei for API hacking. For the unaware, Nuclei is a cutting-edge, template-based vulnerability scanner widely used by bug bounty hunters to scan for low-hanging vulnerabilities. 

Dana highlights four ways in which Nuclei can aid in API security testing:

• Detecting technology in use: Nuclei has templates that can detect the web server delivering content, the programming language being used, and even the type of WAF in place.
• Finding secondary apps that might provide a foothold: Nuclei can help locate common login pages, admin panels, and portals, which can be valuable for gaining access to API artifacts and conducting reverse engineering and taint analysis.
• Advanced app detection: The author suggests using Nmap to scan all responding ports on a target, creating a targets.txt file, and then running Nuclei with the -silent switch to efficiently detect exposed secondary apps.
• Testing leaked API tokens: When potentially leaked API keys are discovered during recon or reverse engineering, Nuclei’s token-spray templates can help determine the service the key belongs to and whether it is valid.

Dana also describes how to integrate Nuclei with Burp Suite … of course. Dan’s conclusion is that Nucei is potentially a useful tool in the armoury of offensive teams.

Article: Five more Burp extensions for API hacking

In the final article this week, Dana features five more Burp Suite extensions that he recommends for API hacking. The extensions are as follows:

1. JS Miner: Automatically scans for hardcoded secrets, credentials, and subdomains and can reconstruct source code from JavaScript Source Map Files. This allows for source code-level access to the front end, enabling the use of code analysis tools to detect potentially dangerous functions.
2. GAP: Helps find potential endpoints and parameters through the web app’s JavaScript, and can generate a custom target wordlist based on the collected data. It can also detect suspect parameters and map them to vulnerability classes.
3. VPS Proxy: Allows for the automatic creation and deletion of an upstream SOCKS5 proxy on popular cloud services, masking the actual testing host’s IP address from the target. This is useful for preventing blacklisting by WAFs during penetration testing and bug bounty hunting.
4. Bypass WAF: Designed to trick WAF devices into believing a request is from itself by adding specific headers, modifying the Host Header, performing HTTP Parameter Pollution attacks, and changing the encoding to bypass the WAF in use.
5. Nuclei Burp Integration: Integrates the Nuclei vulnerability scanner into Burp Suite, automatically pushing detected findings into the Issues panel in the Burp Suite dashboard. This extension allows for tailored scans and easy review of logs within the Burp environment.

Another one for the offensive teams out there. Thanks again, Dana.

The post Issue 243: Economics of API attacks, understanding CORS, blocking compromised API tokens appeared first on API Security News.

Article: API governance to avoid technology sprawl

The first article this week is an excellent piece from Bill Doerrfeld on how API governance is essential to avoid technology sprawl. The article canvasses the views of several industry thought leaders on the proliferation of APIs and how these need to be governed to prevent an unmanageable sprawl of technology, which in turn leads to greater risk to organizations and consumers.

APIs are essential for modern software architectures because they enable data and business services to be integrated across platforms, including mobile and desktop applications. API-first approaches are becoming increasingly popular, providing advantages such as abstraction, automation, and governance. Coupled with this is the fact that new next-generation platforms (LLM-based services or no/low-code platforms) are highly reliant on APIs as their connecting fiber. 

To make things even worse from a governance viewpoint is the fact that API ubiquity presents IT management challenges such as inconsistent design patterns, communication silos, access control, documentation hurdles, and monitoring, performance, and scalability concerns. Additionally, businesses must consider the value proposition, target user, business objectives, and marketing/monetization of APIs.

Gartner’s Mark O’Neill feels that consistency is key to governance:

“When good API governance is in place, consistent design means all your organization’s APIs look like they were defined by the same team, even if many teams were involved,”

Successful API governance initiatives should improve design, provide visibility, future-proof IT strategy, and streamline workflows.

The importance of good API governance includes the following:

• Guardrails bring CIOs peace of mind
• Helping to attain business objectives
• Governance guides more confident usage

API governance is critical for a successful API strategy; unfortunately, it is often hard to achieve in practice.

Article: API security in the age of digital transformation

The next article from Business Daily Africa highlights the growing importance of API security in the age of digital transformation, particularly in the financial services sector. As companies increasingly adopt APIs to facilitate communication between applications, the risk of cyberattacks targeting these APIs also rises.

Hackers are attracted to APIs due to the valuable data and functionality they provide, lack of proper security measures, integration complexity, third-party risks, and skills gaps. To address these challenges, the authors emphasize the need for cooperation between cybersecurity teams and software developers to defend APIs effectively.

To ensure API security, reliability, and successful integration, the authors recommend several strategies:

• Implementing strong authentication and authorization mechanisms
• Designing secure APIs and coding standards
• Comprehensive logging and monitoring to identify and respond to security incidents
• Conducting regular security assessments and penetration testing
• Developing incident response plans and disaster recovery mechanisms

By adopting these strategies, companies can mitigate potential risks associated with APIs, provide a reliable experience for users and developers, and ensure business continuity in the face of potential security breaches or disruptions.

Article: APIs are the new battleground for security

Pulling the first two articles together nicely, we have our third article describing why APIs are the new battleground for security. The authors highlight the concerns around API sprawl as a major challenge, with organizations losing track of their APIs and facing difficulties in managing and securing them effectively.

Since APIs provide access to sensitive data and may have vulnerabilities, APIs are becoming increasingly appealing to attackers because of their access to sensitive data and potential vulnerabilities. The lack of standardization in APIs makes it challenging to develop a comprehensive security strategy for them.

The authors highlight best practices for API security, such as:

• Implementing authentication and authorization mechanisms
• Using rate limiting to protect against brute force and DDoS attacks
• Validating input parameters to prevent injection attacks and other vulnerabilities
• Encrypting sensitive data and securing communication with SSL/TLS
• Monitoring and logging API usage to detect and respond to security incidents
• Conducting regular security testing to identify vulnerabilities
• Following secure coding practices during API development

Perhaps most important is the need for a comprehensive API architecture and management framework, including central management tools and the use of API gateways for security checks and monitoring.

Article: Using AI to find API bugs

Previously, we have featured Dana Epp’s thoughts on using Postman’s new AI feature called Postbot to test or attack APIs, and this week we have Edward Lichtner’s views on the same topic. As a recap: Postbot is an AI prompt within Postman that allows for the automated generation of test scripts with Postman. Combining this feature with Postman’s collection runner capabilities provides a very powerful API testing platform.

The author describes some typical scenarios that can be automated, including:

• Scanning for endpoints that include a JWT in the authorization header and a URL parameter, which could lead to broken object-level authorization (BOLA) vulnerabilities.
• Searching for endpoints that return strings formatted as emails or UUIDs in the response body, potentially exposing other users’ information.
• Identifying endpoints with CORS misconfigurations by looking for the “Access-Control-Allow-Origin: *” header.
• Looking for email addresses in the response body.
• Fuzzing an endpoint by looping through numbers 1 to 15 and polluting the “report_id” parameter to identify BOLA vulnerabilities.

The are some limitations of Postman’s free plan, and the author suggests alternatives like ChatGPT, Hacking APIs GPT, and SecGPT for generating test scripts when the Postbot call limit is reached.

Article: How AI will enable APIs

Sticking to the topic of AI, the next article from Nordic APIs takes a forward-looking view of the possibilities of using AI and APIs together. 

As the previous article showcases so effectively, AI can easily be used to improve the API development lifecycle itself, including:

• AI algorithms can automatically generate client-side code that consumes APIs and server-side code that exposes APIs.
• AI can be used to improve the layout of API resources, align APIs with industry best practices, and create APIs that are more tailored to specific use cases.
• AI can prevent data breaches by analyzing API traffic and identifying malicious communication patterns. Several existing tools already use AI for API security.

The authors then take a fascinating look at the art of the possible, where AI and APIs combine to create a world where applications are intelligent, personalized, and adaptive. According to them, this will happen in phases of enablement, as follows:

• With APIs, applications can self-integrate, eliminating the need for human intervention.
• The APIs will enable autonomous applications to navigate and adapt to their environments.
• Autonomous business integration depends on APIs for evaluating, entering, and fulfilling contracts.
• The pinnacle of AI interfaces is that they are capable of understanding a user’s input and choosing the appropriate API to complete the task, and the future holds exciting possibilities.

The convergence of AI and APIs holds immense potential to make applications more intelligent, adaptive, and efficient, though it also comes with strategic implications for technology providers to navigate. The two technologies have a bright future together.

Guide: Using JS Miner to detect API endpoints

Finally, let us conclude this week with Dana Epp discussing how to use JS Miner to detect API endpoints. JS Miner is a free Burp Suite Professional extension that finds interesting stuff inside static files like JavaScript and JSON, and it provides the following features:

• It automatically scans for hard-coded secrets and credentials.
• It passively scans for subdomains the web app calls and pulls code and data from.
• It can actively try to construct source code from JavaScript Source Map Files (if found).
• It passively tries to detect API endpoints that use GET/POST/PUT/DELETE/PATCH.

Dana shows how to use JS Miner using the following steps:

1. Walk the app to download all static content.
2. Let JS Miner scan passively to orient yourself with the app.
3. Force JS Miner to run an active scan.
4. Check for any JS Source Mapper results to discover any .map files.
5. Explore the code and extract routes and endpoints.

Although this plugin requires the Professional edition of Burp Suite, it looks like an extremely powerful tool to be able to reverse engineer APIs from their web front end. Thanks to Dana for another great read.

The post Issue 242: API governance to avoid tech sprawl, API security in digital transformation, AI for APIs appeared first on API Security News.

Vulnerability: Two critical flaws in Fortinet FortiSIEM product

This week’s main news is the further coverage of the two critical issues reported in the Fortinet FortiSIEM product courtesy of The Register. The two vulnerabilities (tracked as CVE-2024-23108 and CVE-2024-23109) were rated as critical with a CVSS score of 10, indicating that the exploits can be carried out remotely by unauthenticated attackers and are low in complexity. 

According to The Register, there was some confusion about whether these were two new vulnerabilities or whether they referred to previously identified vulnerabilities. Current consensus suggests that these are two new vulnerabilities that have yet to be patched or remediated by Fortinet. The guidance from Fortinet is to upgrade to version 7.1.2 immediately, as this version is not believed to be vulnerable. Fortunately, there do not appear to be any available exploits in the public domain.

The advisory suggests that the vulnerability is related to an API endpoint susceptible to specially crafted payloads manifesting in OS command injections (CWE-78). Although no longer in the OWASP API Security Top 10, injection attacks are still highly prominent and often lead to high-severity vulnerabilities (such as this example.)

Article: How to make public APIs private

DevOps.com featured a very interesting article on how to make public APIs private, which will pique readers’ interest. The author highlights a problem we are only well too aware of — APIs are by their nature most commonly publicly accessible, making them easy to attack. Coupled with this are the generally poor levels of protection offered by so-called ‘Day 2’ solutions such as WAFs, IDS, etc. These are usually not suited to zero attacks leveraged against APIs. 

The author proposes a novel solution using a zero-trust overlay network. The concept is simple and comprises three components:

• The existing API clients are redirected to the overlay network rather than directly to the API
• A zero-trust overlay network
• API servers on a private network segment

The overlay network provides several core security features, namely:

• Eliminating public access: clients connect to the overlay network rather than directly to the API servers.
• Identity, authentication, authorization, and mutual TLS: the overlay network becomes the enforcement point for critical security primitives. Developers only have to add a few lines of code to access the overlay network securely.
• Outbound-only: The API server does not accept input connections but instead makes outbound connections to the overlay network to accept requests.
• Ease of management: the overlay network is a software-only solution allowing central management. 

The article describes the proof of concept using the Open Ziti zero-trust networking solution, which looks like a very interesting project in its own right. 

The approach described contains some promising ideas, particularly the reduction of API servers’ attack surface and the integration of many core API security-critical components (authentication, authorization, mTLS) into the fabric. 

Article: Developing an API security strategy

HelpNet Security is next with its views on the importance of an API security strategy. The author cites the recent Cloudflare report, which suggested that 57% of internet traffic is now API-related. More concerning is that 60% of organizations have experienced at least one breach in the last two years. 

The author suggests that an API strategy is essential for countering the threats posed to APIs, including DDoS, brute force, code injection, and man-in-the-middle attacks. They recommend starting with the OWASP API Security Top 10 to understand the threats and then adopting something like the NIST Cybersecurity Framework to identify a strategy.

Their recommendations include focusing on the following:

• Hardening authentication and authorization implementations
• Using SSL/TLS everywhere
• Implementing zero-trust access controls
• Perform regular security tests and assessments
• Frequent updates and patching of vulnerabilities
• Continuous monitoring and alerting
• Using API gateways 
• Using a WAF or API protection solution

To this, I emphasize the importance of a shift-left approach to API security, which focuses on a developer-led approach to secure API development.

Guide: Endpoints versus routes

Dana Epp returns to the newsletter this week with his thoughts on the difference between an endpoint and a route. From my perspective, these terms are used somewhat interchangeably in our industry, yet—as Dana points out—there are quite distinct differences that are worth exploring. 

An endpoint is a specific URL/URI that a client application can access. It is a unique location in the network namespace. For example,

https://api.example.com/reader  and https://api.example.com/subscribers are two distinct endpoints.

An API route further distinguishes itself from the endpoint by introducing the HTTP operation in question (such as GET, POST, PUT, DELETE). For example, a single endpoint can have a route that responds to the GET operation (reading a value) and the POST operation (writing a value). 

This distinction is important because the code implementation in the backend might be distinct for different routes and behave quite differently. It is essential that all routes are tested individually and that one does not rely on only one endpoint test. A common anti-pattern is that routes are implemented slightly differently. A good case in point is a DELETE operation that does not validate if the caller has permission to actually delete the object. 

Or, more simply put in meme form:

Guide: Django API security best practices

Finally, we have a guide on how to secure Django-based API implementations. Django is a popular Python framework used for web applications and API servers. Fortunately, Django is considered a secure framework with sensible, secure defaults and built-in security primitives.

The guide features a range of popular third-party libraries providing support for the following:

• User registration, authentication, and password management
• Content Security Policy (CSP) to counter XSS attacks
• Rate-limiting protections
• Fine-grained access controls to data
• Transparent encryption

The guide gives guidance on advanced topics, including:

• Authentication, including MFA and social media authentication
• Authorization, including RBAC and group-based authorization
• Input validation and output encoding
• Secure configuration

Django is a good choice for Python-based APIs, and this guide is a great place to start when it comes to securing them.

API Security Workshop: Austin Mar 11, 2024

Join 42Crunch next week at the Austin API Summit for a dedicated API Security workshop.

Workshop Leaders

Topics covered include:

• The context for API security (the need, the differences, the opportunities)
• Understanding the OWASP API Security Top 10 vulnerabilities
• Overview of several recent high-profile API breaches
• Building secure APIs by design
• Developing secure APIs
• Protecting APIs

25% Discount Code: 42crunchworkshop

The post Issue 241: Two critical flaws in FortiSIEM product, making public APIs private, API security strategy appeared first on API Security News.

Vulnerability: Vulnerabilities in Spoutible API

The first vulnerability this week comes to us from the founder of Have I Been Pwned, Troy Hunt, and features several significant vulnerabilities in the API of the new Spoutible social media platform. In Troy’s own words, “No way! No way!” — this is almost a case study on how not to implement an API. Let’s dig in — fasten your seatbelts.

The Spoutible API offers a standard service endpoint allowing a user to retrieve basic account information; in Troy’s case, this is:

https://spoutible.com/sptbl_system_api/main/user_profile_box?username=troyhunt

As expected, this endpoint returned some basic metadata such as name, id, and profile. Troy also noticed that it returned several PII fields, including email and phone numbers. Given that this endpoint took a username as a parameter, it meant that an attacker could scrape the emails and phone numbers of any user at will.

Whilst that’s already a significant issue, it gets much worse. He noticed that it also returned the Bcrypt password hash — no way, I hear you say. He verified that the hash did match his (deliberately weak) password. Whilst not quite as bad as exposing the password directly, this is the next best thing. Bcrypt is vulnerable when used to hash weak passwords, and since Spoutible allowed passwords as short as six characters, it was possible many user passwords were susceptible to being cracked. One can only speculate as to why the API developer felt that returning the Bcrypt hash was a good idea or even remotely useful to anyone other than a hacker. 

He then discovered that the API returned several 2FA values, including the secret (which would allow the regeneration of a new valid 2FA code) and a Bcrypt hash of the backup code. Since the code was only six digits, this was easy to reverse engineer using a Bcrypt cracker. Incredibly, there is one more little “No way” moment. He also discovered a value called em_code, which turned out to be the validation code when resetting a password via email. The API was literally providing the information necessary to perform an account takeover. 

Troy reached out to the founder (ironically on Twitter) to alert him of these vulnerabilities, and within four hours, the API had been redacted to eliminate these sensitive fields. The founder released a public statement detailing the incident, which is available here. 

This is a rather epic example of API 03:2019 — Excessive data exposure. The obvious advice is to ensure that your API never returns any sensitive or security-related information. 

Breach: 15 million user profiles scraped from Trello

The other big news this week is the leakage of PII (usernames and emails) from the Atlassian-owned Trello platform. The breach is believed to have affected over 15 million users and potentially opened up opportunities for spear phishing attacks. Atlassian committed to improving its API security but stressed that no other user profile data was divulged. 

An attacker discovered that they could abuse an API that allowed for the sharing of Trello boards by submitting a target user’s email address. The API would then return a list of all boards associated with that email, which allowed them to associate usernames with the corresponding emails. Trello has since moved to restrict access to this API, and it can no longer be used to query arbitrary user profiles. Atlassian also intimated that all impacted emails had previously featured in breaches and thus were already in the public domain. Troy Hunt’s own research seemed to indicate this was the case based on Have I Been Pwned data extracts.

If you are a Trello user, I would suggest checking if you (like I was!) are on the list. 

The lesson here is to be wary of public, unauthenticated APIs that allow the enumeration of parameters, as they can easily be weaponized against you.

Vulnerability: Over 18,000 API secret tokens leaked

The next article features the findings of the Escape Tech security research team on the prevalence of leaked API secret tokens. By analyzing over 189 million URLs, they found over 18,000 exposed API secrets, of which 41% were deemed to be highly critical, leading to financial risk to organizations. 

The article describes the methodology used in the research, and the details will appeal to the technically minded. In determining the URLs to parse, they picked a set of popular domains and spidered out from the domain roots. They avoided parsing any government, educational, and health-related domains. The researchers acknowledge that their dataset is relatively small and may not be entirely representative.  

The statistics are impressive — over 189 million URLs were scraped in 69 hours with 150 concurrent processes. The whole scanning engine was built by a single engineer in three days. Once the data was collected, it was sanitized using pattern matching and custom heuristics. Upon discovering a potential positive finding, the team reached out to the owner to alert them. The researchers emphasized the importance of reducing false positives to prevent unnecessary panic. 

This is an illuminating piece of research and adds weight to many expert opinions that token leakage is emerging as a top threat to API security.

Vulnerability: API leakage reveals Office 365 account details

Our final vulnerability this week features some excellent research from Eaton Zveare detailing his work in identifying a vulnerable API that allowed access to an Office 365 account (and, with it, 650,000 sensitive emails). 

The researcher discovered that the Toyota Tsusho Insurance Broker India (TTIBI) provided a mobile application for calculating car insurance premiums. By analyzing the application behavior, he determined that the client sent an API request to the server to send an email using a standard “no-reply” service account email. Seeing that the API call used Bearer Authorization, he assumed that attempts to subvert this API would be unsuccessful without a token. To his surprise, he discovered that the API responded with a success status and also an email sending log. In the log, he found a Base64-encoded password for the associated email account. No way, I hear you say.

Using this password and the email address, he could use the Office 365 portal to access the email account and the 650,000 emails in the mail folders. Six months after his disclosure to TTIBI, the password had still not been changed, and he could still access the account. 

This is a great example of two OWASP Top 10 API security blunders that are often associated with one another — API 02:2023 — Broken authentication and API 03:2019 — Excessive data exposure. 

Guide: Securing APIs with Spring Boot

The Spring Boot Java-based framework is among the most popular for implementing APIs, and this guide provides details on how to implement basic authentication. Although basic authentication is not a preferred mechanism for API authentication, this guide illustrates many of the important techniques to enable authentication mechanisms on Spring Boot. 

The steps are relatively simple and include: 

• Adding a custom controller that provides the endpoint to be secured.
• Add a Basic Auth configuration class.
• Add a filter, password encoder, and authentication endpoint.

If you are new to Spring Boot, this tutorial is an excellent starting point to learn the basics of authentication.

Article: Protecting APIs from BOLA, BOPLA and BFLA

Earlier this month, 42Crunch hosted Philippe de Ryck in a popular webinar on the top things you need to know about API security. To accompany this webinar, they have published a blog post that provides nuggets from the discussion around protecting against the following pervasive API threats:

• Broken Object Level Authorization (BOLA)
• Broken Object Property Level Authorization (BOPLA)
• Broken Function Level Authorization (BFLA)

As ever, Philippe’s advice is worth heeding when it comes to securing your APIs.

The post Issue 240: Spoutible API leakage, 15M Trello profiles scraped, API secret tokens leaked appeared first on API Security News.

Breach: Hugging Face AI platform exposes API tokens

This week’s main news is recent research indicating large-scale leakage of API tokens on the popular Hugging Face AI portal. 

Hugging Face hosts over 500,000 AI models and 250,000 datasets for developers working on LLMs and Generative AI projects and can be thought of as the GitHub for AI developers. The platform provides an API and Python library to enable developers to access their models and data. Security researchers at Lasso Security discovered that this API opened three potential AI security vulnerabilities (see the newly released OWASP Top 10 for LLM Applications), namely:

1. Supply Chain Vulnerabilities: the large-language model (LLM) application lifecycle can be compromised by vulnerable components or services in the same way applications are vulnerable to supply chain attacks. 
2. Training Data Poisoning: training data can be tampered with, resulting in vulnerabilities or biases that compromise security, behavior, or biases.
3. Model Theft: Models represent potentially valuable intellectual property and can be the target of theft via exfiltration.

The researchers used fairly basic methods to exfiltrate API keys from both GitHub and the Hugging Face platform. Both offer a search capability and by using a suitable regular expression term, they could identify API keys in public repositories. In their research, they discovered a total of 1,681 valid tokens, including high-value organizations such as Meta, Microsoft, Google, and Vmware. The keys had sufficient access rights to access Meta-Llama, Bloom, Pythia, and HuggingFace repositories fully.

The following recommendations will minimize the likelihood of similar vulnerabilities in the future:

• Do not store login information in public repositories 
• Use multiple API keys and rotate them 
• Be aware of third-party API usage
• AI tools need to handle data securely
• AI providers need to create trust in APIs and more

The other obvious recommendation is to ensure regular scans are run against repositories such as GitHub and Hugging Face to detect accidentally exposed tokens as early as possible, ideally before any adversary finds them.

Vulnerability: SonicWall firewall RCE vulnerability

The second vulnerability this week comes courtesy of research from Bishop Fox, who discovered a pair of vulnerabilities in the API of SonicWall’s next-generation firewall 6 and 7 families of devices. The first, tracked as CVE-2022-22274, was disclosed in March 2022, while the second, CVE-2023-0656, was revealed in March 2023. 

For the technically minded, the research report from Bishop Fox makes an interesting read. It covers the initial vulnerability analysis, the development of a proof-of-concept exploit, and live scans to identify affected systems. The root cause was – as is so often the case – a buffer overflow vulnerability relating to their use of the __snprintf_chk() function. Their proof of concept exploit shows how an attacker could use this vulnerability to execute code capable of crashing the device – perfect for a denial of service attack against a firewall. 

The researchers did note that the likelihood of an exploit in the real world was likely to be low since very specific combinations of hardware and firmware versions were necessary as preconditions for the exploit. The researchers also published a script on GitHub that allowed firewall users to determine if they were vulnerable to the exploit.

Their advice was to ensure that the web management interface (hosting the vulnerable endpoint) was either disabled or removed from the public network. Simultaneously, users of SonicWall firewalls are urged to upgrade to the latest firmware.

Article: API security checklist

API security best practices and checklists are always popular with readers, and this week, we have a good checklist courtesy of pentest provider Astra. Their list of nine items includes the following:

1. Use API keys and/or common authentication: Avoid username/password authentication on APIs under all circumstances since these are easily bypassed and are difficult to change.
2. Enforce transport layer security: Ensure that API data is encrypted in transit, both internally and externally, using TLS.
3. Add rate limits to APIs: Prevent abuse and misuse of your APIs by enforcing rate limiting on all endpoints, including those involving an account reset process.
4. Mitigate any exposure of data: Avoid exfiltrating excessive data. Instead, limit data to the minimum data required for the business function of the API.
5. Implement zero-trust security: Assume all APIs will be accessible regardless of perimeter and explicitly enforce authentication and authorization for all APIs.
6. Validate all user input for APIs: Never trust user-supplied input since this can be manipulated to leverage injection attacks or mass assignment vulnerabilities. 
7. Encode all output from the API: If the API output is being rendered directly (such as to a web page), ensure that output is encoded appropriately to prevent cross-site scripting attacks.
8. Conduct regular API vulnerability scans: Run automated scans against API endpoints to identify common vulnerabilities. 
9. Carry out API penetration testing: Use API penetration testing providers who have the specialist skills necessary to identify API vulnerabilities. 

This is a useful checklist to run against your APIs; thanks to the team at Astra for contributing.

Article: Choosing an API gateway for Kubernetes

Next, we have a guide from The New Stack on selecting the most suitable API gateway for your Kubernetes installations. Although focused on the capabilities of Ambassador’s Edge Stack, the guide gives useful selection criteria and guidance for selecting a solution.

If you are selecting a Kubernetes API gateway, you should look for Kubernetes-centric integrations; security and scalability; and operational ease, monitoring, and high performance. Whilst more conventional standalone gateways can be utilized in a Kubernetes environment, tighter integrations provide a better experience and greater functionality.

Deeper Kubernetes integration covers the following:

• Service discovery and dynamic routing: the gateway should automatically identify and interact with Kubernetes services.
• Native Kubernetes resource utilization: Leverage pods and ingress to achieve tight integration.
• Real-time responsiveness: Dynamically scale to cluster changes and adapt to changing environments.

For scalability and enhanced security, consider the following aspects:

• Elastic scalability: the gateway should be able to respond dynamically to traffic spikes and low-traffic periods.
• Load distribution: distribute workload across multiple environments and regions.
• Advanced security controls: leverage powerful authentication methods, SSL/TLS management, and rate limiting. 
• DDoS mitigation.

Finally, for operational ease and performance, consider the following aspects:

• Intuitive user interface.
• Declarative configuration: since Kubernetes is typically configured declaratively, it makes sense that the gateway should support the same. 
• Traffic insights: Provide granular traffic data and logs.
• Performance: Low latency is required for optimal user experience and scalable access. 

There are some specific requirements for APIs, including:

• Diverse protocol handling: it may be advantageous to have a gateway that can convert between protocols such as REST, WebSockets, and gRPC.
• SSL termination and encryption management: centrally manage certificates for ease of use.
• API publishing and documentation: provide a central location for API documentation and available API inventory.
• Service mesh integration.
• Automation and CI/CD integration: Improves integration into existing DevOps processes.

An API gateway is an essential element in your API security armory; keep this guide in mind if you use Kubernetes.

Guide: Securing APIs built with Express

For readers with a development perspective, this guide on how to build secure APIs with the Express framework. Express is the most common web framework for Node.js based applications. 

The guide covers a broad spectrum of topics, including:

• Input validation
• Output encoding
• CSRF protection
• SQL injection prevention
• Role-based access control (RBAC) using middleware
• Multi-factor authentication
• Password encryption and hashing
• Secure token-based authentication
• Secure password reset process
• Activity logging and monitoring
• Rate-limiting 

This is a good guide to hands-on security using Express –  worth bookmarking if you are an Express developer.

Guide: Dana Epp on rate limiting and NoSQL injection

Finally, we feature two more guides from Dana Epp. The first covers API rate limit testing, and the second covers bypassing API authentication using NoSQL injection.

The guide on bypassing API authentication bypassing using NoSQL injection was a fascinating read for me – like many; I perhaps had not fully appreciated the risks of injection attacks against NoSQL databases. As Dana’s guide shows, a skilled attacker can easily bypass authentication, shown here in meme form:

We have seen several mentions of rate limiting in this week’s edition, and the article from Dana gives an attacker’s perspective on how to test rate-limiting implementations to prevent outages to services. Be sure to test your rate limits to ensure they behave as you expect.

Event: 42Crunch at API Summit in Austin

The Austin API Summit 2024 is approaching fast! Don’t miss your chance to join us on March 12-13th in Austin, TX – to meet industry colleagues, get inspired, and gather knowledge about the technology, trends and best practices shaping today’s API economy.

The event includes a fantastic lineup of speakers who will discuss many different aspects and best practices of API design, security, documentation, management, and more.

To get a 15% discount please use the following coupon code “sponsor15”.

The post Issue 239: Hugging Face API token breach, SonicWall firewalls exploit, Kubernetes API gateway guide appeared first on API Security News.

Article: Attackers are using APIs to target your business

his week’s first article is Forbes coverage on how attackers are using APIs to target businesses. The article cites the findings of the US Securities and Exchange Commission (SEC) into a major breach at a US telecommunications company where the PII of over 37 million user accounts was leaked in a breach. The root cause was found to be an attacker using an API to exfiltrate the data from their systems. The article also reminds us of the accuracy of the 2023 Gartner prediction, forecasting that APIs would become the top attack vector for cybercriminals. Despite improvements made with endpoint and identity security solutions, criminals increasingly find APIs offering an initial foothold. 

The Forbes analysis echoes my predictions for API security in 2024. Firstly, key theft (or key leakage) will become the top attack vector attackers use. Secondly, organizations will face challenges in determining the extent of data breaches when they occur. Customers will increasingly turn to third-party monitoring services to identify when their data has been leaked.

The article concludes with the recommendation that organizations pay careful attention to the security of their API keys, monitor the dark web for leakage, and then revoke and reissue compromised keys before they can be used in attacks.

Article: The role of cloud-native for APIs

Next, we have some top market research from Bill Doerrfeld over at NordicAPIs on the role of cloud-native in APIs. The article focuses on how the continued adoption of both API-first strategies and cloud-native architectures is changing the face of API management solutions. Bill’s research comes from interviews with various industry leaders at KubeCon 2023.

Most experts agree that we are moving from a model for standalone API gateways or management portals (such as the very popular NGINX) toward an architecture where the API management is incorporated directly into the Kubernetes fabric and controlled and configured as part of the deployment. Kong is cited as a product that originated as a standalone product to a solution that can be deployed directly in Kubernetes as an ingress controller. 

Idit Levine (founder and CEO of Solo.io) suggests that the main drivers towards this tighter integration are the need for greater ease of use and responsiveness to changing needs and requirements. Using technologies such as Envoy Proxy makes them much easier to combine with containerized deployments. Dave Sudia (director of Developer Relations at Ambassador Labs) suggests that the main drivers are enablement and speed, using the rise of GitOps as a modern way of operating where infrastructure can be deployed via code. 

Service mesh continues to promise a lot in terms of tightly coupled API security, but the experts suggest this will mainly dominate for east-west traffic (internal between services) rather than north-south, where the API management portals and gateways will still play a crucial role. 

The topic of how API management, cloud-native, and backstage intersect raised some interesting points. Most importantly, how are they to be managed? As API adoption and rollout grows, organizations will need catalogs or so-called API portals. Opinion is divided but the general consensus is that GUI-based management portals will always be necessary and are unlikely ever to be replaced by a GitOps approach. Levine suggested that platforms such as Backstage can be integrated with cloud-native tools such as Solo.io to provide this capability.

Finally, Bill covers the GA release of the Kubernetes Gateway API, which provides an interface for networking in Kubernetes and controls HTTP routing into clusters. While many cloud-native providers have already written integrations into Kubernetes, this new API provides a standardized way of controlling ingress traffic and routing.

 Thanks to Bill for this great research into a rapidly changing space. 

Article: APIs are becoming attractive targets

Helpnet Security covers how APIs are becoming attractive targets for attackers in the next article this week. Quoting Matthew Prince (CEO of Cloudflare), APIs offer a “rich, and relatively new, target for hackers.”  The article quotes some familiar statistics, such as the dominance of API traffic globally (57% according to Cloudflare), with the highest occurrence in 2023 in Africa and Asia. Correspondingly, there has been a marked increase in attack volume with HTTP anomaly, injection attacks, and file inclusion being the top three attacks seen by Cloudflare.

Machine learning is used to discover more API REST endpoints than customer-provided identifiers (such as catalogs or inventories), and 33% of mitigations applied to API threats were blocked by DDoS protections already in place.

In conclusion, the article emphasizes the importance of greater visibility of APIs and careful attention to using secure authentication and authorization techniques.

Article: Exploiting an API with structured format injection

That man Dana Epp is back; this time, he’s discussing how to attack APIs using structured format injection. For decades, web developers have been taught not to trust user input, and whilst that message has begun to resonate, APIs present a new vector for abusing input data. APIs, with their structured data inputs, provide great opportunities for wily attackers to abuse the input data to produce unexpected outcomes in the API backend. 

Dana’s article describes various approaches to tainting input data in JSON and YAML payloads, including how to manipulate parameters to trigger a Broken Object Property Level Authorization (formerly known as Mass Assignment) vulnerability. As Dana concludes: “try to taint all the things”

Article: Dana Epp’s predictions for 2024

Coming to the game slightly late (but still in January), let us look at Dana’s predictions for API security in 2024. 

In no particular order, here are Dana’s predictions:

• Automated attacks against APIs will continue.
• “Secrets Sprawl” will still be a thing – personally, this is likely to be the biggest issue in 2024.
• AuthN and AuthZ issues will still exist – almost certainly.
• Generative AI will be leveraged to attack APIs.
• Security tools still won’t catch critical vulnerabilities.

Come for the predictions, and stay for the memes – thanks Dana for a fun read

On the topic of predictions, the API Futures project from Matthew Reinbold makes for some fantastic reading and is highly recommended to anyone working with APIs.

Event: 42Crunch at API Summit in Austin

The Austin API Summit 2024 is approaching fast! Don’t miss your chance to join us on March 12-13th in Austin, TX – to meet industry colleagues, get inspired, and gather knowledge about the technology, trends and best practices shaping today’s API economy.

The event includes a fantastic lineup of speakers who will discuss many different aspects and best practices of API design, security, documentation, management, and more.

Webinar: Top Things You Need to Know About API Security

Uncertain about the differences between BOLA, BFLA and BOPLA?  Want to know how to protect your APIs against these and other key threats? Then join our webinar as two of the industry’s leading experts, Philippe De Ryck and Isabelle Mauny, guide you through some real-world cases of API security attacks and also share some best practices for securing your APIs.

They dive into crucial vulnerabilities highlighted in the OWASP API Security Top 10, such as enforcing authorization, protecting authentication endpoints and preventing SSRF, a new entry in the 2023 version of the OWASP Top10 for APIs. They also bring the threats to life with several demos, providing a practical look at how these vulnerabilities can be exploited, but also how they can be prevented through a combination of design-time and run-time protection.

At the end of this session, you will have an actionable set of guidelines to assess and improve the security of your own APIs in the face of a number of identified threats.

The post Issue 238: APIs used to target business, cloud-native for APIs, and APIs becoming attractive targets appeared first on API Security News.

Article: Six API trends for 2024

The first article this week comes from The New Stack on their trends for APIs in 2024. API adoption and evolution continue to be a hot topic, and this article identifies some really interesting trends as the industry evolves, including, as expected, API security. 

Here are the six trends:

• APIs from multiple sources: APIs have become a vital cog in the software supply chain, allowing connectivity between upstream providers and downstream consumers. Unfortunately, this provides an increased attack surface, as identified in the new OWASP API Security Top 10 API10:2023 Unsafe Consumption of APIs.
• Multiple API standards and formats: While REST is the dominant standard for APIs, newer protocols such as GraphQL and AsyncAPI tend to complicate the landscape further, mainly for security.
• Unbundling API technology: Organizations have begun to find that their bundled solutions (such as APIMs and gateways) lack critical capabilities and have begun to unbundle in favor of more niche and bespoke solutions.
• API technology sprawl: API technology is rapidly evolving (think Kubernetes and FaaS), which poses challenges for governance and security.
• API gateway evolution: The role of the traditional API gateway has changed, and nowadays, organizations are embedding lightweight gateways closer to their APIs. 
• Advanced API security: API security can no longer be handled solely at the gateway level, and organizations are faced with an array of security solutions, from shift-left developer-focused tools to the latest in machine learning solutions claiming to detect emerging threats. 

This is a very interesting read — for me, the comments on the evolution of the API gateways ring true, as do the observations on the API security landscape.

Article: API keys leading to vulnerabilities

The next article is again from The New Stack and discusses how API keys leave your APIs vulnerable to attack. The article suggests that despite the adoption of API gateways, APIs are still hamstrung by their reliance on API keys as the sole method of protection. 

The first and most obvious problem with API keys is that they are frequently very long-lived, often with no expiration. The recent spate of leaked API keys presents a real risk to APIs protected only by keys. Remediation usually necessitates a revocation of keys and the generation of new keys, including the reconfiguration of clients. 

The main issue with keys, according to the authors, is that keys do not offer fine-grained access control — if you have access to a key, you have access to everything in the API. They recommend using tokens (which contain embedded metadata, such as claims) to limit the token’s scope to specific subsections of the API or its data and the allowed operations. Tokens are usually issued using robust protocols such as OAuth2, adding greater resilience to their distribution and use. 

So why doesn’t everyone use tokens, always? The fundamental reason is that they require significant investment in the design and development phase. When pushed with time pressure to deliver, many API teams will opt for a simple key-based solution rather than using a more robust token-based approach. 

The article concludes with a case study of how the Curity identity server helps simplify the adoption of tokens. I particularly recommend Curity’s API Security Model for API architects and system designers — hopefully, we are all rapidly moving to Level 3.

Article: The future of API gateways

On the topic of API gateways, we have a really great read from Kin Lane (aka. APIEvangelist) on the future of API gateways and where he sees the future taking us. As one would expect, given Kin’s pedigree in the API space, it is an exhaustive look at the history of API gateways, the current market and players, and predictions. 

While the article is worth reading in its entirety, his view on the core capabilities is spot on, namely:

• Security: The majority of organizations are highly reliant on their API gateways for the security of their APIs, and increasingly, new players are leading with new security features. Kin suggests that security features will need to be standardized and hardened.
• Traffic: Traffic management is the other key role of the gateway, allowing organizations to manage access to their APIs and to allow them to scale gracefully. 
• Mediation: As the access point to the organization’s data, gateways are pivotal in managing who has access to what data.
• Transformation: As the API protocol and payload landscape continues to expand, the gateways become more important in transforming data from one domain to the other in an efficient and scalable manner. 
• Virtualization: As the move to design-first accelerates, the API gateway will likely take on a greater role in providing mocking or virtualization capabilities.

If you’re involved in selecting or buying an API gateway, the article has a great list of criteria and differentiators. Finally, in Kin’s own words:

“the API gateway of the future has to exist with a small federated footprint that is programmable and extensible. This gateway has to meet the needs of the product and engineering teams who depend on them, and like APIs, respond and evolve with whatever is happening next”

Article: Why API discovery is hard

The second article from Kin features his thoughts on why the perennial topic of API discovery is harder than one would necessarily expect. The lack of a known inventory is a top challenge for API security teams — you cannot secure what you do not know about. 

Kin provides much context on the various dimensions of API discovery, including how to govern the API landscape. Along with security, having a known inventory is essential for adequate governance of APIs in a modern organization. This includes touch points such as:

• Policies: defining what policies already exist.
• Regulation: understanding the requirements of regulations such as GDPR.
• Compliance: ensuring that APIs are compliant.

Thanks to Kin for two great contributions to the newsletter.

Article: Threat modeling of API gateways

API gateways are the focus of our last article, this time in the form of a practical guide on how to threat-model an API gateway. As mentioned in previous articles in this newsletter, the API gateway is often the bastion of security for APIs and, as such, should be thoroughly threat-modeled to ensure there are no avoidable weaknesses. 

From a security perspective, the API gateway provides the following functions: 

• Authorization and authentication
• Routing
• Offloading
• Transport Layer Security (TLS) termination
• Aggregation 
• Single point of access

The authors identify several common API security challenges and best practices as follows:

• Inadequate rate limiting: APIs can easily be abused using brute force attack methods to deny access to the API or bypass login or password reset controls.
• Insufficient data validation: APIs may be vulnerable to data injection attacks or disclose excessive data. Both of these can be prevented at the gateway level by packet inspection.
• Insecure direct object references (BOLA): Gateways can be used to partially mitigate against the threats of BOLA by using pseudo identifiers.
• Lack of logging and monitoring: Gateways are an excellent enforcement point for central logging and monitoring all API traffic. Most offer excellent integrations with common logging and monitoring platforms.
• Lack of encryption: API gateways are an ideal point for enforcing TLS on all inbound connections.
• Inadequate authentication and authorization: API gateways can perform authentication and authorization of inbound requests before they access internal APIs, ensuring the uniform enforcement of access control.
• Misconfigured cross-origin resource sharing (CORS): APIs are able to enforce cross-origin resource sharing (CORS) at the gateway level, reducing the burden on individual APIs to implement this correctly.
• Exposed sensitive data: As per the previous comment about data, gateways can protect against the leakage of sensitive data via an API response.
• Lack of API versioning: Gateways can enforce versioning by routing APIs via path fragments and routing strategies. 

It is worth bookmarking this guide if you are involved in implementing API gateways.

Event: 42Crunch at API Summit in Austin

The Austin API Summit 2024 is approaching fast! Don’t miss your chance to join us on March 12-13th in Austin, TX – to meet industry colleagues, get inspired, and gather knowledge about the technology, trends and best practices shaping today’s API economy.

If you haven’t yet booked your Early Bird ticket, register by January 19th to get the best price!

The event includes a fantastic lineup of speakers who will discuss many different aspects and best practices of API design, security, documentation, management, and more.

Also, Early Bird registrants will be the first to be offered discounted hotel rates available for the Austin API Summit delegates. So don’t wait to take advantage of the best price!

The post Issue 237: Six API trends for 2024, API keys leading to vulnerabilities, the future of API gateways appeared first on API Security News.

This is the final APISecurity.io newsletter for 2023. We wish all subscribers happy holidays and a prosperous New Year and look forward to welcoming you back with issue 237 on the 11th of January 2024!

Article: Using a developer portal for APIs

The first article this week comes courtesy of The New Stack and covers the important topic of developer portals for APIs. A developer portal can be thought of as a library where you, your developers, and your customers can find and use your organization’s APIs. Without a developer portal, it can be challenging to keep track of your APIs, and this can lead to a duplication in effort as teams recreate existing APIs or a lack of control and governance over your API inventory. 

From an API security perspective, most readers will be aware of the challenges an unmanaged inventory poses. Knowing your complete inventory is necessary to quantify the risk presented by your APIs. Many organizations typically have two or three times more APIs than they realize. By using a developer portal as an inventory tracking tool, security teams can keep track of their API assets, introduce governance over the introduction of new APIs, and gracefully manage the deprecation of obsolete APIs.

The author identifies several other benefits of API developer portals, namely: 

• Troubleshooting and maintenance: a comprehensive catalog can help developers and operations teams understand the connectivity of coupled APIs and aid in troubleshooting in the event of outages or performance issues.
• Support: the catalog can be useful to support teams in identifying APIs and their respective owners, which is important when allocating support teams to support an incident.
• Onboarding and training: help onboarding new team members understand the overall API topology during their onboarding and induction.
• Ongoing development: provides information to developers about the existence of APIs already available in their organization.
• Strategic planning: allows the leadership teams to consolidate their inventory and plan their strategy going forward regarding new APIs and deprecation of obsolete APIs.

This article features an in-depth look at the Port developer portal platform, which looks very comprehensive and offers a totally free tier.

Guide: Finding “dark data” in an API

Our top contributor in 2023 is undoubtedly Dana Epp, and it’s appropriate that we feature him in our Christmas issue. This time, he’s discussing the critical topic of “dark data” within APIs. 

Dana’s working definition of “dark data” is “as any data collected and stored by an organization but not generally used for any practical purpose.” This data can be any from internal storage systems such as databases or various analytics and business intelligence tools. Think of it as metadata that may leak confidential information about your primary data assets, allowing an attacker to infer various useful insights.

Dana calls out the significant concerns around the leakage of such dark data, namely:

• Security risks: data may include sensitive information such as usernames or other PII. 
• Compliance issues: many industries have very strict data protection and privacy requirements, and even such seemingly innocuous data may constitute a violation.
• Insights and opportunities: dark data can provide an attacker with insights into how to attack your organization via its business logic or application flows. 

The impacts of dark data leakage (and, more generally, excessive information exposure) are captured in the OWASP API Security Top 10 as the third most significant concern affecting APIs in the category API3:2023 Broken Object Property Level Authorization. 

The recommendation for an API builder or defender is to use a tightly constrained OpenAPI definition that specifies the minimum data to satisfy the API’s functionality. Use continuous testing to ensure that your APIs meet this contract, and use runtime protection to ensure APIs do not leak additional data in production.

Tools: Web Security Academy resources for API security

PortSwigger’s Web Security Academy is an evergreen resource for learning about web application security and API security. The academy provides excellent guided lessons and hands-on laboratories to allow users to explore topics of interest. In my opinion, their academy is one of the best learning resources for security topics.

Recently, they have published guidance on learning resources specific to the OWASP API Security Top 10. This resource is great for anyone (attacker or defender) wanting to learn more about API security.

Vulnerability: API vulnerability found in Ray AI framework

Last week, we covered several vulnerabilities discovered in the Ray AI framework. We failed to provide the official response from Anyscale concerning the disclosure. 

In summary, the status is as follows:

• 4 of the 5 reported CVEs (CVE-2023-6019, CVE-2023-6020, CVE-2023-6021, CVE-2023-48023) are fixed in the master and will be released as part of Ray 2.8.1.
• The remaining CVE (CVE-2023-48022) – that Ray does not have authentication built-in – is a long-standing design decision based on how Ray’s security boundaries are drawn.

According to their post, the 5th CVE (the lack of authentication built into Ray) has not been addressed, and that is why it is not, in their opinion, a vulnerability or a bug.

Webinar: Top Things You Need to Know About API Security

The flipside of the exponential adoption of APIs over the past decade has been the upsurge in the sheer volume of API attacks. Stories of API security breaches are everywhere which shines a harsh spotlight on the ease of API abuse and the complexities of robust API security. Join this webinar as two of the industry’s leading experts guide you through some real-world cases of API security attacks and also share some best practices for securing your APIs. 

They dive into crucial vulnerabilities highlighted in the OWASP API Security Top 10, such as enforcing authorization, protecting authentication endpoints and preventing SSRF, a new entry in the 2023 version of the OWASP Top10 for APIs. They also bring the threats to life with several demos, providing a practical look at how these vulnerabilities can be exploited, but also how they can be prevented through a combination of design-time and run-time protection. 

At the end of this session, you will have an actionable set of guidelines to assess and improve the security of your own APIs in the face of a number of identified threats.

Predictions for API security in 2024

Finally, I am compelled to make some predictions of my own for API security in 2024. I think API security will remain an important topic in 2024 and continue to receive significant attention at various levels. Based on what I have seen recently in the newsletter, I predict:

• We will see more so-called mega-breaches where organizations lose all of their customer or private data to API breaches or exploits (see examples here and here)
• Vendors (seemingly most often cryptocurrency portals) will continue to experience key leakage or loss (see here, here, and here for examples) 
• Attackers will continue to shift their attacks toward more subtle vectors that exploit the business logic of the API rather than specific implementation flaws. A good example is the recent Twitter mass account information leakage incident, which occurred without detection over 18 months.
• I think we will see the occurrence of the first batch of API supply chain vulnerabilities where an upstream API flaw is instrumental in a breach in a downstream API, as predicted by OWASP with the new API10:2023 Unsafe Consumption of APIs.
• And finally, the role of the developer in implementing API security at design time will only continue to rise. As I alluded to over a year ago, empathy for the API developer with tools designed to secure code at design time can only help improve API security in general.

The post Issue 236: Using a developer portal, dark data in APIs, an update on Ray AI framework, predictions for 2024 appeared first on API Security News.

Breach: Kronos suffers $25m loss involving API key loss

The most important news this week is the breach at the cryptocurrency fintech firm Kronos Research, who revealed in a post on X that they had suffered a loss estimated at $25 million. The company admitted that the breach originated with “unauthorized access to some of their API keys.” although it did not provide any further detail. Independent observers commented that they had seen Ethereum outflows from a wallet to a value of approximately $25m, which seems to correlate with the disclosure. 

This is yet another in a steady sequence of breaches involving the loss or leakage of API keys, particularly on cryptocurrency platforms. As ever, the advice is to protect the keys using vault or secure storage mechanisms and ensure they are invalidated in the event of loss or theft.

Vulnerability: Malware poses a DDoS threat to Docker API

The next vulnerability is the discovery of Python malware affecting exposed Docker engine API endpoints. Researchers discovered that a malicious container image (disguised as a benign MySQL image) contained Python malware compiled as an ELF executable. 

The attack was initiated by issuing an API request to the exposed Docker API to begin the download of the malicious image. Upon execution of the image, the malware connected to a command-and-control center and then undertook various DDoS using UDP and SSL-based flooding attacks. The command-and-control interface was found to control the target IP addresses and domains, including the duration, rate, and port.

We frequently cover issues with exposed Docker or Kubernetes API management interfaces being abused by attackers. Ensure these endpoints are either isolated from public networks or protected with strong authentication.

Vulnerability: Report exposes WordPress and Netflix API flaws

The next article covers the latest research into API threats and vulnerabilities from Wallarm in their ThreatStats report. The report aggregates findings from 239 API vulnerabilities, with the most significant finding being that nearly a third featured broken authentication, authorization, or access control. The report highlights cases of incorrect credential validation on OAuth tokens, allowing possible unauthorized access, and WordPress encountered issues with broken plugin authentication.

The rise in API adoption has resulted in increasing incidences of data leakage and ranked fourth in the report’s ranking for severity. The report cites findings from Netflix, VMware, and SAP, which recently exposed sensitive information over their APIs. The report also highlights the rise in leaked or stolen API keys incidents.

Vulnerability: API vulnerability found in Ray AI framework

The final of our vulnerabilities in this issue comes courtesy of a report in Security Week, which provides a review of a vulnerability (tracked as CVE-2023-48023) in the Ray AI framework. The root cause of the vulnerability is broken authentication on two of its components, the dashboard and the client. An attacker could use the vulnerability to submit or delete jobs to the engine or, even more seriously, retrieve sensitive information or execute arbitrary code.

Most surprising is that the framework does not provide any form of authentication at all, with the only reference being some support for mutual TLS, which is a significant oversight in the design since any user with dashboard access effectively had control of the platform. 

At the time of writing, the issues had yet to be addressed, either since the vendor did not recognize them as security issues or was unwilling to manage them.

Article: APIs are proving fertile ground for cyber attackers

The next article features the views of Matias Madou (CTO of Secure Code Warrior) on how API security creates an opportunity for cyber attackers who see APIs as an easy target. Madou highlights that many APIs suffer from poor access control, citing recent high-profile examples such as T-Mobile and LinkedIn. This is hardly surprising because access control flaws comprise the top half of the OWASP API Security Top 10. 

Madou suggests these findings result from poor awareness of security best practices by API developers. In particular, developers need help with the core topics of authentication and authorization. He recommends that organizations commit to continually upskilling their developers through training and allocating sufficient time to allow them to absorb learning and explore best practices. 

Madou also highlights some industry concerns about how API security is managed. Current reports suggest that 40% of organizations need a dedicated owner of API security; instead, the responsibility is shared between the CISO or the DevSecOps teams. Somewhat concerningly, 24% of respondents said no one in particular owns API security in their organization. If ownership is unclear, then it is likely that the responsibility for API security will fall between the cracks — ensure this critical topic has a dedicated owner.

Thanks to Matias for another great contribution to the importance of developer training.

Article: Protecting APIs for online retail

Finally, this week, we have a seasonal article on how to protect APIs for online retail over the festive season. The article highlights the scale of online fraud, citing the astonishing statistic that in the first six months of 2022, Americans lost a record figure of $3.56 billion to online fraud. During the peak holiday season (starting from 1 November, going to the year end), commerce sites will see a massive uptick in bot attacks ranging from a fivefold increase to a whopping thirtyfold increase. Attackers have readily discovered that APIs often lack the necessary sophisticated protections to defend against bot attacks and will often launch automated attacks on retail endpoints using stolen credit card numbers to identify retailers with insufficient fraud protection. 

The author recommends the use of a robust bot protection solution and the following API best practices:

• Strong authentication mechanisms such as multifactor authentication.
• Data encryption and secure transmission to protect data in transit.
• Monitoring and anomaly detection to identify changing threats.
• Fraud detection and prevention to verify payment information.

This is a timely reminder to all our readers to be extra vigilant to online fraud over this festive season.

The post Issue 235: 25m loss at Kronos due to API key loss and three other API vulnerabilities appeared first on API Security News.

Breach: Sumo Logic advises customers to reset API keys

Sumo Logic confirmed it had discovered evidence of a potential security incident on the 3rd of November. It has since locked down the exposed infrastructure and rotated every potentially exposed credential “out of an abundance of caution.”

Although Sumo Logic insisted there was no indication of a compromise or a breach of customer data, they advised customers to rotate both keys used to access Sumo Logic or that were provided to Sumo Logic for accessing other systems. The attack was believed to have involved third-party access to a Sumo Logic AWS account.

Although Sumo Logic declined to comment further on the details of the incident, it assured customers that they were committed to “a safe and secure digital experience,”

This is another in a recent spate of API key leakage incidents coming on the back of the OpenSea and JumpCloud incidents reported in this newsletter.

Article: The risk of RBAC vulnerabilities

The first article this week is from GBHackers and discusses the risk of role-based access control (RBAC) vulnerabilities in systems built-up APIs. Most people, I am sure, are familiar with the principle of RBAC — a user is assigned rights on a system based on their role, and when they no longer hold that role, those rights fall away. This paradigm is a popular choice for API authorization too, where frameworks such as Casbin and Oso HQ provide good implementations of RBAC engines.

The article describes typical usage of RBAC in certain industries such as healthcare, financial services, eCommerce, and government. It then goes on to describe some common RBAC vulnerabilities encountered in the real world:

• Excessive Permissions: This is the most obvious vulnerability and simply occurs when a role is given excessive permissions to accomplish the given tasks. The principle of least privilege should be employed to ensure only the necessary permissions are assigned.
• Stale Roles: Often a user will be assigned a role that they no longer need after some time. This results in maintaining access, which is no longer necessary.
• Permission Creep: Similar to stale roles, this is when a user changes roles frequently and accumulates more roles than they need.
• Inadequate Auditing: The previous two vulnerabilities can be identified by regular audits; failing to perform these regularly is another common failure pattern.
• Insecure APIs: These can be an entry point for attackers to manipulate permissions or gain unauthorized access to sensitive data.

The guide ends with some rather generic but useful advice on how to prevent RBAC vulnerabilities, namely:

• Least Privilege Principle: This is the obvious solution for many RBAC issues and relies on only assigning the absolute minimum set of permissions to complete a role. The challenge comes in identifying those permissions in the first instance.
• Time-Based Roles: This is a failsafe method to prevent permission creep and that is to periodically revalidate the role access, or to forcibly remove the role entirely.
• Multi-Factor Authentication (MFA): Sensitive roles (such as admin roles) should employ MFA to prevent unauthorized access.

This is a quick, easy read for anyone implementing RBAC in their systems.

Article: Why CFOs should prioritize API security

The next article from Security Boulevard provides a really interesting perspective on the need to prioritize API security looking at it from the view of the Chief Financial Officer (CFO). Frequently in this newsletter, we consider API security from a technical or security viewpoint, so it’s interesting to understand the financial motivators behind producing secure APIs. 

The first obvious benefit is simply avoiding the cost of breaches in the first instance. Breaches can lead to fines due to failings in regulatory, GDPR, CCPA, or HIPAA compliance. In many cases, these fines can be crippling, being a significant portion of revenue. Large-scale breaches also undoubtedly lead to brand damage and a tarnished reputation, leading to a loss in consumer confidence, particularly if those consumers are entrusting you with their data. 

Consumers are becoming more security savvy and are paying attention to news of large-scale breaches. Once a reputation is tarnished the brand may never recover from the damage inflicted. For a CFO, this has to be a strong and compelling driver.

As security practitioners among our readers will know only too well, a breach can be extremely costly in terms of operation cost in recovering from the breach and the loss of revenue resulting from the downtime incurred. Obviously, handling the breach will distract security teams from addressing other security activities, such as proactively improving API security, in the first instance.

Another obvious financial benefit to a robust API security regimen is the likely reduction in cybersecurity insurance. By being proactive about security, in particular about API security, and being able to demonstrate proactivity can allow a savvy CFO to negotiate better rates and terms with insurance providers.

APIs are a vital part of the modern supply chain and by ensuring the APIs you consume and provide are secure, you can minimize the risk of inheriting risk from your providers or passing risk on to your consumers. 

Finally, if your teams are not reactive and dealing with ongoing API security breaches and incidents, they can be freed up to drive innovation by building new products and integrations or by ensuring even greater security. 

This is a useful guide for those wishing to justify upcoming budgets for API security projects.

Book: Automating API delivery

A friend of the newsletter Ikenna Nwaiwu, has recently published his book with Manning on the topic of “Automating API delivery”. The book focuses on how to use DevOps approaches in your API design and delivery phase and covers the following topics:

• Enforce API design standards with linting
• Automate breaking-change checks to control design creep
• Ensure the accuracy of API reference documents
• Centralize API definition consistency checks
• Automate API configuration deployment
• Conduct effective API design reviews

I particularly enjoyed the sections on automating API linting, using GitHub Actions and the section on OpenAPI Generator, which shows great promise. The book is in early access from Manning and has only three more chapters to go. Good luck to Ikenna getting this over the line, and with the upcoming launch and promotion.

Report: API market set to continue to grow

If anyone doubted the size of the API market, then the latest research from Kong should prove to be a real eye-opener. The headline figure is quite startling, with the global economic impact expected to rise from approximately £7.17 trillion in 2023 to about £9.33 trillion over the next four years. Unsurprisingly, much of this growth will come from the artificial intelligence market estimated at around £4.41 trillion in 2027, indicating a substantial 76% increase from 2023 estimates.

The report does make the obvious and crucial point that security risks arising from such exponential growth should not be underestimated. 

Tools: Automated API contract generation

Recently, 42Crunch released their new automatic API contract generation tool API Capture, which will enable organizations to automate the generation of OpenAPI contracts (aka. Swagger files), which can be used to facilitate security auditing and testing. The tool analyzes network traffic and also imports Postman collections to auto-generate the API contract definitions. ​​ This innovative approach expedites testing timelines, minimizes manual effort, and ensures highly secure and scalable APIs.  

Further information is available on the 42Crunch website

The post Issue 234: Sumo Logic breach leads to key reset, risk of RBAC vulnerabilities, automated API contracts appeared first on API Security News.

Vulnerability: Flaws in OAuth social sign-in put billions at risk

The most important item this week (and in the last few months) is the vulnerability discovered by Salt Labs in implementing the OAuth protocol in several popular websites. The vulnerability could have allowed attackers to harvest tokens using a malicious site using OAuth2 social logins and then use these harvested tokens to gain full access to accounts on vulnerable websites. The research describes vulnerabilities on the Grammarly, Vidio, and Bukalapak websites which have now been remediated on all three websites.

The original disclosure on the Salt Labs website is worth reading to fully appreciate how a subtle omission on the vulnerable website’s OAuth handler code could create such a serious vulnerability. During the OAuth token exchange, the client application must validate the token’s identity received from the authorizing server (such as Google or Facebook) to ensure that the application ID matches its own. In other words, does the token belong to the application, or is it a stolen or harvested token from another application?

The image above shows OAuth’s standard “implicit grant type” flow. In step 5, the user presents the token received previously to the client application, which then asks the authorization server for the token’s identity (steps 6 and 7). Before issuing the request at step 6, the client application is expected to verify that the token contains a client_id value identical to its own ID value. If not, the token is fake or has been tampered with and should be rejected. Unfortunately, this research discovered three websites where this check was omitted, allowing fake, harvested tokens to be used. These fake tokens would then assign the attacker all the rights and privileges on the vulnerable site that the victim user had — potentially a total account takeover.

The guidance from Facebook is very explicit in this regard:

“When token is received, it needs to be verified. You should make an API call to an inspection endpoint that will indicate who the token was generated for and by which app. As this API call requires using an app access token, never make this call from a client. Instead make this call from a server where you can securely store your app secret.”

I will be totally transparent here and admit that while I was aware of the importance of this step, I am almost certain I have written code that omits this important verification step. I predict that many other websites are vulnerable to this same issue and that this will not be the last time we feature it in this newsletter.

Article: Five best practices for security API gateways

In the first of two guides from The NewStack, we look at five best practices for API gateways. The API gateway has become the stalwart in the front line of defense of APIs, and yet many API teams fail to take advantage of the many security features offered by their gateways.

The article recommends that the principle of zero trust should be foremost when configuring API gateways. To implement zero trust in your API gateway, you must validate and authenticate every user, request, origin, and action before granting access.

The five top recommendations featured in the article are:

1. Authentication: Use token-based authentication with short-lived tokens. Use tokens in preference to keys, keep the token lifetime short to avoid the impact of loss or theft, ensure that tokens are transmitted securely over TLS, and ensure that you fully validate signed tokens to ensure their authenticity.
2. Authorization: Strictly enforce role-based access control (RBAC) for all API endpoints. Use the principle of least-privilege, and manage the claims in your tokens carefully to ensure that you do not have wide open access.
3. Rate Limiting: Implement dynamic, layered rate limiting based on user behavior and context. This really is one of the easier ones to get right, as gateways tend to have rich features around rate limiting, allowing it to be based on IP address, session or user IDs.
4. CORS: Explicitly define and restrict allowed origins. Use well-formulated CORS policies to ensure that your APIs are not wide open to any attacker and, rather, can only be accessed from the intended origin (usually your web application).
5. Logging: Implement real-time monitoring and alerting for anomalies. Verbose and accurate logs are essential to ensure that any API anomalies are identified and can be addressed.

To this list, I suggest that, where available on their API gateway, security teams enable the packet inspection capabilities of their API gateways and use this in conjunction with the OpenAPI definition to enforce request and response data validation. Remember that API 03:2023 – Broken Object Property Level Authorisation is all about data validation.

Article: How to design scalable SaaS API security

The second guide from The NewStack features the views of Curity on how to design scalable SaaS API security. The article describes the importance of a robust and scale OAuth2 authorization framework (very timely based on our first article). It stresses the importance of choosing the correct flow for the application in question (and implementing that flow correctly to avoid security loopholes).

The guide then looks at the important choice of an authorization server. It suggests that simply defaulting to the cloud provider’s built-in implementation may not always be optimal and that the choice requires sufficient care and attention. Designers should pay attention to the ease of deployment and redundancy or restore times in the case of a failure since the authorization server is mission-critical.

Regarding the use of OAuth2, the guide stresses the importance of not only choosing the correct flow but also ensuring that tokens are designed optimally to minimize the scope of the claims being made (the principle of least privilege) and to ensure the minimum validity is used (a point made in the second article too).

Thanks to Curity for another informative guide on an important topic.

Tools: 42Crunch and Microsoft Partner to Deliver End-to-End API Security

Yesterday, 42Crunch and Microsoft announced an integration of services to help enterprises adopt a full-lifecycle approach to API security. The partnership provides continuous API protection from design to runtime to help Microsoft’s enterprise customers protect their APIs from attacks and data breaches.

With Microsoft Defender for APIs, now in GA, an offering as part of Microsoft Defender for Cloud – a cloud-native application protection platform, organizations can improve their security posture and quickly detect active real-time threats. This integration empowers developers to test their APIs for security during development and empowers security admins to gain full lifecycle visibility into the security posture of their APIs within Defender for Cloud.

Further details of how the integration works are available here.

Guide: How to prevent API breaches

The next guide comes courtesy of The Hacker News and is a compendium of best practices that can be used to prevent API breaches. Although many of these will be familiar to readers of this newsletter, this guide does highlight some of the critical design and test fundamentals for anyone involved in securing APIs.

Right at the top of the list is the twin pairing of authentication and authorization, which are certainly top issues for API security — most breaches we see will include a failure of one or both of these. They describe the following key topics:

• API keys and tokens: be sure to safeguard keys and tokens, use tokens with short lifetimes, and transmit them securely.
• OAuth and OpenID Connect: use industry-proven and robust protocols to establish authentication and authorization, and be sure to implement them securely (again, see the first article).
• Role-based access control: Only provision the minimum necessary privilege to users.

Second on the list is data encryption, which is vital to ensure that APIs do not leak data or information unnecessarily. The key topics here include:

• SSL/TLS certificates: Ensure that server certificates are valid (watch for expiring certificates) and that clients fully validate the certificate chain.
• Transport Layer Security: Use TLS everywhere to ensure data privacy, and between microservices use mutual TLS where possible.
• Encryption of data at rest: When storing data on the filesystem use encryption to protect it, and when storing in a database use the built-in database features to protect the data.

Also critically important is the topic of API design and implementation to ensure that APIs are secure by design. The key topics here are:

• Versioning: Manage deprecated APIs and ensure that API changes do not break existing clients.
• Input validation and data sanitization: Use core principles from AppSec to ensure that all input data is validated and sanitized to prevent possible injection attacks.
• API endpoint security: Ensure that API endpoints include proper checks for authentication and authorization.

Testing is critical in ensuring that flaws in APIs do not make it to production. A well rounded approach to testing yields the best results and should include the following:

• Automated Testing: Use automatic API testing tools in the CI/CD pipeline to ensure APIs are compliant with their specification and do not contain basic errors such as missing authentication or authorization.
• Unit Testing: Developers should test individual elements of API functionality as they implement it within their environments.
• Integration Testing: Test the full API to confirm it works with dependent components.
• Functional Testing: Test the functionality of the API to confirm it behaves as expected.
• Continuous Automated Red Teaming (CART): Use red teams and/or managed bug bounty programs to keep on top of API security risk.

Guide: Proving API exploitability with Burp Collaborator

Finally this week, we have another guide, this time featuring the PortSwigger Burp Collaborator tool to prove the exploitability of APIs, particularly for attacks which are blind and do not reveal indication of compromise to the main output.

Burp Collaborator is a rather useful companion tool for uses of paid versions of Burp Suite. The diagram below shows the basic usage: a tester using Burp Suite submits a payload to the target and if it is vulnerable, will extract the payload and access links which will trigger access to a URL on Burp Collaborator which will store the payload for analysis in Burp Suite.

As usual Dana provides a great guide on how to use it in your testing, but if you are looking for an excellent real-world example then this write-up from AssetNote is a great read. Thanks to both for the great guides.

The post Issue 233: Flaws in OAuth social sign-in, securing API gateways, scalable SaaS security appeared first on API Security News.

Article: API attacks surge as cybercriminals target financial service

In the first of our articles this week on the rise of API security risks, we cover a report from CSOOnline discussing the increase in attacks on APIs and web apps in the financial services industry. According to a report from Akamai, Q2 saw a 65% rise year on year in such attacks, with the majority directed at banks. The report covers over 340,000 servers in 4,000 locations and also reports a rise in Layer 3/4 DDoS attacks.

API security risks pose persistent threats to organizations across sectors, with the growing use of APIs giving attackers more ways to break authentication controls, exfiltrate data, or perform disruptive acts. Of the financial services targeted, banks faced the most attacks at 58%, with other industry segments (Fintechs and insurance) facing ever-growing challenges as the pace of digitization gains momentum.

One of the interesting statistics quoted in the report is their finding that Local File Inclusion (LFI) attacks are the top attack vector, accounting for 58% of attacks, with Cross-Site Scripting (XSS) and SQL Injection (SQLi) coming in second and third place. This data is not borne out by my own research, which reveals that broken authentication and secret leakage are the biggest threats to APIs.

The report concludes that financial services are increasingly integrating third-party risk management into their overall risk management policies to mitigate the risk from third parties.

Article: The silent threat of APIs

The next report on the threat from APIs comes from Richard Bird (CSO of Traceable AI), covering their report on the state of API security in 2023. The report covers findings from 1,629 respondents from over 100 countries and six major industries. The headline figures are startling: 74% of organizations have experienced three or more API-related breaches in the last two years. The expansion rate of connected organizations is also highlighted by the statistic that over 88% of organizations have over 2,500 cloud applications.

Bird’s key takeaway is that APIs contribute to increased unknown risk for organizations. Although organizations are conscious of the risk of APIs, over 40% of them reported that they only test a small fraction of their APIs for vulnerabilities. Without being able to measure API risk, it becomes challenging for organizations to detect and contain API risk.

The report highlights how APIs are driving the expansion of the attack surface, namely:

• Sheer volume of APIs: The volume of APIs continues to grow exponentially, and this is not restricted to public-facing APIs, as internal and 3rd party APIs are growing at similar rates.
• Diversity in API types: APIs are a long way from being a uniform attack surface since many protocols are in play and many more deployment and configuration options. This creates a growing and complex attack surface, with 58% of respondents claiming that APIs increase their attack surface.
• Varied perceptions about API risk: Despite the high prevalence of API-based incidents arising from poor security, many respondents sought to downplay the risk, with 8% feeling it was negligible.
• Unknown risk and the expanding attack surface: As highlighted earlier, the unknown attack surface makes it harder to contain and manage risk, with many organizations being unaware of their attack surface.

For Bird, the biggest risk to organizations and their connected digitization strategy arises from unknown (and hence) unquantified risk.

Article: What happened with the Jumpcloud incident

Recently, we covered an incident on the Jumpcloud platform where users were advised to rotate API keys “out of an abundance of caution,” and this week, we have a post-mortem report on the incident from TechRadar.

The first concern was the lack of transparency from JumpCloud in communications around the incident. The initial communication was a brief note to rotate API keys and an apology, but no further explanation was given, leading to speculation in the wider community. According to the report, the breach was a result of a spear-phishing campaign that was able to gain access to Jumpcloud’s internal infrastructure and target a subset of its customers. This left JumpCloud with no option but to force a reset of all customer API keys.

JumpCloud has since provided an update to customers, reporting that only a few customers and systems were impacted and that the threat had now been totally contained. The attack highlights an increasing trend where attackers are targeting cloud service providers due to the rich nature of the assets, including SSO, MFA, password management, and device management that these providers hold. As per this attack, often the easiest attacks are simply to steal API keys and use those to infiltrate downstream services.

Unfortunately, there is no silver bullet in minimizing the threat of stolen or leaked API keys and tokens. Typical guidance includes ensuring a robust exchange or revocation process exists, minimizing the lifetime of keys and tokens, and reducing the scope of tokens to reduce the impact of a lost or stolen token.

Guide: Seven things about API security

The next guide is destined to be a favorite with readers and features Dr. Philippe De Ryck discussing seven things about API security from a recent talk he gave. Philippe has kindly made the slides available, and anyone working in the realm of API security is advised to grab a copy and understand the content.

As a case study, Philippe uses the example of how not to do APIs from the Yunmai smart scale (one of our most popular breach reports). Philippe uses this case study to illustrate why developers so frequently make mistakes in implementing authorization and provides some easily consumable patterns for how to get it right the first time around.

Philippe’s slides then go on to cover his seven key things about APIs, namely:

• Centralize complex authorization logic – avoid so-called spaghetti code implementing authorization in various disconnected locations in the code base.
• Empower audibility – make the intent behind coding decisions explicit and obvious to aid effective code reviews.
• Avoid sensitive data exposure – be careful of your ORM and helper functions like .to_json().
• Avoid leaking information – avoid exposing the implementation internals of your API.
• Implement rate limiting – one of the simplest and easiest ways to prevent your APIs from being abused.
• Mitigate guessing attacks – make identifiers hard to guess using complexity and randomness.
• Protect against SSRF – use CORS to help protect against SSRF.

Another great resource from Philippe (be sure to check out his many other excellent free resources), and a big thanks to him for his contribution to the community.

Tools: OAuth.Tools goes beyond just JWTs

Useful API tools are always popular with our readers, and this week, we have news of the excellent OAuth.Tools from our friends at Curity.

Although ostensibly a JWT editing tool, it offers a wealth of other features that will be useful to anyone working with JWTs, OAuth, and OpenID Connect. The diagram below shows some of the key features, including examples of flows for popular OAuth flows and token management:

This is a really powerful tool, and I recommend bookmarking it if you are involved in wrangling JWTs, OAuth flows, and OpenID Connect. Thanks to Curity for making this available to the community.

Guide: Finding hidden API endpoints using path prediction

As has become a tradition of late, we finish this week with another guide from Dana Epp looking at how to find hidden API endpoints using path prediction.

Hidden API endpoints are entry points within an application’s API that are not documented or publicly announced for various reasons. They can possess vulnerabilities, and hence, understanding and locating them is a critical aspect of bolstering API security.

Path prediction is a technique that involves studying the URL structure, endpoint patterns, and other discernible indicators within the API documentation or code to guess potential hidden endpoints. Path prediction is a powerful technique for discovering undisclosed or weakly secured endpoints.

Dana highlights how developers focused on good REST design principles will tend to produce APIs with fairly predictable endpoints. From a red-team perspective, being able to predict API endpoints is a valuable skill.

Another fun read from Dana. Thanks for the contribution.

The post Issue 232: API attacks surge, the silent threat of APIs, Jumpcloud incident review appeared first on API Security News.

Vulnerability: API authentication bypass in Ivanti Sentry

First up this week is news of a vulnerability in the Ivanti Sentry cybersecurity product. The vulnerability (tracked as CVE-2023-38035) impacts versions 9.18 and earlier of the product. 

The vulnerability allows an attacker to access an administration API endpoint (running on port 8443 by default) without any authentication at all. The API provides a number of high-privilege functions, including changing the configuration, running commands, and writing files to the system. Due to the impact of potential access, the vulnerability is rated critical and assigned a CVSS of 9.8. In their statement, Ivanti highlighted that the likelihood of real-world exploitation is relatively low since, in most cases, this administrative port will not be publicly accessible. As a precaution, they released a set of RPM scripts to patch the issue and advised customers to disable this administrative endpoint unless absolutely needed explicitly.

This is another example of API 02:2019 — Broken User authentication; in this case, it appears there was no authentication at all (never mind it being broken). Instead, the system designers relied on the port being disabled via configuration or being blocked by a firewall as a mitigation. Defense in depth is always the best strategy for a secure system.

Report: Docker images expose APIs and private keys

Next up is an interesting report featured in Security Boulevard, citing a report from Git Guardian on the prevalence of stored credentials within Docker images. The report cites previous research from Git Guardian into 10,000 Docker images and then more recent research from the RWTH University in Germany into over 300,000 Docker images on DockerHub. 

The headline figure is the fact that 8.5% of the images contained stored secrets such as API keys and private keys. Breaking down the credentials by type revealed the following:

• 52,107 private keys
• 2,920 cloud keys
• 213 social media keys
• 25 keys for financial tools (Stripe, Square, PayPal, etc)

The researchers mention some caveats regarding the accuracy of their findings: firstly, not all keys could be tested and validated against their intended systems for validity (leading to false positives), and secondly, not all credentials were necessarily detected (leading to false negatives). 

Whilst the adoption of containers has been a great boon to developers and IT teams, they do present an additional risk vector for security teams to consider. In my personal experience, I have encountered developers who have mistakenly assumed credentials embedded into a lower layer of a container image would not be accessible. An attacker can either use a tool to unpack the layers or just execute a shell within the running container to access any “secrets”. A container is not a secure storage medium.

This report shines a spotlight on an increasingly prevalent problem affecting API security, namely the leakage of keys and tokens. Remember to use a secure and robust credential storage mechanism, for example, a key vault, and do not rely on obfuscation, such as hiding credentials in a container image.

Article: API security’s role in protecting retail apps

The next article again comes from Security Boulevard and discusses API security’s role in protecting retail apps. The article highlights the growth of APIs, particularly within cloud platforms, where they form a vital part of the connecting fabric and the increasing attractiveness of APIs for attackers. 

The article then makes a distinction between the control plane (which is largely the responsibility of the cloud provider) and the data layer, which is definitely the responsibility of the end user. Increasingly, this data layer is growing in complexity with both a north-south element (for external connectivity) and an east-west element (for internal connectivity between services). The report highlights the importance of data protection from a governance and compliance perspective and highlights many API data security risks that will be familiar to readers of this newsletter.

The most interesting part of the report is the discussion on cloud-native protection platforms, in particular, the protections that can be offered by modern so-called cloud application protection platforms (CNAPP). These offer end-to-end protection and complete lifecycle management of cloud-native applications, covering threats such as web application and API attacks and cloud, storage, and database attacks. As an example, a CNAPP typically encompasses the following:

• DevSecOps 
• Cloud security posture management (CSPM)
• Infrastructure-as-code (IaC)
• Kubernetes security posture management (KSPM)
• Cloud infrastructure entitlement management (CIEM)
• Runtime cloud workload protection platform (CWPP)

This is another timely reminder that good API security requires a layered approach, including hardening and protecting your runtime environments using modern cloud-native protection platforms such as CNAPPs. It’s worth remembering, though, that regardless of how well the underpinning platform is secured, APIs will still be vulnerable if they are poorly designed or implemented or not tested sufficiently.

Article: How APIs and generative AI interoperate

The next article from Silicon Angle discusses the role APIs play in driving the adoption and integration of generative AI and how the two bring great opportunities but, with it, increased challenges for risk management. The democratization of generative AI (driven by the runaway success of ChatGPT) has enabled software engineers and developers to incorporate AI capabilities into the offerings, and APIs provide the vital connecting tissue between these integrations. The rise of so-called “citizen developers” using low-code platforms and API-connected AI services will be building the next generation of apps. Ironically, many of them will learn these skills using the very AI services they themselves are integrating. 

More technically savvy users will continue to create complex software systems using multiple APIs and various AI and ML systems to solve some of the world’s hardest challenges. These solutions will then be offered back to the open market to be consumed via – you guessed it – APIs. This is a rose-tinted view of a future where we are locked into a spiral of continuous learning and technological advancement. 

However, this leads to an increasingly complex web of connectivity between systems, which will begin sharing data with one another. This will lead to increasing complexity from a security and compliance viewpoint. Developers must be mindful of the various data privacy requirements associated with the systems they build and the risks exposed by simply connecting everything via an API.

Article: Common bypasses of Web Application Firewalls

The next article from The New Stack describes many of the techniques hackers use to attack and bypass Web Application Firewalls (WAFs). This is particularly interesting to API security practitioners since WAFs are commonly the only line of defense for APIs, and it is worth knowing their limitations.

The article first identifies some of the most common WAF attack types, including:

• Injection attacks: these may include SQL injection, command injection, and cross-site scripting attacks. Generally, these attacks seek to evade protections (in a WAF or in the backend API or application code) to allow attacks against the underlying systems, such as a database. 
• Broken access control: these attacks either target missing authentication or insufficient authorization validation and are the most common attacks against APIs. WAFs in particular, are ineffective in protecting against this category.
• Vulnerable and outdated components: when a new vulnerability is discovered in a component, bot farms will scan the internet for publicly exposed instances to attack. WAFs are critical in protecting these types of attacks.

The article then describes the three types of WAFs, namely:

• Negative security model: this attempts to block so-called “known bad” via a “deny list”.
• Positive security model: this only allows so-called “known good” via an “allow list”.
• Hybrid security model: uses a combination of signatures (the deny list) and then checks if the request is allowed (the allow list). This improves efficiencies since block lists are easier to implement.

Now, how do attackers exploit WAFs in practice? Firstly, attackers know that analyzing traffic is computationally expensive and increases latency. To this end, they will exploit the limitations of WAFs by sending large packets (such as 8kB or more), which will not be scanned at all by many popular WAFs. Alternatively, attackers may pad their attack payloads by placing dummy data at the front of the payload and then placing the malicious payload at the end. The intent is to trick the WAF into allowing the packet once it has scanned a few kBs of innocuous data at the front of the payload.

Finally, the article concludes with three steps to improve your WAF security:

• Test your web applications with padded request data.
• Examine your web application logs to find request sizes greater than, say, 8kB to identify attacks.
• Determine if you can change your configuration to disable padded attacks (limit the request size, for example).

Web Application Firewalls are a useful tool in the armory of a defender, but it is worth being aware of some of their limitations and attack vectors.

Guide: Using Postman Flows for API exploits

Finally, this week, we finish with another of Dana Epp’s customarily awesome guides — this time, he shows us how to use the Workflows feature with Postman to exploit APIs. Dana describes the value of demonstrating an exploit in the real world rather than describing it at an abstract level. Certainly, from my experience, a developer is far more likely to implement a fix if they see their app being exploited with their own eyes. 

Dana takes us through an introduction to Postman Flows (a GUI state-machine-like interface to automate API tasks), how to use it to implement some flows such as password reset and OTP enumeration, and how to use the Flow Query Language (FQL). He then uses it to crack the OWASP crAPI password reset function. As usual, it’s an excellent read, taking you through all the details and the many lessons learned in this example. 

I’ve used Flows previously to do some very basic automation, but this gives a view of the advanced attacks that can be implemented using Flows. I am inclined to agree that the limitation in being able to export or share Flows is an unfortunate one; hopefully, the good people at Postman are planning updates on this one in the future.

Thanks again, Dana, for a great guide. 

The post Issue 231: API authentication bypass in Ivanti Sentry, Docker images expose API and keys appeared first on API Security News.

Breach: OpenSea API users warned of breach

The popular NFT trading platform OpenSea has warned certain platform users to rotate their API keys. Although few details are provided in their official release, they suggest that one of their vendors may have experienced a security incident that led to the disclosure of OpenSea API keys. At the time of writing, there is no further detail of the number of users affected or whether other data besides these keys is impacted.

The article speculates whether this breach may be related to a breach at the third-party vendor of a popular blockchain analytics platform. OpenSea themselves were among several crypto companies to experience leakage of customer emails in an incident in June 2022. As is common with email leakages, attackers may use them to launch spear phishing campaigns against platform users (or even third-party vendors).

Vulnerability: Flaw in Atlas VPN exposes user IPs

Infosec Magazine reports on a vulnerability affecting users of the Atlas VPN service that can potentially expose user’s IP addresses to an attacker or allow the attacker to control the VPN itself. The vulnerability was discovered by a user and confirmed by the vendor, who has advised users to avoid using the Linux VPN client until a patch is released. There is no report of this vulnerability having been exploited at all.

The vulnerability arises via an unauthenticated API in the Linux VPN client, which exposes a localhost API on port 8076. This API is meant to be used as an administrative interface, most likely from web clients in a browser. It is possible the designers were relying on the Cross-Origin Resource Sharing (CORS) protection of the browser. However, by executing a command instead of a request, the researcher demonstrated a proof-of-concept that bypassed this CORS protection. This proves the important security adage: always use a layered approach built on a defense-in-depth approach. Even a simple key or token could have prevented this attack vector.

Article: API fuzzing and why you should use it

One of the most effective approaches to API testing (including security) is to use an extensive fuzzing approach to detect deviations from intended behavior or failures with edge case data. Our next article from The New Stack features this topic in-depth and covers how the Schemathesis tool can be used for API fuzzing.

Fuzzing is a long-established approach in software testing that involves providing synthetic and random data to a system under test. In the case of web applications, it is perhaps somewhat ineffective as a test method, but against APIs with well-defined contracts and behaviors, it can be invaluable in detecting deviations from expected behavior.

The article describes the following benefits of API fuzzing for API testing:

• Error handling and resilience: Rather than letting your users discover how well your API handles malformed or unexpected data input, use a fuzzing engine to exhaustively test with a large, varied payload. By identifying weaknesses in handling unexpected data, the API developer can greatly improve the resilience of their API.
• Compliance and standards: Various regulations require a thorough testing regime and fuzzing is a good way to prove you meet these requirements.
• Third-party integration: If you are integrating with a third-party API, then apply fuzz testing to that API to see how it behaves before integrating with it.
• Cost-effectiveness: Fuzz testing can be fully automated at a massive scale and run within modern pipelines, eliminating the need for almost any human interaction.
• Security assessment: Most important, though, is the value of API fuzzing as a means of security testing. Fuzzing can identify various input validation vulnerabilities, including buffer overflow and injection attacks. It can also detect where the API has responded incorrectly to deliberately malformed input, such as invalid data formats or schema.

The article concludes with a showcase of the Schemathesis tool. This tool appears to offer a highly configurable and scalable approach to fuzzing both OpenAPI (REST) and GraphQL APIs. Some of the benefits include positive and negative tests, stateful testing, session replay, and various integrations with Python and CI/CD platforms. The tool can be run locally at the CLI or in Docker, or via a SaaS platform.

It’s always good to see new API security testing tools; this looks like a good one to add to the inventory.

Guide: Using Keycloak for RBAC in microservices

Next up is an article of interest primarily for Java developers wanting to integrate Single Sign-On into their applications. Keyclock joined the Cloud Native Computing Foundation in April 2023 as an incubator project and is a favorite as a cloud-native SSO server focusing on role-based access control (RBAC) across various complex landscapes from on-premises to full cloud-native cloud environments.

The article describes using the Keycloak server to implement an OpenID Connect authorization code flow using the Quarkus Java framework, which has its own OIDC connector. The tutorial shows the mechanics of setting up an application and getting it working with Keycloak for OIDC, and then gets on to the interesting topic of how to add RBAC security to REST APIs.

Keycloak seems to be an increasingly popular choice for SSO solutions, and this article shows how easily it can be integrated into an API.

Article: Exploiting APIs with prototype pollution

Next up is a real mind-bender of an article from Dana Epp on the topic of prototype pollution on Node.js, and how this can be exploited to create remote code execution (RCE) attacks. I’d recommend that the reader invest the time to work through the article as it’s definitely worth the effort; it took me a few reads before I understood what was possible.

Prototype pollution is a particular issue affecting JavaScript and results when a user can modify the prototype (a construct that allows JavaScript to manage inheritance) of an object. Essentially, if an attacker can modify the prototype of an object, they can change the underlying data object to something of their choosing. It’s not exactly like this, but it’s a fair approximation.

Dana describes how to test Node.js servers running the Express framework for susceptibility to a server-side prototype pollution attack (if you want to learn more, then Port Swigger have you covered). He then describes how to inject a dangerous payload (a script to open a reverse shell) and then inject that into an object’s prototype to get a reverse shell.

I’ve not had the time to try this myself, but I am quite fascinated by the mechanics of a prototype pollution attack (and why such a mechanism would exist at all ?) and will work through this and the PortSwigger labs in due course.

I will follow Dana’s advice though: “DO NOT RUN THIS ON A MACHINE CONNECTED TO THE INTERNET. YOU’VE BEEN WARNED.”

Guide: Using AI for API testing in Postman

The final article this week comes from Dana Epp again and covers the recent testing he did with the new Postbot features within Postman. Tl;dr: he found it to be a really useful tool in writing API test code in Postman. My own tests concluded that it’s likely to be quicker than I am.

API developers are used to using Postman to perform basic acceptance testing of their APIs while they’re coding them, but many are unaware of the powerful test automation features incorporated in Postman via the integrated scripting engine. Using this feature, creating custom scripts and checking the API responses for custom conditions and response codes is easy.

Recently, Postman got the AI buzz and added the ability to generate test scripts courtesy of an AI prompt familiar with the scripting framework. Simply describe your test requirement to the prompt (“check if the response contains a field called ‘CVV'”), and it does a pretty good job of writing the test code, certainly quicker than it would take me to read the manual.

Dana takes it to the next level with some of the scenarios he gave to Postman, such as: