Tag Archives: XML

It started yesterday when I saw a message pass by on LinkedIn. (See below). 

The honest first thing I thought was ‘Are you effing kidding me?’ It was like an episode of comedy capers. I thought that this level of shortsightedness was a thing of the past, but it seems to me that people will get themselves into heaps of troubles for the longest of times. And what was that term “endless digital potential?” A call to arms for the stupid people? 

So here I am educating the wannabes and the short of cash people, because it is essential. An API is an Application Programming Interface. It is a set of definitions and protocols for integrating application software, or to ‘simplify’ this “a software intermediary that allows two applications to talk to each other.” It is a way for others to talk to your software or data. It allows access. To give another reference. You are about to connect an anchor to your boat. But there are Danforth anchors, plow anchors, fluke anchors and several others. It depends on the size of the boat and WHERE you tend to park that dinghy, that largely decides what kind of anchor you need, not what is the prettiest anchor, that tends to be a factor in losing your boat. 

To put it in a better way “digital potential” will be seen when you connect YOUR data to anyone else’s data. Did you consider that? You see this blinders approach to information is nice and those with dollar shaped pupils take notice and want to race to that digital potential, yet the reality is something less nice. It is the chapter of risk.

RISK
Risk is the number one consideration, there is no other. Is it worth doing ‘approach A’ to get to the finish of revenue? 

Bad coding
This is perhaps the largest foe. Right off the bat, if you start off with the premise of bad coding, you are exposing yourself to serious API security risks and that is an issue. But fear not this person thought of that. We are given “That’s why we designed IBSuite as API First!” Yes, really? Security risks are still a massive danger. Unrestricted access to sensitive business flows is the stuff nightmares are made of and a security risk will bring that to your front door. 

Inadequate validation
A security researcher discovered an API payload that would send invalid data to their own user process, which would repeatedly fail to be handled correctly. This error handling loop prevented further access to their user account. This is perhaps the smallest issue, the problem is that failure to handle something correctly implies that something goes somewhere else. Do you know where that somewhere else is? Consider that your former colleagues spend decades optimising the data you have now, would you like others to enjoy that hard work, or keep that in house? 

Hesitating over API utilisation
Some state that in big companies, sometimes management can neglect to track APIs and their utilisation numbers. From this point, you can incur many charges and leave yourself open to security risks due to exposed APIs. So not only are you in danger to hand over your data, you can get charged for it too. Utilisation of data and greed in one nice compact solution, who would have thought it possible? 

Accountability
This does sound like the odd duck out, but in reality it often connects to data loss, Since API’s connect external users and applications with a firm’s internal applications, they are potential paths to a firm’s data. If access to these paths is not controlled, data can reach the wrong hands – and can be stolen, modified, or even irretrievably deleted. So data could get copied and then deleted, to make sure it does not hinder YOUR storage. I wonder if they will charge you to hand the data back? Just a thought.

Risks of XML
I admit, this is the hardest one for me. It is not always easy to put your finger on XML, its usage is too widespread, in the 90’s it was never an issue, more of a fab for some. Yet, 3rd party APIs could be compromised and leveraged to attack other API services. Attacks such as SQL injection, XML External Entity injection, and more, should be considered when handling data from other APIs. This part tends to be tedious but essential. It is time consuming ground work, but it must be done. 

APl incompetence
This is harder for me, I have a massive lack of knowledge here, it is specific niche knowledge that the experts have, yet it amounts to the ability to have a fault-tolerant system. Consider that in the 90’s there was accounting software. If I used a specific expression, the program would crash. No biggie you would think, but at that point I ended being in THAT system, now completely open with supervisor privileges. I had access to the entire mainframe with access to everything. This was a specific setting that was solved 3 weeks later. But what happened when it was not found? Consider that your system is open to anyone that employs such a solution and they get access to everything including the porn pics of your wife and your data. I am willing to bet that option one was a lot more upsetting to you, weird that.

Lack of security
You would think that this is covered, but it is not. Akamai (a US cybersecurity firm) reported “Of note, fewer than 50% of respondents have API security testing tools in place. Even fewer have deployed API discovery tools. Although the survey results suggest enterprises recognise the security risks of widespread API usage, there is no clear consensus on where to prioritise investments”, this matters. Security should be everything when it is about your house and your data. 

This is all mere top-line header consideration. So consider the intro I reacted to and the lack of risks that it shows. So how much risk are you willing to take with your house and your data? If I was inclined to be that short sighted in promoting ‘digital potential’ I would have gone with “APIs are not required, but if you consider and adhere to the risks in a proper way, they are the safest way to connect and explore digital potential. Any eco-system has risks, which is why we designed IBSuite to be a safety first option in exploring the digital oceans for revenue you cannot see now, but to get there in a digitally safe way, one that keeps your data YOURS.” Is it as good? Perhaps not, but it instills value that you as a customer and the data YOU have is used for safe navigation and that matters.

This was a functional boat once, they chose the wrong anchor and in the wrong place that cost them their livelihood. What will you do? Look deeper, look better, look elsewhere? All good questions and it all started by understanding the risks of an API because everything has a risk, not looking at it implies you are taking too many risks with something you can only lose once.