Bug bounty programs continue to prove their value by helping organizations uncover security flaws that would otherwise slip through the cracks. For those of us in cybersecurity, reading through responsible disclosure (bug bounty) reports is both educational and a great way to demonstrate risk in real-world terms.

Today’s post highlights a fascinating discovery in Mozilla’s Firefox Accounts system—a bug that underscores the critical importance of API security and authorization checks, especially in Single Sign-On (SSO) workflows.

This might be the first in a series of posts if people find value. Let’s dive in.

API Security: Still a Hard Sell

Helping organizations understand the risks tied to insecure APIs is no small feat. Many teams rely on static application security testing (SAST) or commercial tools and assume that’s “good enough.” But as this case demonstrates, business logic flaws can sometimes fly under the radar when it comes to assigning permissions by role.

Account creation typically involves assigning default permissions based on the user’s role. For example, a standard user might have access to view and update reports, while a manager may be granted the ability to delete or assign users who report to them. A violation generally occurs when a user with lower-level permissions is able to perform actions reserved for higher-level roles. For instance, it would be a violation if a viewer has the ability to delete users under their manager. Testing all possible permission combinations can become increasingly complex, especially as the number of roles grows.

That’s where bounty hunters come in—offering a second set of eyes that can save companies from substantial losses.

The Vulnerability: IDOR in Account Deletion

Security researcher z3phyrus submitted a report to HackerOne detailing an Insecure Direct Object Reference (IDOR) in the Firefox Accounts API:

api.[sub-domain].firefox.com/v1/account/destroy

In layman’s terms, an IDOR allows an attacker to perform actions on resources they don’t own—like deleting another user’s account—by simply changing identifiers in a request.

This class of vulnerability is listed in the OWASP Top 10 and is unfortunately still very common. Let’s explore how this one worked.

What Made This Attack Special?

Here’s how it worked (non-technical version):

1. An attacker signs up using SSO (e.g., Google).
2. They intercept their own account deletion request using a tool like Burp Suite.
3. They modify the request and replace their own email with the email of another SSO-based user.
4. The system, lacking additional validation, deletes the victim’s account—no password, no session ownership required.

Let that sink in: the attacker doesn’t need the victim’s credentials or access to their SSO provider—just their email address to be successful.

Initial Rejection… Then Recognition

Mozilla initially downgraded the report to “Informative,” noting that the victim’s authPW (a password-derived value) was required to exploit the issue. They reasoned that obtaining this value would require access to the victim’s Mozilla account—meaning the attacker would already have the necessary access. To expand on that, the authPW is a password-equivalent value derived as part of Mozilla’s account architecture. It’s typically only known to the legitimate user (or someone who already has their credentials). So, Mozilla at first believed that the attacker would need direct access to the victim’s email and password-derived value, which meant the attack was essentially no different from just logging in as that user — thus not a security issue.

But this missed a key detail: SSO-based accounts don’t require a traditional password. So the token used by the attacker, while valid for their session, could still trigger actions against someone else’s account.

To Mozilla’s credit, they reopened the report on their own within a day, re-evaluated the impact, and ultimately:

• Rated the bug as High Severity (7.0–8.9 CVSS)
• Awarded $6,000 to z3phyrus

Real-World Risk

This vulnerability highlights how something seemingly small—like omitting an authorization check—can escalate into a significant business risk. Let’s break down the impact in practical terms.

1. Scope of Potential Victims
Assuming the same vulnerability existed in your companies’ environment, if a large portion of your users sign in using SSO providers like Google, Apple, or Microsoft, they may be vulnerable. Simply knowing their email address could be enough for an attacker to delete their accounts. Organizations should quickly assess how many of their users rely solely on SSO to determine exposure.

2. Mission-Critical Access
How critical is access to user accounts in your business model? If your platform plays a key role in your users’ daily operations—say, in e-commerce or SaaS—then losing access could mean real revenue loss or operational downtime.
For example:

A company generating $3 billion in annual e-commerce revenue could lose $5M–$8M daily if 60% of their customer accounts were deleted or disrupted.

Compare this to a B2B manufacturer using their site mainly for support or marketing—where the disruption might be less urgent.

3. Likelihood of Exploitation
This bug requires no direct interaction with the victim, and could be weaponized with basic automation. Given how many data breaches include leaked emails, attackers would have no shortage of targets. With automation scripts, the ease of execution increases the likelihood significantly.

4. Risk Transfer Consideration
If your organization determines that the financial risk is too high to absorb, consider transferring it via a cyber insurance policy. But that should be considered after a thorough Business Impact Analysis (BIA) or formal risk assessment has been completed.

Change Your Managerial Mindset about Security

Learn how you can be a better advocate for your Cybersecurity Program

Learn More

Business Impact Questions to Ask:

Asking targeted questions can help assess how much attention a specific event requires. Consider the following questions when evaluating a vulnerability similar to the one identified here:

• What percentage of your users rely on SSO (Google, Microsoft, Apple)?
• How mission-critical is continuous account access?
• What would the cost be if even 5–10% of accounts were deleted in a targeted attack?

Key Takeaways

✅ What Went Well:

1. Professionalism & Clarity from the Researcher
   z3phyrus stayed calm, professional, and focused on clarity—not confrontation. This is a great example of what bug bounty communication should look like.
2. Mozilla’s Responsiveness
   Mozilla re-evaluated the report quickly, provided thoughtful replies, and demonstrated that they take responsible disclosure seriously. They didn’t just fix the issue—they engaged with the process in good faith.

✍️ What Could’ve Been Better:

The original report might have benefitted from a clearer summary. It wasn’t immediately obvious that only the attacker’s session token and a victim’s email were needed to exploit the flaw. A single clarifying sentence could have avoided the initial misclassification.

That said, the quality of the report was still strong—and the clarification helped Mozilla reassess accurately.

🙌 Final Thoughts

This bug was a unique and high-impact find. More importantly, it shows that:

• Even mature vendors can miss edge cases
• API endpoints must verify authorization, not just authentication
• Civil, well-documented disclosures benefit both parties

Big thanks to z3phyrus for their professionalism and to Mozilla for exemplifying how a solid responsible disclosure program should work.

💡 Want More?

If this kind of content is valuable to you, let me know—I’d love to turn it into a series. Responsible disclosure is a vital part of keeping the web secure, and there’s a lot we can all learn from it.