The Ease of API Coding vs API Security: Key Considerations – 

“Make haste slowly” was something I learned about learning. The Latin phrase is “Festina lente” (Latin always makes things sound scholarly). Take the time to pay attention to detail in the beginning, and along the way one avoids foundational mistakes and completes tasks sooner. The same applies to API coding, and here are several considerations in the overall milieu of API coding.

Also Read – What are Advantages of Investing in Mobile App Development?

Code Quality –

Anyone can learn to create APIs, even for free. This and numerous other helpful resources, including ready-made APIs, make the barrier to entry for API use very low. An inherent drawback to any passive learning (when one doesn’t have direct contact with a teacher or mentor – an all-too-common occurrence) is that the deeper disciplines involved in creation by considering a 360-degree view of the business and customer needs get lost. Any kind of code learning is preferable to none, but that’s not the complete and end goal. The end goal (at least in part) is clean, useful, and secure code.

I’m reminded of the first tenet of the Zen of Python: “Beautiful is better than ugly.” Code should be easy for others to follow (this is important, especially if you want to take a vacation). If it can be beautiful, that’s even better.

Following available API documentation is part of achieving readable API code. One example of artful documentation Is Twitter, and one tool for creating beautiful documentation is Swagger.

In the book “Advanced API Security: OAuth 2.0 and Beyond”, author Prabath Siriwardena writes, “All in all, a connected system, not planned/designed quite well, could easily become a security graveyard.” Well-designed code is part of the path to secure code.

Secure Code –

There’s more to secure code than just writing it so it looks good and others can follow. APIs need to consider items such as input validation, data length, and error handling. API security also needs to include at least the triad of confidentiality, integrity, and availability, but due to its complex nature it requires extra attention. Among the many resources available is the Salt API security best practices checklist, which contains an overview, guide, and spreadsheet.

Another good resource for learning API security is this project from OWASP, which is a purposely vulnerable B2C application for finding API flaws.

Secure infrastructure –

API code can be better secured, but there’s even more to securing the API than just secure code. Three areas for better securing APIs are Development, Staging, and (especially pertinent) Runtime. Additionally, there are a traditional four pillars of security management: Administration, Authentication, Authorization, and Auditing.

Whatever the API architecture (e.g., REST, GraphQL) or usage (e.g., Private, Public), and whatever the infrastructure choices, the virtual or physical hardware must be able to handle the demands of the API activity, management, and maintenance.

Threat Modeling –

Think of “What if?” scenarios. What if the app is slow? What if the app gets DDoSed? What if the UI looks outdated? What if the UX is not on par with other UXs in the industry? What if the API is vulnerable and gets breached?

Businesses must consider all angles of any product or service and determine the ROI of investing in API technology. Based on the questions above, change the “What” to “How much would be lost…” How much would be lost if the app is slow? All the way down to “How much would be lost if the API gets breached?”

While threat modeling receives some criticism, it’s a natural part of any process. Don’t hold back; make it a reality in API development.

What if API code is not secured? 

Let’s look at a couple examples.

1. Consider the Uber vulnerability found by security researcher, Anand Prakash. In this case, due to a lack of authorization, Anand was able to discover the private information of any Uber account by knowing only their phone number or email.

2. Consider the John Deere API leak. This page provides an excellent review of the process used to discover API security vulnerabilities. Here, a security researcher was able to extract the names of many who owned John Deer equipment.

A fascinating aspect of both examples is that the tools used were most, if not all, free. Remember that criminals have the same opportunities to learn and “test” as the protectors, but with fewer boundaries.

Challenge –

One obstacle to implementing security is that it slows down the process. A rebuttal to that is to think of what people do every day to secure their physical lives. We lock doors and windows and ensure the stove is off before we leave the house; lock our car doors, lock our locker at the gym, get our vehicles maintained – the list of the extra time and money we spend every year is extensive, yet we have made if part of daily life so that we are reasonably secure.

Businesses should make securing their products part of daily life.

Third-Party Vendor Monitoring –

One of the largest risks is not monitoring for dependencies. This isn’t to say that third parties are suspect, but rather that, because one doesn’t have direct contact with a third-party dependency, there’s no direct way to monitor what happens elsewhere. Even with a good vendor management program, things can go wrong.

One example is the recent GitHub leak. “The attackers had used a compromised AWS API key. After initiating an investigation on the same day, the Microsoft subsidiary said the attacker(s) obtained the API key upon downloading a set of private npm repositories.” That led to Heroku and Travis-CI getting compromised, which led to those two companies needing to further communicate with their customers.

This leads to our final point.

Incident Response –

Bad things happen – criminals commit crimes, natural disasters occur, black swan events transpire. Have an incident response plan. What will be your response if an API gets breached? This is part of the “life’s not fair” side of business – considering the worst-case scenarios. If you need assistance in crafting an incident response plan, SANS is one of many resources for security policy templates. https://www.sans.org/information-security-policy/

APIs are not a separate part of a business, nor are they a nice-to-have. They are integral to an online business and need to be treated as part of the corporate risk management program and as a critical asset. Whatever rigor would be applied to web applications needs to be intensified with API code. It will take creativity and effort, but it needs to be done; customers depend on it.

About the Author:

Ross Moore is the Cyber Security Support Analyst with Passageways. He was Co-lead on SOC 2 Type 1 implementation and Lead on SOC 2 Type 2 implementation, facilitated the company’s BCP/DR TTX, and is a HIPAA Security Officer. Over the course of his 20 year IT career, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds (ISC)2’s SSCP and CompTIA’s Security + certifications, a B.S. in Cyber Security and Information Assurance from WGU, and a B.A. in Bible/Counseling from Johnson University. He is also a regular writer at Bora.

Also Read – Top 5 Organizational Apps for Improving Productivity