This post is part 2 of 3 for my ultimate guide to API security best practices series. In this post, I will be discussing confidentiality, integrity, and availability of data. In essence, methods of how we can keep data private, protect it from being compromised while making it accessible anytime.
Part 1 – API security: Ways to authenticate and authorize discussed authentication and authorization of identity security.
Part 3 – API security: Platform capabilities and API-led Connectivity example will show a walkthrough that demonstrates how Anypoint platform can be a vital component of a secure API-led architecture.
2. Confidentiality, Integrity, and Availability
2.1 Message Integrity
Message Integrity goes beyond the authentication of the App and the User and includes the verification that the Message was not compromised mid-flight by a malicious third party. In other words, the Message received by your API is verified as being exactly the one sent by the App. The same goes for when your API acts as Client to a Server.
2.1.1 Digital Signatures
We humans sign all kinds of documents when it matters in the civil, legal and even personal transactions in which we partake. It is a mechanism we use to record the authenticity of the transaction. The digital world mimics this with its use of Digital Signatures. The idea is for the App to produce a signature by using some algorithm and a secret code. Your API should apply the same algorithm with a secret code to produce its own signature and compare the incoming signature against this. If the two match, the API has effectively completed authentication by guaranteeing not only that this message was sent by a known App (only a known App could have produced a recognizable signature), but that it has maintained its integrity because it was not modified by a third party while in transit. As an added benefit for when it matters with third party Apps, the mechanism also brings non-repudiation into the equation because neither the App, nor the User can claim not to have sent the signed message.
2.1.2 Message Safety
Even when you know that your API has been invoked by an authenticated App and User and the message has arrived with its integrity guaranteed, you still need to protect against any potentially harmful data in the request. These attacks often come in the form of huge XML documents with multiple levels of nested elements. JSON documents may also contain huge nested objects and arrays.
2.2 Message Confidentiality
It is all very well to rest assured with the Integrity of a message sent by a known App, but the journey from App to API may have been witnessed by some unwelcome spies who got to see all of those potentially very private details inside the message! Thus, it is necessary to hide those details from the point of delivery by the App to the reception by the Server. An agreement is needed between the App and API in order to be able to hide the details of the message in a way that allows only the API to uncover them and vice versa.
2.2.1 Public Key Cryptography
The age old practice of cryptography has made a science of the art of hiding things! IT has adopted this science and can produce an encryption of the message which is practically impossible to decrypt without a corresponding key to do so. It is as if the Client had the ability to lock a message inside some imaginary box with a special key, hiding it from prying eyes until the Server unlocks the box with its own special key. Digital Signing discussed above produces signatures in this very way. Cryptography comes in two forms: symmetric, when both Client and Server share the same key to encrypt and decrypt the Message; and asymmetric, when the Server issues a public key to the Client allowing the Client to encrypt the Message, but keeps a private key which is the only one that can decrypt the Message: one key to lock the Message and another key to unlock it!
2.2.2 Digital Certificates
Digital Certificates are a means to facilitate the secure transport-level communication (TLS) between a Client and a Server over a network in such a way that the Server can authenticate itself to the Client. This is made possible because the certificate binds information about the Server with information about the business which owns the Server and the certificate is digitally signed by a Certificate Authority which the Client trusts. 2.2.3 Mutual Authentication with Digital Certificates In most cases it is the Server which authenticates itself with the Client. However, there are also scenarios in which the Server demands the authentication of the Client. The Server requests the Client certificate during the TLS handshake over the network. One thing to keep in mind is that the Server controls whether Client authentication occurs; a Client cannot ask to be authenticated.
2.2.3 Mutual Authentication with Digital Certificates
In most cases it is the Server which authenticates itself with the Client. However, there are also scenarios in which the Server demands the authentication of the Client. The Server requests the Client certificate during the TLS handshake over the network. One thing to keep in mind is that the Server controls whether Client authentication occurs; a Client cannot ask to be authenticated.
Mutual authentication with TLS certificates is ideally suited to the type of system to system communication that you see when your API acts as a Client to a Server, whether the Server be another API or a Database or any other system entity. Missing from this sort of communication is the human User. Hence, the security credentials exchanged between the two parties are far easier to manage.
2.2.4 HTTPS
By utilizing TLS, your API can expose itself over HTTPS and guarantee both Message Integrity and Confidentiality at the same time. Public Keys are emitted on Certificates which have been digitally signed by independent and trusted Certificate Authorities, thus guaranteeing that the public key was issued by your API. Once the initial handshake has been completed with the App by the exchange of Messages using public and private keys, the communication switches to the more efficient symmetric form using a shared key generated just for the duration of the communication, all of which occurs transparently.
2.4 API Availability
Your API must guarantee that it is always available to respond to calls and that once it begins execution on the call, that it can finish handling the received message right the way through to completion without losing data. This can be achieved by horizontally scaling the API across multiple servers and by handing off the processing of the message to a message broker which will hold the message till the API has completed its processing. The understanding in this latter scenario is that another process is subscribed to this message publication and thus continues the processing asynchronously.
Thus it is clear that reliability is a step beyond mere availability. While an API may (through horizontal scale-out) be available to respond to all calls because a load-balancer in front of the API can propagate calls to the correct hosting server when any of the other servers are down, this still may not be enough because the API may fail mid-way through processing. In a reliable architecture, the API would receive the call and then leave a message on a message-broker queue (JMS or AMQP for example). Even when the service which has subscribed to the queue is down, the broker can hold onto the message for later consumption when the service comes back online again.
What to expect at the of the API security series
The next post will show how MuleSoft’s Anypoint Platform can ensure that your API is accessible while completely secure. You will understand the majority of security concerns and the methods to address those concerns. You will then become an expert on the topic and with MuleSoft’s Anypoint Platform to execute on these ideas and insights.
If you want to read ahead and learn more in detail about API Security, you can download the full Protect Your APIs whitepaper.
