Lessons from Trello’s API Exposure: Securing Your API Endpoints

Published: December 4, 2024

In January 2024, Trello, the popular project management tool owned by Atlassian, fell victim to a significant security lapse. A threat actor known as “emo” released over 15 million email addresses associated with Trello accounts, collected via an unsecured API. This breach underscores the importance of securing APIs against unauthorized access and misuse. Here’s a breakdown of what went wrong and how organizations can protect their APIs from similar vulnerabilities.

The Breach: Exploiting an Unsecured API

The offending Trello’s API allowed developers to query public information about user profiles based on Trello ID, username, or email address. Emo exploited this unsecured API endpoint by feeding it a list of 500 million email addresses, determining which of these addresses were linked to Trello accounts. The result was a dataset containing email addresses and public Trello account information for over 15 million users.

The leaked data, while primarily consisting of public information, also included non-public email addresses, which can be leveraged in phishing attacks and doxxing. This type of data breach highlights the risks associated with unsecured APIs, which can be misused to compile detailed profiles from seemingly benign public information.

What Went Wrong: Lessons for API Security

Unsecured API Endpoints (OWASP API1:2023, NIST PR.AC)

The core issue in this breach was the presence of an unsecured API endpoint that allowed unauthenticated users to query for sensitive information. This falls under OWASP API1:2023—Broken Object Level Authorization, which emphasizes the necessity of proper authentication and authorization controls on API endpoints.

The NIST Cybersecurity Framework’s Protect (PR) function also stresses the importance of securing access to sensitive information. By requiring proper authentication, Trello could have prevented unauthorized users from accessing and exploiting user data through their API.

Lesson learned: Secure API endpoints with robust authentication mechanisms to prevent unauthorized access to sensitive data.

Excessive Data Exposure (OWASP API3:2023, NIST PR.AC)

While Trello’s API was designed to handle public information, the breach revealed how such endpoints can be abused to gather non-public data, such as email addresses. OWASP API3:2023 highlights the risk of excessive data exposure, where APIs may inadvertently provide more information than necessary.

NIST’s Protect (PR) function also underscores the need to minimize data exposure by ensuring that APIs only return the information required for their function. Even public data can be dangerous when combined with other information, as demonstrated by this breach.

Lesson learned: Limit the scope of data exposed by APIs to reduce the risk of misuse and ensure that only necessary information is accessible.

API Rate Limiting vs. Authentication (OWASP API4:2023, NIST PR.AC)

Trello’s initial response involved securing the API, but the incident highlights a common pitfall: relying solely on rate limiting to protect APIs. While rate limiting is important, it can be circumvented by threat actors using proxy servers to rotate connections and evade limits.

OWASP API4:2023 emphasizes the importance of implementing rate limiting as part of a broader security strategy, but it should not be the sole defence mechanism. NIST’s Protect (PR) function also advocates for a comprehensive approach to access control, combining rate limiting with strong authentication measures.

Lesson learned: Use rate limiting in conjunction with other security controls, such as strong authentication and authorization, to protect your APIs from abuse.

Monitoring and Auditing (OWASP API4:2023, NIST DE.DP)

Effective monitoring and auditing are crucial for detecting and responding to potential abuses of APIs. In this case, Trello could have identified the misuse of their API sooner with robust monitoring systems in place. OWASP API4:2023 stresses the need for monitoring to detect and respond to unusual activity.

The NIST Cybersecurity Framework’s Detect (DE) function also highlights the importance of continuous monitoring to identify and address security incidents. By implementing detailed logging and alerting mechanisms, organizations can better detect and mitigate API-related security issues.

Lesson learned: Implement continuous monitoring and logging to detect suspicious API activity and respond to potential security incidents promptly.

How Solsys Can Help

At Solsys, we understand the evolving threats posed by unsecured APIs and we are dedicated to helping organizations fortify their systems against similar breaches. Our API security solutions are designed to identify and close gaps in your API infrastructure, ensuring that access controls are strong, data exposure is minimized, and any potential vulnerabilities are addressed proactively. With our comprehensive monitoring and auditing tools, we help organizations detect suspicious activity in real time, preventing misuse and securing sensitive information before it’s compromised.

Whether you’re looking to implement better authentication mechanisms, limit data exposure, or strengthen your overall security posture, Solsys has the expertise and solutions you need. By partnering with us, you can safeguard your APIs, protect your users’ data, and avoid the kind of exposure that Trello experienced. Connect with Solsys.

Marek Suchomski is a Technical Account Manager at Solsys, where he has been dedicated to helping clients leverage Splunk deployments for over three years. With a strong development background, Marek brings a deep understanding of both the technical and business aspects of the industry. As both a manager and a Splunk-certified Admin, Marek is committed to assisting his colleagues in navigating the evolving landscape of cybersecurity.