Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Welcome to The researcher’s desk – a content series where the Detectify security research team will conduct a technical autopsy on vulnerabilities that are particularly interesting, complex, or persistent. The goal here is not to report the latest research (for which you can refer to the Detectify release log); it is to take a closer look at certain vulnerabilities, regardless of their disclosure date, that still offer critical lessons.

TLDR: Excessive Data Exposure (leaking internal data via API responses) is the silent, pervasive threat that is more dangerous than single dramatic flaws like SQL Injection. It amplifies every other API vulnerability (like BOLA) and happens everywhere because developers prioritize speed over explicit data filtering. Fixing it means systematically checking hundreds of endpoints for unneeded PII and sensitive internal data.

Picture this: it’s 3 AM, and your message broker is acting up. Queue depths are climbing, consumers are dropping off, and your on-call engineer is frantically restarting pods in a Kubernetes cluster they barely understand. Sound familiar? For years, we lived this reality with our self-hosted RabbitMQ running on EKS.

Our API scanner can test for dozens of vulnerability types like prompt injections and misconfigurations. We’re excited to share today that we’re releasing vulnerability tests for OAuth API authorization for organizations that use JWT tokens. These JWT, or JSON Web Tokens, are meant to prove that you have access to whatever it is you are accessing. One of the most critical JWT vulnerabilities is algorithm confusion.

Two months since I joined Detectify and I’ve realized something: API security is a completely different game from web application security. And honestly? I think a lot of teams don’t see this yet.