API security checklist: 15 best practices to keep your API secure

With security threats constantly on the rise, those with public facing APIs should take particular care in securing their systems, especially when your API functions as a gateway to your data. An improperly secured API can lead to huge data breaches, loss of business reputation, damage to your data and more.

For reference and to ensure we are covering all our bases we will be using the extended fundamental principles of information security to categorise all the suggested security practices for your API checklist. The elements of the extended fundamental principles we will be using are:

• Confidentiality: implementing confidentiality in your system means that resources within your system are protected from unauthorised access. This ensures that all users are currently identified and authenticated in order to access a particular resource.
• Integrity: This ensures that you protect your data from unauthorised or accidental modification, and that the data you hold is accurate and of high quality.
• Availability: Having your data accessible when needed is of utmost importance, this involves keeping your hardware and software available through which data can be accessed.
• Non-repudiation: A secure system should be able to verify the identity of the sender and receiver of data and should make it irrefutable as to whether that data was actually sent by the sender or received by the receiver.

Confidentiality of the resources within your API

There are various security mechanisms you can implement into your API in order to ensure the confidentiality of all resources of your system, including functionality and most importantly your sensitive data that you wish to restrict to authorised users only. This will be the largest section within our checklist as breaches in confidentiality within your API tend to have the worst impact.

1. Authentication

Your authentication is one of the most important mechanisms within your API. In order to authenticate a subject, they must first be identified and then that identity must be proven. In the case of a username and password, the username is the unique identifier of the subject, and the password is something only that subject should know (in theory), therefore authenticating that subject.

There are several different authentication factors whereby you can prove the identity of a subject, these are:

• Something you know: Usually an authorisation code, password or answer to a security question. This authentication factor is based on something only the subject would know.
• Something you have: This would usually be something physical like a key, access card or even your phone. This authentication factor is based on something that only the subject would have physical access to.
• Something you are: This usually involves Biometric authentication using things like fingerprints or facial recognition (although it can also refer to traits of a machine such as IP address). This works well as you don’t have to remember any passphrases or access cards, however it still has its flaws.

Usually in single-factor authentication, one of the above factors are used, such as using a password to authenticate your username on a website, or using facial recognition to access your phone. 

Multi-factor authentication combines multiple of these factors in order to authenticate a subject, such as websites requiring a one-time-pin sent to your phone (something you have) after entering a password (something you know). Multi-factor authentication can be used in your API as well to greatly increase the security of your authentication system, but often at the cost of reduced convenience and automation ability, however with the amount of system breaches happening it may be something you would want to strongly consider.

Once a user is authenticated, for the sake of convenience you can turn that something they know (their password for example) into something they have such as a temporary access token granted once authenticated. Such a token can then be used to verify the identity of the subject in the future, this should of course be done with care as tokens may be intercepted and re-used by attackers. The effect of this can be diminished by giving access tokens an expiry time, after which the user must re-authenticate and the old token becomes invalid.

It may be tedious or hurt automation for a user to constantly re-authenticate using another authentication factor, so you can always make use of a secure refresh token to automatically acquire a new token after your current one has expired, an attacker making use of a refresh token can be mitigated by rotating refresh tokens and detecting the use of old refresh tokens.

2. Access control - Keeping it as granular as possible

Access to the resources provided by your API such as functionality and data should be controlled as finely as possible. When dealing with an API that works with personally identifiable information (PII) or other sensitive data, resources should be locked in a granular fashion so that subjects can only access those resources that they are authorised to see.

There are many different parts of your application you can control access to. Within an API the most basic form of access control is to validate the subject’s access to certain endpoints, restricting them to only the ones they have access to, endpoints can also be grouped together such that one role is required to access multiple endpoints within the same group, how granular you make this endpoint access control depends on the sensitivity of your application. 

If your data is particularly sensitive then access to specific fields can also be limited on your API, even if the subject has access to a particular endpoint you can still restrict the fields that are returned, for example if you have an endpoint that returns details about people, you may want to show general demographic data such as age and gender but restrict access to sensitive fields such names and surnames. This is especially important for multi-purpose systems such as those that deal with both analytics and PII data processing.

