Building APIs with security in mind

Any system is no stronger than its weakest link.

Connectivity relies heavily on APIs. We live in a world where almost everything is connected. For attackers, connectivity opens up many new paths of exploitation.

Design Challenges

It’s not an afterthought to think about security. It must be an integral part of all development projects as well as APIs. The process involves gathering requirements, designing, developing, testing, deploying, and monitoring. Security presents a multitude of challenges to system designers. It’s hard to build a system that is 100% secure. Making the attacker’s job harder is the only thing you can do. Cryptographic algorithms are designed based on this philosophy.

User Experience

Finding and maintaining the right balance between security and user comfort is the most challenging aspect of any security design.

Performance

Another key criterion is performance. How much does it cost to protect your business operations from intruders?

Suppose you have an API that is secured by a key, and each API call must be digitally signed. An attacker can access the API if the key is compromised. What can you do to minimize the impact? The key is only valid for a short time, so whatever the attacker can do with it is limited. What will be the impact on legitimate day-to-day business operations?

If the validity period of the key has expired, the client application should call the authorization server (the issuer of the key) to generate a new key. If you make the lifetime too short, almost every API call will require a call to the authorization server to generate a new key. Performance suffers, but the risk of an intruder gaining access to the API key is drastically reduced.

Another good example is the use of TLS for transport-level security. Data in transit is protected by TLS. You pass your Amazon or Flipkart login credentials over a secure communication channel, or HTTP over TLS, which is actually HTTPS. Data passed from your browser to the web server cannot be read by anyone in the middle (assuming there is no room for a man-in-the-middle attack). However, this comes at a price. Over plain HTTP, TLS adds more overhead, which may slow things down. Due to the same reason, some enterprises communicate with the public over HTTPS and with their internal servers over plain HTTP. Strong network-level security ensures that none of those internal channels can be intercepted.

Weakest Link

A proper security design should take into account all communication links. A system is only as strong as its weakest link.

Defense in Depth

Whenever a system is being tightened for security, a layered approach is recommended. This is also known as defense in depth.

CIA Triad

Information systems security is measured by the CIA triad (Confidentiality, Integrity, and Availability).

• Confidentiality — CIA triad confidentiality involves protecting data from unintended recipients, both in transit and at rest. By encrypting transport channels and storage, you can achieve confidentiality.
• Integrity — Integrity refers to the ability to detect any unauthorized modifications as well as the correctness and trustworthiness of data. Protects data from unauthorized or unintentional alteration, modification, or deletion. Integrity can be achieved through both preventive and detective measures. Data in transit and data at rest must be protected by both measures.
• Availability — Providing legitimate users with access to a system at all times is the ultimate aim of system design.

Four prominent controls play a vital role in achieving CIA: Authentication, Authorization, Nonrepudiation, and Auditing.

Authentication

The process of authentication involves identifying a user, a system, or a thing in a unique manner in order to prove that it is the one that it claims to be. Your authentication assertions can be direct or brokered, depending on how you bring them. Logging into a system directly by providing your username and password falls under direct authentication. Direct authentication involves the entity wishing to authenticate itself and presenting the authentication assertions to the service. A third party is involved in brokered authentication. An identity provider is a third party that provides identity services. Facebook is the identity provider when you log into your account via Facebook. Using brokered authentication, the service provider (or website you want to log in to, or API you want to access) doesn’t trust you directly. An identity provider is the only one it trusts. Access to the service is only possible if the trusted identity provider (by the service provider) passes a positive assertion.

A single factor or multiple factors can be used for authentication (also known as multifactor authentication). Three factors of authentication are well known: what you know, what you have, and what you are. At least two factors should be used in multifactor authentication.

• Something you know — Passwords, passphrases, and PIN numbers
• Something You Have — Certificates and smart card–based authentication
• Something You Are — Fingerprints, eye retina, facial recognition, and all other biometric-based authentication

Authorization

Authorization is the process of validating what actions a user, a system, or a thing can perform within a well-defined boundary. The authorization process assumes that the user has already been authenticated. Two prominent access control models are Discretionary Access Control (DAC) and Mandatory Access Control (MAC).

In Discretionary Access Control (DAC), the owner of the data can transfer rights to another user at their discretion. DAC is supported by most operating systems, including Unix, Linux, and Windows.

In Mandatory Access Control (MAC), only designated users can grant rights. Users cannot transfer rights once they have been granted. Operating systems that support MAC include SELinux, Trusted Solaris, and TrustedBSD.

Nonrepudiation

Whenever you conduct a business transaction through an API, you should not be able to reject it or repudiate it later. Nonrepudiation ensures the inability to repudiate. Once you do it, you own it forever. Nonrepudiation should establish the origin and integrity of data in an unforgeable manner so that a third party can verify them at any time. To maintain the integrity of a transaction and allow future verifications, no part of a transaction should be altered once it has been initiated — including user identity, date, time, and transaction details. Once a transaction is committed and confirmed, it must be unaltered and logged. To prevent unauthorized modifications, logs must be archived and properly secured. When there is a repudiation dispute, transaction logs and other logs or data can be retrieved to verify the initiator, date, time, and transaction history.

Digital signatures bind the user (who initiates the transaction) to the transaction the user performs. A user’s key should sign the entire transaction, and the server (or service) should be able to verify the signature through a trusted broker that confirms the key’s legitimacy. A certificate authority (CA) can serve as this trusted broker. As soon as the signature is verified, the server knows the identity of the user and can guarantee data integrity. To ensure nonrepudiation, the data must be stored securely.

Auditing

Auditing involves keeping track of both legitimate and illegal access attempts to facilitate nonrepudiation and identifying possible threats. Accessing a resource can be permitted in some cases, but it should be justified.