Frankenstein APIs Explained!

Unknown APIs can be scary but not every API is a monster.

This is part of the API Cybersecurity 101 series by Software AG's Senior API Strategist, Brenton House. A continuing series on API Security and Cybersecurity.

You may have never heard of a Frankenstein API. But there is a good chance you have used one at some point. It is important to know what a Frankenstein API is because your API Security could depend on it.

A Frankenstein API is one that is created in the deepest depths of a dark and secret laboratory.

No. Not really.

But this type of API is usually creatively pieced together using unorthodox methods and is driven by a strong need for functionality.

So let’s start with the basics.

What is an API?

The acronym API stands for Application Programming Interface. Basically, it is non-human systems (or applications) that talk to each other in an agreed-upon way! Most often, people are talking about Web APIs, which include things like REST, GraphQL, gRPC, SOAP, etc. The introduction of smartphones caused an exponential growth and adoption of APIs as pretty much every single mobile application uses APIs.

What is API Security?

The simple answer is that it is about applying and managing security for your APIs but we all know, there is nothing simple about API Security.

There are 7 basic categories for APIs.

• Public APIs
• Internal APIs
• Partner APIs
• Composite APIs
• Shadow APIs
• Zombie APIs
• Frankenstein APIs

So what is a Frankenstein API?

What happens when you really need an API for something and that API does not exist?

Take for instance Google Public Search Results (SERP) API. Have you ever used it?

Me neither. It doesn't exist.

That doesn't mean that people don't need APIs like this though. You may have used services that provide APIs to show you how your website (and the websites of others) rank for certain keywords and queries.

Another example might be where a web application product has an API but it is very limited and doesn't provide access to all the information and functionality that the corresponding web application does.

This is another example where someone might end up building an API.

Now when I say building, I really mean piecing/hacking/cobbling it together using unorthodox and unconventional methods such as screen scraping and other techniques. When done right, these can provide the valuable data that wasn't provided by the original product but it comes with many risks...

Some of the risks to be concerned about stem from the fact that this API was not created by the same organization that created the original product.

Frankenstein APIs can be extremely fragile

A Frankenstein API does not have the insider information needed to make the API stable and durable. For instance, ~~if~~ (sorry, WHEN, not if) Google were to change how search engine results were laid out or presented, then every Frankenstein API that was created by scraping the Google Search Engine Results Pages (SERP) would most likely break (depending on the how major the changes were).

Frankenstein APIs can bypass product security

If a Frankenstein API was created to fill the gap created by missing features in the original product, it is very possible that the mechanism for scraping the data and compiling it into an API would be bypassing security. What I mean by that is the resulting Frankenstein API would not require the same security that the scraping tool (or another mechanism) was required to provide in order to retrieve the data from the original application.

Frankenstein APIs can cause undue load on resources

There is no guarantee on the experience level of the developer (or developers) that creates a Frankenstein API. Since they are not part of the organization that created the original application, the techniques used to "retrieve" the data may be, well... less than optimized. The code in a Frankenstein API could be eating up all kinds of resources owned by the original application owner. Calls could be taxing servers, bandwidth, and other resources that all result in lots of money.

Frankenstein APIs could expose vulnerabilities

This one is not strictly limited to Frankenstein APIs but you could be asking for problems. Once you have an external developer or hacker digging through your applications looking for a way to capture the data they need, they could discover vulnerabilities in your system that would not have been found otherwise. Vulnerabilities can be found by hackers not creating Frankenstein APIs but it would be wise to not create more opportunities.

API First to the rescue

A solid API First strategy can be helpful in avoiding some of the problems that arise due to Frankenstein APIs. If your organization treats APIs like a Product and always creates an API First, BEFORE creating an application, you can engineer security into a proper API, thus alleviating the need for a Frankenstein API.

NO API FOR YOU!!

If you absolutely insist on not providing an API for the users of your applications, you will need to take precautions. By the way, I DO NOT recommend this option!

You will need to have very advanced mechanisms in place to protect your web applications (and other sources of data) from screen scraping and other data retrieval mechanisms. This can be tough to do and you will have to be constantly changing it in order to keep of with the latest data retrieval techniques.

This is not to say that you don't need to protect against screen scraping if also provide an API but it may remove a lot of the motivation for creating a Frankenstein API if you provide a proper API along with your application.

I am not saying Frankenstein APIs are bad, more misunderstood.

My point is for you to be aware that they exist and to treat them with care, especially in terms of API Security.

About Brenton House

Brenton House is Vice President of Digital Evangelism at Software AG. As an API and Digital Transformation Evangelist and Strategist, he has connected enterprises with API solutions and microservices, to help drive innovation and overall business growth for many organizations.

In his 25+ years of experience, he has worked across many industries including broadcasting, advertising, retail, financial services, supply chain, transportation, technology, and publishing -- gaining a breadth of knowledge on all things APIs and Integrations. His diverse experience set and unique creative skill sets have enabled him to equip organizations in creating captivating and innovative products that delight users.

👉    Connect with Brenton House on LinkedIn!    👈

Check out some of our other resources to continue learning more about APIs and Integrations!

⭐    Software AG Blog ▪ https://blog.softwareag.com
⭐    API Knowledge Portal ▪ https://knowledge.softwareag.com
⭐    Software AG Tech Community ▪ https://techcommunity.softwareag.com/
🎬    Software AG YouTube Channel ▪ https://youtube.com/softwareag
🎬    Brenton House's YouTube Channel ▪ https://youtube.com/brentonhouse
🎬    API Shorts YouTube Channel ▪ https://youtube.com/apishorts

👇👇👇    FREE online API Maturity assessment here!    👇👇👇

https://www.softwareag.com/api-maturity