When implementing access control it is important to ensure that this mechanism is always invoked and cannot be bypassed, this concept is similar to an operating system reference monitor (having a few extra requirements which will be covered later) which acts like the entrance to a fortress, not allowing entrance through any other point of your application, all requests must pass through this and invoke your access control system.

3. Encrypting API datasets

No matter how confident you are about the security of your network, servers and applications, there is always the lingering chance of a data breach, this can be through coding mistakes, hardware vulnerabilities, software zero-day vulnerabilities, and a large list of other potential attack vectors. It is important to have multiple layers of security protecting the confidentiality of your system and you should therefore prepare for the eventuality of a breach by limiting the damage such a breach could have, this can be done by encrypting all PII and sensitive data that you hold in your systems.

The data you should focus on encrypting is any personally identifiable information (PII), sensitive organisation data such as financials and other sensitive fields. In the event that an attacker gets their hands on your data sets, or your data sets are somehow leaked, it should be impossible to decipher any damaging information from that data, or the damage from having this data should at least be restricted as much as possible.

The techniques you can use to encrypt your data vary on what you are trying to accomplish, PII fields such as emails and telephone numbers that you need to decrypt at some point to display should be two-way encrypted (meaning it can be encrypted and decrypted afterwards) using an encryption algorithm such as AES which is currently considered to be uncrackable. When implementing these algorithms, make sure to follow best practices such as implementing initialisation vectors, and make use of trusted and up-to-date encryption libraries for your programming language.

Authentication strings such as passwords that never need to be displayed should be one-way encrypted using a hashing algorithm such as sha256 (with a salt!) or better yet a secure hashing library specifically designed for authentication strings such as Bcrypt which is available on many platforms. Using these hashing algorithms, you can store the initial hash of the password in your dataset and then compare that hash to the one you generate for the input password in order to authenticate.

Do not try to create your own encryption algorithms, the practice of encryption is highly complex and the trusted encryption algorithms have undergone much scrutiny and research. Also you should make use of trusted and well maintained encryption libraries for your programming language, attempting to implement a trusted encryption algorithm yourself can lead to an incorrect implementation from minor mistakes.

4. Securing internal credentials and other keys used in your API

Once you have secured your datasets using encryption, Your API will need to interface with that data somehow and must be able to decrypt it in order to supply the data to your users, to do this it must store the encryption keys somewhere in your application. Additionally, any other credentials such as database credentials must also reside somewhere in your application.

This is one of the most difficult parts of implementing security in your API as there has to be an entrance point to your encrypted data at some point within your application, at some point data is going to be decrypted in memory or keys exposed in memory, however there are ways of securing these credentials and keys as best as possible.

Unfortunately, there are always going to be developers who disregard security requirements and follow bad practices such as storing credentials in plain text directly within their application, exposing it not only on the server on which it resides, but also potentially within their version control system. To secure your API data as best as possible, you should ensure that sensitive credentials and keys are exposed in as few places as possible and for as little time as possible. 

There are certainly places where keys are more secure than others, for example if keys are stored in plain text directly within your web application files, a vulnerability in your API may allow attackers to access it directly. Similarly, if stored in plain text outside your web application directory, an attacker who gains access to the server may be able to access those keys. If keys are stored only in memory then the operating system does a more substantial job at protecting them, especially if the attacker is unable to escalate their privileges on the server.

One way to secure your application credentials substantially is to create an encrypted database of your sensitive keys, the encryption key may be provided to the application on startup in such a way that it is not stored permanently on the server, such as the application prompting for a password or using a temporary environment variables. This provides far more protection to your sensitive keys and will limit the potential damage of a data breach.

5. Ensuring your servers, network and software are secure and routinely updated

The actual programming is only part of the security of your API, the hardware on which it resides, the software on which it relies such as the operating system, database management systems or application dependencies, and the internal network through which your application communicates with the world represent potential critical vulnerabilities. Your application may be secure, but if other factors are not considered and made secure then you will still be highly susceptible to a breach. No API security checklist would be complete without covering these basics.

