Issue 229: Incidents with DuoLingo and JumpCloud, FastAPI for APIs, and five best practices


This week, we have news of two API security incidents: the reported leakage of the data of 2.6 million DuoLingo users and an incident at JumpCloud that resulted in resetting customer API keys. For the technically minded, we have two guides: the first discusses how to use API keys in an ASP.Net Core application, and the second covers the excellent FastAPI Python framework. We have an article on five best practices for API security, and once again, we conclude with two articles from Dana Epp.

Incident: Data of 2.6 million DuoLingo platform users leaked

First up this week, we have coverage of the ongoing data leakage affecting users of the DuoLingo language learning platform. According to the report in the Infosecurity Magazine, the personal data of as many as 2.6 million users has been leaked on a hacking forum. The information included real names, login identifiers, email addresses, and many internal metadata items, including courses taken, progress, rankings, etc.

The leakage was highlighted to DuoLingo, who responded by saying that the information was available via public profiles and did not represent a compromise of their systems. The fact that email address information was leaked is concerning since this indicates the validity of the email, which can allow targeted phishing attempts. Since an attacker could link an email to a user’s DuoLingo account, they greatly increase the chances of a successful attack since the victim will be more inclined to believe an email for a service they subscribe to. The data surfaced on the Breached hacking forum and was available for the grand sum of $2.13.

The root cause of the leakage was a totally unauthenticated public API taking an email address as a query parameter. By querying this API with email lists, the attacker could quickly build up a database of users. Suffice it to say the API endpoint also did not provide any form of rate limiting to thwart efforts such as mass exfiltration.

At the time of writing DuoLingo has made no effort to remove or restrict the API. The API was still very public and revealing personal data on DuoLingo. DuoLingo says that account closure requests will be actioned within ten working days. Stay tuned for an update. If you have an account and want to check your own email, here is where you find further details.

Incident: JumpCloud resets customer API keys

The other incident covered this week is the apparent incident affecting JumpCloud, a cloud services provider. Although few details of the incident are known, the upshot was that JumpCloud reset all of its customers’ API keys “out of an abundance of caution”, as they described it in their official communications.

Whilst we can only speculate as to the nature of the incident, it is likely to have been quite serious in nature for this step to have been taken by JumpBox. Whilst they mitigate the immediate risk of access by an unauthorized 3rd party using a leaked key, they create another not-insignificant problem, and that is the redeployment of the new keys to downstream systems. Unless their customers had planned for this activity specifically in their recovery plans, this could be a significant undertaking.

This highlights the importance of API keys in today’s API-based systems: firstly, they must be protected from leakage, and secondly, organizations are well advised to have a key rotation plan.

Guide: Using API keys in ASP.Net Core applications

The next guide will hold appeal for any ASP.Net Core developers and focuses on how to use API keys within their .Net Core application. This brief guide focuses on the two most common methods of validating API keys: using the built-in key validation middleware or using custom attribute decorators.

To use the middleware approach, the developer implements a single key validation method that checks the key against all known values and returns a pass/fail. All that needs to be done to use this method is to make a single method call in the application setup to inject this handler into the request flow; the rest will be handled transparently by the .Net core engine.

To use the custom attribute method, the developer implements a single key validation method that checks the key against all known values and returns a pass/fail. It is important to ensure that this method derives from the Attribute class, allowing it to be used as a decorator for endpoint methods. To add this to a handler, all that needs to be done is to add the appropriate decorator to the endpoint method, which will cause it to be invoked on every endpoint call.

Why would you use one over the other? It’s a trade-off: using the middleware ensures that the authentication check cannot be omitted accidentally, while the custom attribute method allows a more granular level of control. It’s up to the designer which suits their needs better.

Guide: Using FastAPI to build secure and performant APIs

The next developer-focused article is for our readers writing Python implementations and showcases many of the fantastic features of the FastAPI framework. Personally, I have been using this framework for the last few months, writing samples for my API security book, and I can attest to the power of this modern, performant framework.

This DZone article focuses on some of the key benefits, including:

  • Unmatched Performance: FastAPI (the clue is in the name) is fast due to the Starlette high-performance asynchronous framework at its core. It’s worth noting that it is fast relative to other Python frameworks; if you want to get a better idea of how it ranks against others, here is a great comparison.
  • Type Safety and Documentation: As much of a fan of Python’s run-time typing as I am, it undoubtedly leads to fragility at runtime. FastAPI uses the Pydantic typing system to clearly define and enforce the data types for requests and responses. This aligns perfectly with the drive toward adopting the OpenAPI specification in defining API data types.
  • Security and Authentication: My favorite aspect of FastAPI is the excellent built-in support for many security features, particularly the wide support for authentication and authorization mechanisms.
  • Scalability and Extensibility: FastAPIs asynchronous design allows for very effective horizontal scaling, and its modular design allows for easy integration with other libraries and frameworks.
  • Automated Testing and Debugging: FastAPI has excellent support for native Python test frameworks such as pytest and pytest-bdd, making it easy to write tests for your APIs as you implement them.

