One of the most important things any API developer can realize is the fact that, as a data handler, they have some of the most important legal and moral requirements towards their data subjects of any technically oriented organization.

The fact that consumers entrust developers with their data at all is predicated upon the idea that this data will be secured, that the API itself will be bolstered against attacks, and that the API provider is doing everything within their power to continually secure themselves against potential threats. With this in mind, the idea of auditing API security is extremely important.

Today, we’re going to do exactly that. We’ll discuss 9 questions that every API provider should ask themselves when it comes to security. While this is one potential guide for high-level API security auditing, we hope it will be a jumping off point toward more specific questions along the API lifecycle.

The Benefits of an API Security Audit

Simply put, security is not a set and forget proposition. Threats are constantly evolving, and accordingly, so too should your security. Gone are the days where massive spikes in technological development occur over the course of months. The modern era sees breakthroughs in decryption and new methods of network penetration in a matter of weeks (or days) after a new software release.

Of course, there are strong systems to implement which can negate much of these threats. Following a few basic “best practices” for security can negate a bulk of the vulnerabilities, and as such, these best practices should be seen as a first line of defense.

Auditing can help expose wasteful endpoints, duplicate functions, consistently failing calls, and more, which if reduced makes for a more maintained, and safer codebase. This also has the added effect of producing clearer documentation, and taken to its logical conclusion, can make version management and iteration that much easier and effective.

In other words, a security audit is not just a good idea in terms of securing your API – it’s a good idea for securing the health of your API program, too.

9 Questions to Audit API Security

One way to audit an API is to separate our questions into three general categories according to the type of consumer who will interact with the system. We can broadly separate these consumers into core functions, generating Business Questions, Technology Questions, and User Relations Questions.

Business Questions

When we discuss business considerations, what we’re really looking at is the fundamental way in which the core business competencies drive the API design and function. In other words, we’re looking at how the API supports the business itself, and thereby identifying the various security concerns fundamental to the business functionality. This includes how information is collected, how that data is retained, and various other aspects concerning partners and internal policies.

1 – What Data Do We Collect – And Why?

Identifying why the business collects the data that it does is a huge first step towards ensuring security compliance. GDPR and other related legislation has brought data privacy to the forefront in the consumer mind, but these issues have long been coming. The simple fact is that businesses, and thereby their APIs, can very easily over-collect data. It might seem an easy way of going about things, but it may create much bigger issues than it delivers in terms of value.

Understand new EU data protection laws

The biggest impact here is the fact that with greater amounts of collected data, the data pipeline loses efficacy, and can potentially betray user privacy expectations. This, together, makes the API a larger target, and thereby decreases the overall security. An API should do much while exposing little – in other words, it should provide excellent functionality without exposing exactly how powerful it is.

If your API exposes massive amounts of data, from a pure cost/benefit analysis, you are going to be a target. Furthermore, if you are breached, especially if you function in any capacity with EU data or are under EU data protection laws, your punitive possibilities are extreme.

Look at your API, and reduce data collection to only that which is necessary. Obtain explicit user consent for that collection – an “opt-out” option is no longer effective and, in many cases, does not guarantee GDPR compliance. Obfuscate data where appropriate, especially on endpoints. Most of all, minimize your attack surface as drastically as possible while still allowing the basic business functionalities required.

2 – Do We Have Internal Security Policies?

The unfortunate reality of data exposure is that most threats are not from external sources, but from internal threats, poor security policies, inadequate training, and simple malfeasance. Even if the threat is not cognizant or purposeful, simple human error can be much more damaging than any external attack due to the nature of internal access to resources.

Thankfully, this area of threat can be mitigated perhaps more effectively than any other area in this auditing process. Internal security policies are stated by internal members, and as such, can be tailored to your specific organizations, its eccentricities, and its general weaknesses.

Hardening processes against social engineering, for example, can be relatively simple if systems are locked out from access until the client provides two-factor identification, thereby removing the inherent insecurity of secret questions.

IP theft can be prevented by separating systems and ensuring that clients accessing content via an API on a secure server and have their traffic routed independently of other, less secure traffic sources.