There are many steps that can be taken to secure the network on which your application communicates with the world. There are the basic network essentials such as firewalls that should be implemented on your network at minimum. However, there are some extra network security mechanisms you can use to protect your API such as placing your application server in a demilitarized zone on your network- meaning it is logically separated from the rest of your network save for the connections it absolutely requires. Network intrusion detection systems can also help you contain any attacks as quickly as possible in order to minimise impact.

The hardware on which your application resides and other hardware that make up your network are a point of vulnerability for your system. Faulty or unreliable hardware, as well as hardware with known vulnerabilities can cause breaches. One thing you can do to protect your existing hardware is to ensure the firmware is updated regularly.

The software that your API relies on is perhaps the greatest potential security vulnerability as it tends to be the most accessible part of your system. Modern APIs rely on many different softwares and services such as the operating system, database management systems, application code dependencies, and more. Each different piece of software represents a potential vulnerability in your application, it is therefore extremely important to ensure that you maintain this software to the best of your abilities. Firstly you should only be installing and using software that is coming from trusted sources, and that are properly and frequently maintained, stale software that is no longer being updated can accumulate vulnerabilities that increase your chance of a breach. Secondly and perhaps most importantly, you should always keep your software up to date, ensuring you have the latest security patches, outdated software can also accumulate vulnerabilities that attackers scan for and can make use of to breach your system.

6. Protect your API against known security threats

API applications must be designed from the ground up with security in mind, before attempting to construct an API you should familiarise yourself with the various threats and exploits that are commonly used in the wild. A lack of knowledge of the potential hazards to your API will inevitably lead to a breach of your system.

Some of the more common security threats such as SQL injection and incomplete authentication or access control can be solved by accounting for it while programming your API using methods such as scrubbing your input to ensure no unexpected input may make it through to your inner application. However, there exists a myriad of other threats that many developers do not consider, for a breakdown of the top threats you can have a look at the OWASP top 10 API security threats. Some of the included security threats relevant to confidentiality include:

• Security misconfiguration: This is one of the most common reasons for a data breach, it is extremely important to properly configure your application and software dependencies, misconfiguring a web application interface such as Apache or Nginx can severely compromise your security by allowing access to parts of your filesystem that should be out of bounds, having improper permissions on files, or allowing access to data that should be inaccessible (amongst many other scenarios).
• Broken user authentication: This involves being able to exploit or bypass user authentication systems in order to access parts of the API that should be off limits to the attacker.
• Broken function level authorization: This is a failure of access control to particular functionalities within your API such as endpoints, groups of endpoints, utility functions or static resources within your API.

We will cover a few more of the included security threats later on. 

Remember, the above-mentioned threats are by no means a complete list of what your API may face. It is advisable to do some additional research about the less common but still dangerous threats, especially if you intend on creating an API that handles sensitive data or services.

Maintaining the integrity of your data

Integrity is a commonly overlooked principle of information security. However, there are a few important points to cover that you will need to include in your API security checklist. Integrity in the context of an API primarily refers to the quality and completeness of the data you return to your users.

7. Data cleaning

One of the biggest issues with any large data set is dirty data. This can happen for a number of reasons such as data entry staff misspelling or mistyping a field, differently formatted data-sets being combined or acquiring data-sets from sub-standard sources. Either way, it is in your best interest to ensure that you are returning data that is as correct as possible and of high quality.

The key to data cleaning is consistency. This entails returning a result that is as standardised as possible to your users in order to aid automation and to stop the broken telephone effect from making the data quality even worse.

One aspect of consistency is that you should always return your data in standardised formats. Objects returned to your users should adhere to a format that is as strict as possible, including always maintaining the same fields- each with a specified predictable format. If your data includes multiple different data types for a particular field or you are combining data sets, you should ensure that you convert all fields to a specific format before returning it to a user. Some examples of maintaining consistency of your API fields include:

• Ensuring your object keys remain the same on every object returned from a particular endpoint.
• Ensuring the data type of your fields remains consistent for each piece of data returned from a particular endpoint
• Using the same date format not only for a particular field, but maintaining that format across different objects returned from other endpoints within your application.
• Using the same default values throughout different fields returned from different objects, for example missing data may be returned as a blank string, a null value, or a default date such as 0000-00-00, however if you decide on a particular default, you should stick to this throughout your API.

