What's API?

API, “Application Programming Interface” is the interface that enables the functions of an application to be accessed and used externally or remotely. API allows an application to be accessed from different platforms.

The API Evolation

An API itself is an interface. It’s the interface for clients that interact with the system. Clients should only know about the interface and nothing about its implementation.

SOAP vs. REST

SOAP-based web services provide a way to build and invoke a hosted API in a language- and platform-neutral manner. A message from one end to the other is passed as an XML payload. SOAP is very structured and is backed by a large number of specifications. The request/response protocol between the client and the server is defined in the SOAP specification. The way you describe a SOAP service is defined in Web Services Description Language (WSDL). The WS-Security, WS-Trust, and WS-Federation specifications describe how to secure a SOAP-based service. WS-Policy provides a framework to build quality-of-service expressions around SOAP services. WS-SecurityPolicy defines the security requirements of a SOAP service in a standard way, built on top of the WS-Policy framework. The list goes on and on. Due to the nature of SOAP-based services, which are highly decoupled, standardized, and governed based on policies, they’re the preferred ingredient to build a service-oriented architecture (SOA).

In contrast to SOAP, REST is a design paradigm, rather than a rule set. REST is based on the rule set defined in the HTTP specification. Web 2.0 is a set of economic, social, and technology trends that collectively formed the basis for the next generation of Internet computing. It was built by tens of millions of participants. The platform built around Web 2.0 was based on the simple, lightweight, yet powerful AJAX-based programming languages and REST — and it started to move away from SOAP-based services.

Security By Design

The most challenging thing in any security design is finding and maintaining the right balance between security and user comfort. First of all, you should be protected from many attacks such as brute force attacks. You must encrypt sensitive data such as user information in an accurate and secure way.

You must have an API secured with a key. Every API call must be digitally signed. If the key is compromised, an attacker can use it to access the API. How do you minimize the impact? You can only make the key valid for a very short time; so anything an attacker can do with the stolen key is limited by its lifetime. Each API call must first check the validity period of the key, and if it has expired, make another call to the authorization server to generate a new key. The new API key duration should be set according to the server. Otherwise, it may create an extra burden.

Strong authentication and authorization practices are required to keep your APIs secure. There are several methods for API authentication and authorization, for example, oAuth2.0 is the most popular.

It may be your most dangerous attack on the API. Insider attacks are less powerful and less sophisticated, but highly effective. Most organizations spend most of their security budgets protecting their systems from outside intruders; however, according to the Computer Security Institute (CSI) in San Francisco, about 60% to 80% of network abuse incidents originate from within the network.

You need to hash your API Key for Insider Attackers. Make sure you use a safe random generator to generate your UUID. Send the API key as securely as possible. Your authentication mechanism affects how you store the API key.

If what you’re providing to the user is a combination of primary key and API key, you can store the API key securely.

You should definitely use the algorithm correctly for the primary key and API key. There are different hashing algorithms. Like bcrypt and scrypt… This may or may not be appropriate for your use case. MD5 and SHA1 are not recommended as they are insecure and decryptable.

If you simply use your primary IDs for your resource and expose them to the user, it is easy for an attacker to guess every other resource, just by increasing the number.

Take the obvious and make something new out of it in a way only you understand. If the attacker does not know the “how”, it is harder to guess what the next number in the chain might be.

Always sanitize external data!

Security Patterns

An API can be anonymous or protected with limited access. If it’s anonymous, you don’t have to worry about authentication.

Twitter API version 1.0, for example, had several open APIs. The API https://api.twitter.com/1/ statuses/public_timeline.json was an open API, which returned the public timeline of a particular Twitter user. All Twitter APIs have been protected since version 1.1. If you open a public API, be sure to enforce appropriate limits.

A public API can be secured for authentication with HTTP Basic/Digest Authentication. Until then, it was a way to access a protected API by sending a username and password in the HTTP Authorization header along with the API call request. The limitation here is that you have to own and maintain the user base or user store. HTTP Basic Authentication won’t work in a federated scenario where you want to give access to users that don’t belong to you. This authentication model is known as Direct Authentication.

Both public and private APIs can be secured with HTTP Basic/Digest Authentication.

A system protected by HTTP Basic Authentication is not secure enough. Credentials can be leaked in two stages: during transfer and at rest. You can use HTTP over TLS (HTTPS) for user credentials. It is not enough to secure the API call. You also need to consider how the API gateway connects to the user store.

Passwords should only be known to owners. At the database level, they should not be known, even to system administrators or anyone with full access to the system.

System administrators can view passwords in clear text as long as they have access to the key used to encrypt the passwords. Using one-way hashes can prevent this. Even if the encryption and encryption algorithm are known, the passwords should not be decrypted.

Managing API Security

API security should encompass a system originating from the client, traversing networks, reaching the server/backend, and finally reaching the user. Therefore, in API security, data in transit/data in motion Security, Access Control, and Security Against Denial of Service Attack (DoS) play an important role.

You must reliably identify end-user information using authentication and authorization.

You must perform data privacy and masking of personally identifiable information.

What’re Authentication and Authorization?

Authentication is used to identify an end-user. Authorization is used to grant access to the resources the identified user has access to.

What Is Used For Authentication and Authorization?

JSON Web Token (JWT) is the most used method in this regard. Defines a container for moving data between interested parties. JWT has multiple implementations. JWT can be used to propagate identity between parties, distribute user privileges between parties, transfer data securely over a channel between parties.

What are the JWT Limitations? Transactions for users are more difficult as they are not reflected immediately. JWT has a structure that can be set as date and time. Because the token is stored on the client-side, there is no way to directly invalidate the token, even if the user that the JWT was issued with is marked disabled in the database. Instead, you have to wait until it expires.

What’s the JWT JWE? The JWE (JSON Web Encryption) specification allows us to encrypt data sent in a JSON-based data structure. It defines two serialized forms to represent the encrypted payload: JWE compact serialization and JWE JSON serialization. As with JWS, the message to be encrypted using the JWE standard need not be a JSON payload.