Something as simple as ensuring proper distribution of responsibilities and powers amongst your employees can go a long way towards ensuring security of this type and mitigating most common threats.

3 – Do We Trust Our Partners?

Insider threats are a serious concern, but the term itself is somewhat misleading. When we talk about insiders, we’re not just talking about individual workers and those with code-level access – what we’re really talking about is the threat from people with elevated, internal access of any kind. Unfortunately, that includes partners that have elevated access for business-to-business functions.

When you share data from your API with other third parties, you are relying not just on them securing the data they’ve gotten from you, but on their own security being stringent enough to secure their own data and their own API. Due to the nature of a business-to-business application, these types of integrations tend to form symbiotic chains between the API partners, meaning what affects one partner will likely affect the other.

In other words, if a partner’s system is compromised, there is the serious and real threat that endpoints that aren’t meant to be exposed would in turn be exposed, thereby transferring much of the impact from an external point of failure onto your internal systems.

Accordingly, any business security review must take into account an audit on external partners, their various policies, and the systems into which they integrate your data stream. If you don’t have an SLA, or Service Level Agreement, with that partner, or they aren’t 100% trusted and verified, they are not a partner you need to be providing heightened access to.

Partner API Security Case Study: Cambridge Analytica & Facebook

Technology Questions

Technology concerns go beyond these business questions, and instead look at the technological implementations of the core business competencies and their related functions. This is often the focus of most security audits and implementations, and while this is an extremely important aspect of this auditing process, it is only part of the bigger picture.

4 – Is Our Data Encrypted During Transit? What About Data at Rest?

Encryption is a huge part of API security, both in terms of data in transit and data in rest. Although encryption evolves randomly, major faults with older methods are often discovered, so sticking with a single solution in impetuity is not a tenable approach. Unfortunately, this seems lost on some data providers, as many of the most recent security issues have had lax data security at its core.

Addressing your encryption methods and ensuring that they are adequate and secure is extremely important. While at rest encryption is obviously important, it’s also just as important to ensure encryption in transit. The amount of data pushed over HTTP is insane when one considers that HTTPS is much more secure and very easy to set up. It’s not a perfect solution, sure, but it’s a better solution than sending over the clear, and when paired with other advanced encryption, makes for a secure pipeline for data transit.

5 – Are We Overexposing? Are We Tipping Our Hand?

A big technical exposure can be found in the simple practice of exposing too much to too many in the API proper. Simple things like not adequately rate limiting endpoints, exposing too much information in queries, or even documenting internal endpoints in external documentation can tip your hand and expose much more about the API than was ever expected or desired.

For more read: Security Points to Consider Before Implementing GraphQL

As an example of this type of overexposure, we can look at something like GraphQL. Since GraphQL allows for users to state what data they want and in what general format, it’s conceivable that, without rate limiting, a nefarious external user could use multiple API calls in different formats from different endpoints to effectively map the entirety of the internal API routing, thereby exposing the structure of the API itself and beginning to expose the vulnerabilities that could be attacked.

In essence, this is akin to port scanning, and as any decent network administrator can tell you, limiting access and locking down systems is a very powerful, proactive method for securing your API.

6 – Do We Have Any Gaps or Vulnerabilities?

While this might seem so simple as to not justify its inclusion, scanning for gaps and vulnerabilities is a very important step in auditing – unfortunately, it’s often seen as the only step, and as such, is better considered as part of a process rather than as a single solution. Look at your codebase both at rest and in action, and look specifically for gaps and vulnerabilities arising from common interaction.

These are often missed or ignored, especially when the vulnerabilities seem small. The reality is a single small gap can cascade across multiple endpoints and products, resulting in a much less secure system, and a propagation of weakness across the entirety of the system.

A big vulnerability, often associated with online databases, is using default settings and setup values. While it might seem easy to just click a button and set up a default server, in some cases, this can leave data unencrypted, easily grabbed, and sent over the clear. In fact, many of the most high profile data breaches of the last ten years have occurred simply because the databases in question or the services that secured them had little to no encryption and utilized default securing credentials.

