With the accelerated pace of digital transformation following the dawn of the COVID-19 pandemic, many organizations and leadership teams are asking themselves this question: “Should we launch a public API channel?” Imagine the reaction from your stakeholders when they learn that your partners and competitors are already using your APIs to power their offerings without any mechanism to charge or even track this usage.
What many enterprises don’t realize is that they already have a public API channel that’s being used by would-be partners and even competitors because the current application development patterns in IT groups rely on public APIs to power their web and mobile applications. If you have a consumer-facing mobile app, you have an API. If you have a website, you have an API. It may not be tracked, or easily consumed but that doesn’t mean it’s not out there and being used because when it comes to developers, where there’s a will, there’s a way. Rather than waiting around for consequences of ungoverned API usage, it’s time to get out of public API denial and create an intentional channel.
Over the last few years, I’ve helped enterprises around the world chart their paths to bringing a public-facing API portal to market. While each enterprise has a different business context and a unique take on how to generate customer and enterprise value — one thing is the same across the board: they already have a public API program that they weren’t aware of. I’ve been on the calls where every person regardless of role or level denied it. Then weeks later, the truth is revealed: Many enterprises have APIs that their stakeholders readily consume in an untracked and uncharged fashion.
The not-so-invisible channel
How is it possible that major enterprises have a public API channel that they don’t know about? It turns out that there’s a not-so-invisible back door embedded within public-facing websites and mobile apps as well. Not only is this backdoor there for any developer motivated enough to look for it, it’s a widely accepted practice that’s endorsed by technology professionals and enterprises as we speak. The issue isn’t that enterprises use APIs to drive their web and mobile applications. It’s not even that the URL addresses are readily accessible by external parties. The problem I’m referring to is that a wide array of enterprise business and technology leaders have not connected the dots enough to understand that they’ve effectively made their APIs publicly available infrastructure that can be used by anyone for free.
The emergence of the low-profile public API program started 20 years ago when AJAX (Asynchronous JavaScript and XML) first became available and kicked off the start of what was then known as “web 2.0.” The technologies have been refined and renamed, but the basics of the pattern have become the defacto standard for creating highly responsive web applications and have been applied to become the foundation of mobile application communications as well.
Whether it’s a web page, a mobile application, or a web page encapsulated within a native mobile application, the details of API endpoints and client credentials are often available within a few minutes for a mildly motivated developer. For a host of reasons, advanced obfuscation techniques and strategic scraper defense programs rarely make it above the line as teams work towards bringing their offerings to market. The end result is that many organizations have a shadow API offering that is essentially unmanaged and unmonitored. If you are wondering if and how this applies to you, here’s a simple flow chart to help you get your bearings:
Even your BFF needs good boundaries
Once an organization begins development on data-rich mobile experiences or an omnichannel program that delivers consistent experiences across audience touchpoints, the need for a composite API strategy emerges. Enterprises around the world are discovering this need as the push for digital transformation becomes more prevalent in every industry context. Whether it is intentional or serendipitous, the desire to conserve development and operations cycles has driven the Back-end for Front-end (BFF) architectural pattern popularized by Sam Newman and Phil Calçado to become the norm in an ever-widening set of enterprises and startups.
While the BFFs (and the APIs that power them) have become a popular pattern with development organizations, the presence of the BFF doesn’t always come with an approach to manage the inevitable data leakage that comes from digitally delivered experiences. Regardless of where you stand on the political subject matter in the content, the systematic scraping of Parler content this past week has shown just how badly it can go when your API management capabilities are not up to the challenge of reasonably protecting the data keeps your organization competitive in the marketplace. Due to a lackadaisical approach to data security, 100% of all user data and posts including deleted posts were scraped, downloaded and shared with US law enforcement.
This vulnerability isn’t new to everybody. Many media properties have scraper defense strategies that don’t rule out BFFs. A frequent pattern is to have pages access data via server calls rather than client calls which then allows enterprises to put “allow lists” in place while simultaneously opening up governed API portals. An important distinction in this strategy is that nobody successfully stops the scrapers. The smarter and more tractable play is to channel, monitor and govern them via a structured data monetization offering.
Yesterday’s luxuries are today’s necessities
All too often technology teams adopt business team narratives that neglect to account for the realities of the modern world. Business teams claim dominance on “the what” and presume to have the best judgement on which capabilities are necessary and which ones are “nice-to-haves.” This pattern of decision making that emphasizes short-term wins at the expense of long-term concerns is more out of balance than in past times because:
- The clock speed of technology and business has accelerated and continues to accelerate which means “long-term concerns are manifest in ever-shortening calendar time cycles.”
- The trend of “phase 2 items that never make the cut” is the everyday status quo in many enterprises around the world.
With this newer context in mind, a few capabilities that were once considered luxuries, should be elevated into the realm of necessity. To be clear, this does not mean that all necessities are MVP or V1 worthy. Moreso, this means that data security measures to mitigate the risk of API mining (e.g, API management, rate limiting, secure by design policy enablement, API specific traffic monitoring, “defense in depth” security practices embedded within network and/or infrastructure, etc.) must move into the zone of “non-deferrable scope” where firm roadmap commitments need to be articulated and “have teeth” sufficient to hold the forces of “revenue above all else” at bay.
Within the context of prioritizing enterprise capabilities, it can be difficult to have the persistence necessary to shift the posture of distributed teams on the balance between architectural capabilities and generating revenue. At the same time, the need to elevate the topic of data security is becoming more self-evident every day as data breaches become more and more frequent. Even in the context of “internal” APIs, small errors and missteps can render your enterprise vulnerable to leaking valuable or sensitive data. While it is true that no one person can solve this problem for an enterprise, it is also true that this doesn’t relieve us of the responsibility to do what we can, from where we sit within the enterprise. Whether you manage a team, a platform or even the products that consume and distribute data, you have a role to play.
If you work in an enterprise that believes “we have no public facing APIs,” do these three things:
- Think again and validate exactly how APIs power your customer experiences.
- Reach out to the MuleSoft team to learn how your organization can take advantage of broadest and deepest deployment of “secure by design” API infrastructure across the largest customer base globally.
- Start to develop the enterprise appetite to inventory, control and govern your data assets that are accessible via API. Because in this case, what you don’t know can hurt you.