Another aspect of consistency is within the quality of your data. Ensuring the data you return to your users is of a high standard involves:

• Scrubbing your output data of any unexpected characters or data.
• Removing data objects that do not meet a certain minimum quality criteria.
• Ensuring standardised fields such as categories always return an expected value.
• Scanning for data anomalies in your database and manually fixing or removing errors.

Cleaning your data is important to API security as it ensures that you return accurate and complete data that protects the integrity of your system. Dirty data can not only be harmful to your reputation, but can also compromise the security of the entity to whom the data belongs, resulting in incorrect or unfair decisions being made against them due to misrepresentation.

8. Protection mechanisms for accidental or unauthorised data modification

For an application to perform its function, it will generally need to create, modify and delete records. One has to make sure that the your data is protected against unauthorised or accidental modification while still maintaining the availability of the application- making sure that users can still perform their tasks with minimal hassle.

The first thing that should be considered for this is access control within your API- which is the interface between the user and the data. When it comes to protecting your data, the concept of least privilege ensures that users can only modify what they are authorised or capable of doing. Users may be authorised to view certain datasets, but access to the modification of that data should only be provided if they absolutely require it to perform their function on the application and that they are aware of the consequences and importance of the data fields they are modifying.

Access control should be as granular as possible to ensure that the effects of accidental damage are limited. Limiting users to accessing only certain fields of a dataset and limiting the amount of data they can modify can help ensure data integrity.

Another major threat to the integrity of your data is vulnerabilities within your application. SQL injection, for example, can be used to perform bulk operations on your database that can be extremely damaging. As described in the confidentiality section, it is extremely important to make yourself aware of the potential threats that your API faces when designing your API security structure.

The integrity of data can also be protected on the database level when being modified. Some Database Management Systems (DBMS) do come with additional functionality that can be very useful in maintaining the integrity of your data. MySQL for example has the ability to introduce check constraints to your table, these ensure that any data entered into the table must conform to certain programmatic constraints that will stop bad data from even entering your tables in the first place.

9. Data integrity checks

Protection mechanisms against harmful modification of your data can only be so effective, data can also be corrupted through software or hardware faults. You should therefore be prepared to detect such occurrences as quickly as possible as to limit the damage of having incorrect data on your system.

For relatively small data sets it may be possible to perform manual verification of your data on a frequent basis, of course depending on your resources available. You may also be able to perform periodic checksum verifications by extracting and concatenating the data and then performing a simple hashing function such as MD5 and comparing it to historical hashes.

Larger datasets that are subject to frequent changes are more difficult to perform integrity checks on. For these types of datasets you should generally be using a more advanced database management system (DBMS) such as MySQL or PostgreSQL for example. These DMBSs generally have dedicated integrity checking tools such as MySQLs mysqlcheck utility which can detect general database corruption, while this does aid in detecting faults caused by the database hardware or software, it does not protect system against data incorrectness.

Using a suitable DBMS allows you to perform and automate data correctness checks for larger datasets using aggregation comparisons, for this you may need a certain level of understanding of SQL queries. Aggregating data in queries allows you to check ranges, averages, anomalies and more, what you look for in these depends very much on the dataset you are working on. For example if we had the following table:

In this particular example we have a simple table containing the ages and genders of individuals, these 4 records represent a small subset of the table that contains several thousand records. In general this table contains younger individuals with genders roughly evenly split 50/50. There are several queries we can implement to ensure the integrity of our fields. For this particular example we could potentially keep an eye on the Gender field to ensure it is within the expected bounds:

SELECT Gender, COUNT(*) as Total FROM table1 GROUP BY Gender;

This query could potentially detect bad data that has entered the table such as individuals loaded without a gender:

Or perhaps individuals loaded with the incorrect gender, leading to data out of the bounds of expectation:

This method can be applied to much more complex datasets, and by making use of data visualisation or automated detection scripts, anomalies can be detected in the data and corrected.

10. Data backups and replication