User Relations Questions

To finish this picture, we also need to look at user relations. While we’re technically looking less at the API internal security policy, and instead focusing on the security actions of those who utilize the API itself, the implications of their use would suggest that any security failures aren’t necessarily because of their actions alone, but instead due to the API even allowing those actions to occur in the first place. Accordingly, identifying the facilitating security holes that allow users to break the system will go a long way towards rectifying any potential issues in the future.

7 – Are We Vetting Our Customers?

Most customers mean well. The customer just wants to use your API, often for their legitimate, well-informed, and legal business purposes. Unfortunately, you can’t just trust all users because “most” do the right thing – especially when some of your users want to use the API for massive amounts of data processing.

A human-readable developer policy is the first step toward enforcing API terms of service.

As such, vetting your customer base is a massively important issue for any secure API. Make sure that customers are using their data access for the proper reasons, and most importantly, establish a way to track baseline usage and ensure that any deviations are properly addressed and managed.

An example of this type of threat would be the massive data misuse from Cambridge Analytica. The organization data-mined information from an app that was published on Facebook for “academic purposes,” and used that data for a multitude of different uses – all in violation of the terms of services from Facebook itself.

Another great method of dealing with these concerns is to grant new customers rate-limited starter accounts until they’ve shown that their purposes are legitimate and their usage allowed. Another method is to tie into other federated networks with trusted userbases, allowing trust to be established by trusting their history on other networks.

Regardless of how you ensure your customer is trusted, this is of paramount important to a secure API. Most attacks are going to originate from the inside, not from random outsiders.

8 – Do We Have a Secure Front End?

Depending on the method by which a user accesses the API and its services, insecurity can arise not from the API, but the frontend that ties into it. A web front utilizing Flash or Silverlight could, if those plugins utilize older builds, expose vulnerabilities for script injection or other types of malicious code usage. Even something like an advertiser widget displaying an advertisement on a login page could, in theory, be used to capture data about the browser and user agent string, and in some malicious cases, may be able to use scripting to capture credentials using session captures.

Consider how the frontend operates. Does the API secure keys properly in transit? Is the key used for total authentication, or just as part of the process? Ideally, a key should start the process of identification, but not solely prove ownership, thereby limiting damage. Are user rights escalation limited, or is there an automatic system given their subscription level? These systems can be broken and users can sometimes maliciously escalate their own privileges.

All of this is often overlooked, but it bears discussion – a frontend is just like your front door, and as important as we consider locking our front door when leaving the house, so to should we treat our frontends with ample security!

9 – Is Your User Support Effective?

The way in which an API supports their users can have a dramatic effect on security. Often, security can be broken down unintentionally, through users utilizing a system in ways the designers never planned for. Ample detection of this, as well as documentation as to how a system should be properly utilized, can go a long way to mitigating these user issues before they even pop up.

Additionally, consumer support systems can be leveraged as a method of reporting and identifying these issues before they become larger than they already are. Simple reporting emails, a live support chat, or even a bug hunting reward program can go a long way to ensuring users are reporting issues when they’re discovered, thereby having an overall strengthening effect on your API.

Being proactive in this realm is hugely important. After all, if your users can find and exploit these issues, sometimes even accidentally, then you can be sure that attackers can as well – the only difference being that attackers won’t be kind enough to notify you as to the exposure, alerting you there’s a problem at all.

Conclusion

Head to our API Security Insights page for more on securing APIs!

Security is an extremely serious and important part of any API, and as such, it should be given the importance and weight that it deserves. These 9 basic questions can do a lot of audit security, and frankly, they’re not that difficult to address – adopting them as a frame of mind not only results in a greater amount of security immediately, but has a compounding effect when used as a structure for secure development.

Considering the possible fines, not to mention the loss of trust and commerce that can come from being exposed or having an API used for nefarious purposes, the benefits of adopting these questions and thinking hard about security moving forward are immediate and compounding over time, delivering a safer, stronger, and more reliable API ecosystem.