APIs prove that security through obscurity doesn't work

Security through obscurity sounds intuitive: if you hide or obscure the workings of a system, attackers won’t know what or how to attack. After all, you can’t exploit something you can’t see, right? Unfortunately, in the real world, determined attackers are actively probing for these hidden components, and their tools can uncover assets that organisations themselves may have forgotten about.

One of the most overlooked examples is the Application Programming Interface (API). Unlike a graphical user interface (GUI), APIs are not immediately visible when you visit a website or use an app. Some might assume their obscured nature keeps them out of hackers' sights. But APIs are not invisible—they are discoverable, probeable, and if misconfigured or unmanaged, they become highly valuable attack vectors.

APIs: indispensable but often unmanaged

APIs have become essential to modern development, enabling websites, apps, and services to interact with external systems and extend functionality. But as their use has expanded, so too has their sprawl. What starts as a handful of well-documented APIs can grow into hundreds or thousands, often beyond the point where an organisation has full oversight.

According to Imperva's 2024 State of API Security report, the average organisation maintains over 600 APIs. Yet studies show that organisations often have 30% more APIs than they realise, as untracked or undocumented "shadow APIs" multiply without formal governance. These shadow APIs, if they go uncatalogued and unaudited, present silent entry points that attackers are actively hunting.

The real-world risks of invisible APIs

Assuming obscurity is protection leads to dangerous oversights. In the Dropbox breach of 2024, attackers used phishing to compromise GitHub credentials and access Dropbox’s internal repositories. There, they found stored API keys, which they used to exfiltrate sensitive data through Dropbox APIs. The breach wasn’t just about hiding keys—it was about the lack of robust API key management, monitoring, and validation.

Similarly, the 2023 T-Mobile breach exposed the dangers of unauthenticated internal APIs. Attackers discovered an internal API that didn’t require credentials and used it over a month-long period to extract the data of 37 million customers. The result? $31.5 million in regulatory penalties and security improvement mandates from the U.S. Federal Trade Commission.

These are not isolated stories. According to Thales, 71% of all internet traffic consists of API calls. APIs form a massive, often under-defended attack surface. Attackers know this—so much so that 44% of advanced bot traffic now targets APIs, especially in financial services, healthcare, and e-commerce. The annual financial impact of automated attacks against APIs is estimated at nearly $18 billion worldwide.

Insecurity through obscurity: why hiding isn’t protecting

While API obscurity might keep endpoints out of view from casual observation, it offers no defence against automated scans, fuzzers, or determined attackers. In fact, it can lead to what might be called "insecurity through obscurity": because teams believe APIs are hidden, they don’t enforce proper governance, authentication, or continuous testing.

The real issue is not just obscurity—it’s lack of visibility, control, and validation. Without clear inventory, many organisations can’t answer basic questions: How many APIs do we have? What do they expose? Who should have access? Are they properly configured? Are they tested regularly for exploitable vulnerabilities?

How to secure the growing API attack surface

Securing APIs requires shifting from passive assumptions to active, structured security practices. Organisations must:

● Discover and catalog existing APIs: Build and maintain a full API inventory, including shadow and deprecated endpoints.

● Define and enforce access controls: Ensure APIs use proper authentication and authorisation mechanisms.

● Integrate API security into the SDLC: Make API definition, documentation, and security testing a formal part of the development pipeline.

● Continuously test in runtime: API attackers live in your runtime. Static scans just don’t do enough. Start with dynamic application security testing (DAST) with API discovery and proof-based scanning to identify vulnerabilities that attackers can actually exploit.

Advanced DAST tools, like those on the Invicti platform, help organisations move from reactive to proactive security by combining continuous testing with automation and validation. This allows teams to cut through alert noise, focus on real risks, and harden their environment before attackers strike.

The takeaway: visibility is non-negotiable

Attackers will always find weak points—the question is whether enterprises can see them first. To defend against the all-seeing eye of cybercriminals, organisations must achieve full visibility into their API ecosystems, embed security controls across the lifecycle, and leverage automated testing to continuously harden their defenses.

Security through obscurity isn’t a strategy. Security through visibility, validation, and governance is the only viable path forward.