Backing up and retaining multiple copies of your data on different devices and locations is key to ensuring the integrity of your data. In the event of data loss due to disasters, theft or data corruption you should be able to recover from a backup that is as recent as possible.

Full backups of your data should be performed as frequently as your budget and resources permit. Some of the factors to consider when determining your backup intervals is the size of your data (large data sets can be costly to back up frequently), how often your data is updated (if data is updated infrequently then the impact is minimised in the event of data loss), the value of the particular data set you are updating (data that is less valuable to your organisation warrants a lower backup priority) or the time sensitivity of your data records (your users may rely on your records being updated on a particular interval).

Where and how to keep your data should be your next consideration. There are a number of places data can be backed up to, the choice usually depends on the resources you have available:

• On the same server: While this can allow you to recover from events such as data corruptions, other more serious events such as the entire server becoming unavailable can lead to the total loss of your data.
• On the same network: While storing your data on a secondary server within the same network can protect you against the loss of your primary server, other events such as ransomware encrypting all the devices on your network can also lead to the total loss of your data.
• External devices: Copying your backups to an external device outside your network such as an external hard drive allows you to keep isolated copies of your data that would not be affected by any disasters or other events that occur within your system. You should however consider the confidentiality implications of this, data stored outside the security of your network is vulnerable. Depending on the sensitivity of your data it is advisable to ensure that your backups on external equipment are encrypted.
• Cloud backups: What list of backup options would be complete without mentioning cloud storage, this method allows for a dynamic storage size to cater for a growing business. While the security of some of the main cloud providers is likely acceptable, you should take further steps to protect your data such as encryption.

While the choice of where to store your data depends on your means, it is generally a good idea to have more than one location where your backups are stored (even if secondary locations are copied to less frequently), so that in the event that one location is compromised you will still have another copy elsewhere.

Your data can easily be compromised either by accidental or malicious intent, the timeframe it will take to notice is not guaranteed and may exceed the interval at which you create your backups, causing you to lose the last copy of your in-tact data. Therefore, the number of copies to keep of your data is another important question. Depending on the size of your data and amount of storage space available, it is advisable to store multiple copies of your data over different time periods. In the event you are creating daily backups of your data you may want a number of backups from previous days and perhaps even a single snapshot per week or month. This way you are able to allow yourself more time to detect and recover from harmful data modification.

Lastly, you will want to make sure your backups are tested frequently. It’s no use creating endless backups without knowing whether you are actually able to restore from them, backups may be incomplete or corrupted. You should attempt a mock restore of your backups as frequently as possible to ensure that they are correct and complete.

For larger organisations with more resources, it is also an option to employ live data replication from one server to another server (or multiple). Most modern database management systems such as MySQL allow for replication, this allows you to copy the data stored in your database from one server to another almost immediately (depending on how much your data is modified and how fast your drives and network are) and allow you to access that data just as you would on the primary server. This allows you to always have a backup server with all your data on it that is as up-to-date as possible, ready to be switched to in the event that your primary server fails.

Availability of your API resources

The availability of your application is crucial to providing services to your users, this refers broadly to your application’s ability to perform the tasks required of the user and whether it can complete those tasks in a reasonable amount of time. There are many ways the availability of your application can be blocked, from lack of hardware to denial of service attacks.

11. Rate limiting

Rate limiting is a crucial security feature of an API and should always be high priority on your checklist. Not only can this feature ensure fair access to your services, but it can also limit the damage of unauthorised access to your data through your API. Rate limiting becomes increasingly important for availability the more users are making use of your API as there are more potential clients to cause excessive usage.

Integrating into APIs can sometimes be a complex task, each user may have different requirements to fulfil using your services and may therefore implement those services into their own systems in different ways, this can sometimes result in excessive and unnecessary usage of the API. Integrated applications can frequently go haywire due to overlooked conditions and can use up excessive resources, leading to increased response times or complete timeouts for other users, denying them availability.

Usage limits can be implemented in many different ways. A simple and rather common implementation is to introduce daily limits on how many times a particular user can call your services, while this contributes to limiting damage in case of a breach and it may limit the time for which a rogue client slows down your services, there are more advanced options that can provide fair usage for multiple users.