If you are starting out learning about APIs and/or Python, I can heartily recommend the FastAPI framework. Thanks to DZone for a great article.

Article: Five best-practices for API security

There is no shortage of guides on best practices for API security, and they are always a favorite with our readers. This week, we feature a really good one from RTInsights with some interesting takes on some common themes. The author highlights the rise in API security incidents, citing the following as concerns for API security:

  • Mismanagement of API tokens and keys (see the second article in this newsletter)
  • The increase in DDoS attacks globally
  • Easily accessible credentials such as usernames and passwords
  • Machine-in-the-middle (MitM) attacks

The author recommends the following five best practices for improving API security:

  1. Assess your organization’s infrastructure and processes: As often stated, you cannot secure what you do not know. The first step is to build a full view of the inventory of your organization’s APIs, including internal and external APIs and, of course, third-party APIs.
  2. Pay attention to data security in the cloud: Beware of the increased attack surfaces resulting from cloud service adoption. Even if your API itself is secure, it may be vulnerable if built on top of poorly configured cloud infrastructure.
  3. Make multi-factor authentication a requirement: Usernames and passwords are no longer sufficient for secure access in 2023; ensure that you use some form of MFA and resilient authorization framework such as OAuth.
  4. Ensure the right users have access to the right data — and no more: Readers of this newsletter will be familiar with the high number of instances of excessive information exposure seen in breaches. Often, it’s clear that the API designers have failed to understand the privacy requirements related to data that is obviously PII and should have restricted access.
  5. Secure certificate keys in a keystore: Moving to mutually authenticated certificates adds another layer of security, but do ensure these certificates are stored securely in an appropriate keystore.

Thanks to the author for an interesting take on some familiar themes.

Guide: Creating reverse shells with cURL

You just cannot keep Dana Epp out of this newsletter, and in the first of two guides this week, he discusses how to create a reverse shell using the cURL utility. For those not familiar with the dark side, a reverse shell is one of the most prized discoveries for a hacker — effectively, this is opening a back door on a system that a hacker can then use to further exploit the system. Think of it like leaving a shell session open on your computer, allowing anyone with access to that shell session to do anything they wish to your computer.

Dana describes exploiting a command injection vulnerability (these are all too frequently encountered on APIs) to then use cURL to create a reverse shell. For this article, he takes us on a detailed journey using a vulnerable test app he created.

Why use cURL over tools like netcat and socat? The latter are often identified as dangerous tools and removed from restricted environments (in my past life, it was a severe policy violation to even have these tools on your machine). cURL, however, is just a boring HTTP client, right? It is until Dana gets hold of it !

Another great article, and I’d recommend a deeper read to see how easy this exploit really is. Also, a great shout-out to ngrok, a must-have tool for any API tinkerer.

Guide: Using Burp’s Bchecks for API security testing

Dana’s second article this week is a topic close to my heart: using the awesome new Bchecks capability within BurpSuite to assist with API security testing. For those unfamiliar with BurpSuite, this is the preeminent web application hacking tool produced by PortSwigger in the U.K. Part of its immense popularity is its extensibility facilitated by its plugin architecture — there is a marketplace plugin for almost anything you could wish to accomplish. However, there is a barrier to entry to create plugins, and that is some development knowledge using Java.

Fortunately, PortSwigger recently added a scripting engine into BurpSuite to allow users to write so-called Bchecks scripts that execute within BurpSuite, and can output their findings into the reports and output logs. The scripting language is simple to understand and quite powerful, hopefully enabling almost anyone to write custom tests.

I would simply refer readers to Dana’s article, where he shows how to test for the following:

  • Detecting API calls with a missing authorization header.
  • Checking to see if a security.txt file was published on the server.

I would love to hear more from readers on where they think Bscripts could be used to enhance API security testing from a defensive perspective. If anyone knows of repositories of great API-centric scripts, please do reach out so I can share them. Or please create your own and let me know.


Get API Security news directly in your Inbox.

By clicking Subscribe you agree to our Data Policy