Another method that can be implemented is to limit the frequency with which a user can call the API. Depending on the resource cost of a particular endpoint a user is making use of, you can only allow a single transaction every few seconds, transactions made during the limitations can be put in a queue to be processed as soon as they are allowed. This can be adjusted to ensure fair usage of the resources you have available.

Usage limits do not necessarily need to be implemented directly into your API. These can be implemented throughout your network on the path to the API such as in your load balancers or on your firewalls. Implementing rate limiting on the outer layers of your network can be more effective at mitigating DDoS attacks due to fewer network resources being used to process the request before being blocked.

Multiple methods can certainly be implemented together to take advantage of each of their benefits.

Usage limits are also critical in limiting the damage of unauthorised access either directly into your API or through one of your integrated users. While you may consider your API particularly secure, those who have integrated into your API may not appreciate security as much. Bad actors can exploit vulnerabilities in client systems and gain what appears to your API as authorised access. If users are limited to their expected usage of your API, then transactions above that level can be blocked, therefore limiting the damage such a breach could cause.

12. Load balancing across multiple API servers and failovers

User request loads can generally be somewhat unpredictable on APIs, certain users may only make heavy use of your API for short bursts periodically. Additionally, APIs may be used more frequently during certain times of the day. It is highly recommended to have more hardware available for when the usage of the API exceeds the currently available resources.

Furthermore, with the threat of denial of service, having a single server responsible for API services creates a single point of failure from which it may be difficult to recover.

If your API user base grows to the point where your current hardware is struggling to meet usage requirements, it may be a good idea to start a new instance on an additional server to aid the other. In order to properly share the resources of those servers, you can use a third server to run a load balancing application such as Nginx or Apache. These can be used to fairly split the load between the servers. More importantly, in the event of one server suffering a hardware or software failure and being unable to process further requests, the load balancer can intelligently redirect all requests to other available servers.

For those who want a more financially efficient solution, many hosting providers provide the option to only bill you for the number of hours a virtual machine is running, this allows you to proactively spin up a new instance only in the event that it is needed such as during peak usage times. Using this method you may have multiple dormant servers ready to kick in when you need them to.

As a method to recover from a total availability outage due to something like a denial of service or ransomware attack, a disaster recovery (DR) site should strongly be considered. This DR site should contain the minimum required systems to adequately serve users. It should preferably be isolated in its own environment, totally separate from your primary environment so that whatever caused the outage on the primary environment cannot spread to the DR environment. DR sites could be reachable using a separate URL and IP that can be activated only when there is an incident. While this does provide enhanced availability protection, it can be costly to have an entire DR environment ready to take over from the primary system so this may be an option only accessible to those with more resources.

13. Incident response

It is practically impossible to guarantee 100% uptime for an API service, there are multiple points of failure where availability could be denied, from the API application itself, to your DNS provider. Preparing yourself for as many eventualities as possible can limit the downtime of your services during an outage event.

The first step in incident response is to detect when an outage has occurred, the outage could be partial- where one or more particular services within your API are non-functional- or complete- where your API is entirely non-functional. This could happen due to a myriad of reasons from something as silly as running out of harddrive space on your server, to a full on cyber attack. Either way, being able to identify the issue is critical, doing so as fast as possible will limit the amount of time your services are unavailable.

It doesn’t exactly look professional when your users are the first to inform you that there are issues with your API. There are many tools out there that can detect server and network issues within your environment and alert you as soon as possible. These tools can frequently tell you exactly what is wrong within your environment or can at least inform you of where to start looking. If you are running an API where uptime is critical, then such tools are an absolute must.

Intrusion detection systems (IDS) are another great option for detecting cyber attacks that could cause outages, these more advanced systems can detect and alert when such an incident happens.

There are several methods of preparation that you can create in order to quickly recover from an outage, some of these include:

• Accessible backups: If your resources allow for it, you should have backups of varying accessibility, from database replication where the primary server can easily be switched to the replicant, to backups available directly on the network, to the final layer of off-site backups.
• Disaster recovery (DR) site: If uptime is imperative, DR sites are worth considering. These allow you to switch environments as quickly as possible, allowing you to resolve the issue in your primary environment with peace of mind that time is no longer as big of a factor.
• Logging: When an incident occurs, one of the easiest ways of determining the cause is to look at your logs, while this is difficult to enhance on servers directly, you are responsible for the quality of logs coming from your API, it is important to catch and report on errors in as granular a fashion as possible so you can quickly determine the root cause.

These are just some common key preparations you can implement, other preparations very much depend on your environment which should be considered when releasing an API.

After an incident has occurred, it is important to document the details of the incident and to mitigate future such events as best as possible to ensure it does not occur again.

Non-repudiation

While not included in the original triad of security principles, non-repudiation has become an increasingly important principle in our world of digital services, especially when considering an API. It is imperative that we are able to pin-point to the best degree possible the activity of a user within the API. This allows us to determine if an individual has performed activities out of the scope of what they are allowed to do.

14. Audit logging

Audit logging is extremely useful in determining the cause and pathways of unauthorised or unusual activities. If it is suspected that a user is performing suspicious activities these logs are where you would look first. Without proper proof of the actions that a user has performed, it is difficult to determine what unauthorised data was accessed, by which specific user, as well as how and when it was accessed. While audit logging is crucial for forensic investigations after a potential breach has occurred, it's also a great way of debugging problematic endpoints and user integration issues.

Throughout the process of an API call being processed, there are several steps along the way where we can implement audit logging, such as:

• The initial contact: What endpoint was called with what input data, by which user at what time.
• Errors and warnings: During the processing of the transactions were there any errors or warnings encountered that may have affected the output the user would be provided.
• The output response: What exact output was provided to the user (this can require large amounts of storage capacity) and the duration the API took to process the call.

By logging these steps, we can prove exactly what data the user requested, if there were any issues on the API side that may have altered the response, and exactly what was returned to the client.

As a rule of thumb, it is generally a good idea to log as much about the processing of a call as your storage capacity allows, especially when you are handling sensitive data. 

Beyond the aforementioned benefits, audit logging can also be used for:

• Anomaly detection: Logs can be monitored for any unusual activity, automated systems can alert developers upon detection.
• Development debugging: Can increase the speed of development time as developers can quickly determine the errors within their code.
• Performance tracking: You can use the logs to track how long services take, then aggregate this data into useful performance charts to see what services may require optimisation.
• Business analytics: Logs can also be used to determine which services are performing best and at what times they are most popular.

15. Asymmetric Encryption and Digital Signatures

Forenote: the complexity of implementing this in your API and the ability of user’s to integrate using this may hinder most people from considering this option, but it can certainly enhance the security of your API significantly.

While audit logging tells you what actions an authenticated user has performed, you can’t necessarily prove that a user was not falsely authenticated due to leaked credentials or whether an attacker has perhaps performed a man-in-the-middle attack. Beyond using credentials or tokens as an authentication system, one can encrypt the data in transit using public key cryptography while ensuring the requests are being sent by the expected source.

While we won’t be going in-depth on the specific workings of public key cryptography due to its complexity, the simple explanation is that by making use of a public and private key combination, the sender of information can encrypt data that only the recipient can decrypt, within this data a digital signature can also be inserted that can only be created using the sender's private key (which only they have access to) which can be verified using their public key.

If the digital signature enclosed within the request to your API can be verified, it can be almost guaranteed (to the extent possible in IT) that the request did come from the correct identity (user). One can then tie in the activity from their audit logs to perform forensic investigations into unauthorised usage of your API, knowing that there is enough evidence to prove that the request did come from that user.

Something to consider is that- while it’s difficult enough to implement this when you are coding your API- it can be even more difficult for your users to integrate using this system. This would most likely not be feasible for an API built for many different entities as it would be a nightmare to assist them all. Furthermore, this will most likely have a negative impact on performance due to the extra encryption and decryption operations required. But for a complex API handling large amounts of confidential data, this would be a good option to consider.

Using this article as a checklist, you can ensure your API follows the best security practices that will protect your data and services. Depending on the environment of your API, this checklist is not exhaustive and you should consider the potential threats related to your use-case. If you’d like to contribute to the discussion feel free to leave a comment below.