Modern digital transformation is built on APIs, driving a new operating model that provides direct access to business logic, applications, and institutional data. While this access is invaluable for partners and customers, it also makes APIs attractive targets for hackers and cybercriminals. Therefore, it is very important to focus on API security.
In this article, you will learn why it is so important to protect your API, some API security methodologies and best practices, and the role APIs play in the DevSecOps paradigm.
Importance of API security
Organisations use APIs (Application Programming Interfaces) to communicate with other systems and transfer data. A poorly developed API can expose sensitive personal data and depending on the nature of the applications even medical and/or financial data. Data privacy is therefore high on the priority list for both the users and the organisations.
There have been several cases in which companies have been hacked because of an open and insecure API, thereby exposing user data. Venmo, a peer-to-peer mobile payment service, was hacked by a computer science student who was able to access information on seven million Venmo transactions, including the full names of people sending money through the platform. This happened, at least in part, because Venmo didn’t appropriately handle the challenges while making data accessible through a public API.
Similarly, Ledger, a French cryptocurrency hardware wallet company, experienced a data breach due to an insecure API. While the wallets and cryptocurrencies were well protected, a third-party API misconfiguration ended up leaking the personal data of their customers. The breach resulted in over 270,000 phone numbers and addresses being leaked and the exposure of more than a million customer email addresses. As you can see, ensuring that your API is well developed and properly protected is of huge importance.
API security methodologies
There are several techniques you can implement to increase your API’s security, each with a unique set of benefits. There are two aspects of API security – authentication, which tells an application who you are, and authorisation, which tells the application what you can or have permission to do. Here are a few common API security methods:
API keys are good for developer quick-starts and allow users to have access to all the resources on a platform as long as the `API-Key` is provided on every request. Essentially, it’s an encrypted string that identifies an application without paying attention to the user of the application. API keys provide application authorisation and identification; in other words, the platform identifies the project or application making a request to the API and checks to see if the application is authorised to make a request to the platform. The calling application needs to add the key to each API request, and the API can use the key to identify the application and authorise the request.
However, API keys are not totally secure as they are usually accessible to the client. This may make it easy for a hacker to steal the key, and if the API key doesn’t have an expiration time, a stolen key can be used indefinitely unless the owner revokes or generates a new key.
On the plus side, API keys can be used when you need to block anonymous traffic if you want to allow only traffic from a particular application. You can also use them to control and limit the number of calls made to your API, to filter application logs or to identify application usage patterns.
Basic Authentication, or basic auth for short, is a simple method of authenticating API requests. It uses a header called Authorisation, with a base64 encoded representation of the username and password of the user. For example, a request using basic authentication for the user `tomiwa` and password `123456` looks like this:
GET / HTTP/1.1 Host: example.com Authorization: Basic dG9taXdhOjEyMzQ1Ng==
Even though basic auth is easy to implement and suitable for server-to-server communication, using it for client-server communication can pose several threats. Sending user credentials for every request would be considered bad practice, as the user is not aware of what the app will use the credentials for, and the only way to revoke access is to change the password. Also, the passwords are usually long-lived, and if an attacker has access to the password and username, this can lead to significant damage.
Basic Authentication can be used in a scenario where you want a simple way of authenticating users while enforcing security. It can also save a lot of time when you need to quickly get up and running with authentication and don’t want to spend much time thinking about roles, permissions scopes, etc.
JSON Web Tokens (JWT)
JSON Web Tokens, also known as JWT, is a standard for safely exchanging claims between two parties. These claims are assertions about a certain object to ensure its validity. JWT provides various types of signatures and encryption. The signatures are used for validation to guard against data tampering, while the encryption is useful for protecting data from being accessed by third parties. The process starts by sending a username and password to the server and then validating the information sent.
Once validated, the server generates a token, which is usually made up of a header, payload and signature separated by dots based on a secret key that only the server knows. The client can then include this token in the headers of subsequent requests, and the server will validate it using the secret key. The generated token is usually valid for a period of time, after which the client can use a refresh token to request a new one. This allows the server to block access to clients, if required.
There are several benefits of using JWTs. They are more secure as they provide a public/private key pair in the form of a X.509 certificate for signing. They can also be used in federated identities. For example, the ID Token returned when a user logs in successfully with their credential in the OpenID Connect’s spec is a JSON Web Token. JSON Web Tokens are very common and are used at internet scale. They can also be used on multiple platforms, especially mobile.
While Authentication checks if a user exists on a platform, authorisation focuses more on verifying if a user or entity has the right to perform certain operations, such as whether a user can view the photos of other users in a photo-sharing application. There are several methods to be aware of, some of which include the following:
Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) is a security paradigm that allows users to have restricted access to resources based on their roles in the organisation. RBAC allows you to assign roles to users; each role grants access to one or more sets of rights and that in turn determines the kind of operation that particular user can perform on the platform.
The basic principle of Role-Based Access Control is simple; for example, the Human Resource department can’t see Finance data, and vice versa. When implemented correctly, RBAC will be transparent to the users. Role assignment happens behind the scenes, and each user has access only to the applications and data that they need to do their job. When you have a structured workgroup and want to be able to define the rights to a system by specific roles, RBAC is a great option.
Attribute-Based Access Control (ABAC)
Attribute-Based Access Control (ABAC) is an authorisation model that evaluates the characteristics or attributes of an entity, instead of roles, to determine access. For example, you might only want to allow users of a particular type, such as permitting employees in the HR department to access the HR/Payroll system, and only during business hours within the same time zone as the company.
At its core, ABAC enables flexible and fine-grained access control that allows for more input variables into an access control decision. Any available attribute in the directory can be used by itself or in combination with another to define the right filter for controlling access to a resource.
Because you can define access by employee type, location and business hours, ABAC is usually suitable for geographically dispersed workgroups, or when you want fine-grained access control policies.
OAuth 2.0, which stands for “Open Authorization,” is a standard that allows a website or application to access resources hosted by other web apps on behalf of a user. It’s a way of securely saying that it’s okay for a platform to use one of your trusted authentications to allow access to the platform resources. For example, you might use it to tell GitHub that it’s okay for Linkedin to use your GitHub profile.
OAuth is mainly used for authorisation and doesn’t share password data, but instead uses tokens to prove an identity between consumers and service providers. It also provides consented access and restricts actions that the client app can perform on resources on behalf of the user, without ever sharing the user’s credentials.
It is important to note that OAuth 2.0 is an authorisation protocol and **not** an authentication protocol. As such, it is designed primarily as a means of granting access to a set of resources available on another system, such as remote APIs or user data. It is therefore frequently paired with OpenID Connect (OIDC) to add authentication to the security workflow.
Open Policy Agent (OPA)
The Open Policy Agent (OPA) is a domain agnostic, general-purpose policy engine that gives you the ability to decouple policy and decision-making of a dedicated system. It automates and unifies policy enforcement and implementation across a wide range of technologies and across several IT environments, especially in cloud-native applications. OPA was originally created by Styra and has since been accepted by the Cloud Native Computing Foundation. The OPA is offered for use under an open-source licence.
Organisations use the OPA to automatically enforce, monitor and remediate policies across all relevant components. You can use OPA to centralise security, compliance and operational functions across Kubernetes, API gateways, continuous integration/continuous delivery (CI/CD) pipelines, data protection and more.
Other API security best practices
Finally, there are a few other best practices in API security that are worth mentioning:
Shifting left on API security with DevSecOps
While traditional security teams rely on testing software at the end of the build process, this often causes inefficiencies and delays as developers must spend time implementing security fixes to new versions before releasing features to the end customer. However, with DevSecOps—a philosophy that involves integrating security best practices during the development and operations processes—performing security tests is no longer done at the end of the build pipeline. Instead, it has become an integral part of the development process, allowing issues like vulnerable or outdated libraries, wrong API configurations, or possible sensitive data leakages to be discovered and fixed earlier.
Defining ownership for security
With the introduction of the DevSecOps paradigm, security becomes the responsibility of everyone on the team—from the developers to the QA and DevOps engineers. That means not only the security team is responsible for ensuring the software’s security, but all stakeholders must take a vested interest in the API’s security.
The benefits of ensuring that all stakeholders accept responsibility for a software’s security are enormous. It reduces the time it takes to identify issues and bottlenecks in software and the time it takes to resolve them. It also speeds up the time it takes to deliver value to end customers, and encourages accountability at each stage of the development as each stakeholder must put their best foot forward toward the achievement of the team goal.
An audit log is a record of events as they happen within a computer system. A system of log-keeping and records becomes an audit trail where anyone investigating actions within a system can trace the actions of users, access to given files, or other activities, such as the execution of files under root or administrator permissions, or changes to OS-wide security and access settings.
Audit logs are very useful when there is a need to identify or track the cause of an issue or event. For example, they can be used to track how data went missing on a platform. They can also be used to make informed decisions in the future as the data logged in real time can also serve as feedback on how to improve the system going forward.
Identity Providers (IdPs)
An identity provider (IdP or IDP) stores and manages users’ digital identities. Think of an IdP as being like a guest list, but for digital and cloud-hosted applications instead of an event. An IdP may check user identities via username-password combinations and other factors, or it may simply provide a list of user identities that another service provider (like an SSO) checks.
IdPs are not limited to verifying human users. Technically, an IdP can authenticate any entity connected to a network or a system, including computers and other devices. Any entity stored by an IdP is known as a “principal” (instead of a “user”). However, IdPs are most often used in cloud computing to manage user identities.
IdPs can be used when organisations need to delegate or outsource the managing and controlling of employee information from a central source without having to build a custom solution to do so. This can save time as well as provide a platform to manage all employee data in the long run, while ensuring that the security of user information remains tight.
How Tyk’s API Management platform enables API security
Tyk is a cloud-native API management platform for modern software. We enable users to use REST, GraphQL, gRPC and even SOAP-based APIs to connect to one another through our open source API gateway, while also providing an intuitively designed interface for monitoring and controlling the APIs.
Being one of the leaders in full life cycle API management, API security is top of our priority list. Here’s how Tyk enables organisations to secure their APIs:
Separation of concerns
Tyk’s API gateway enables developers to abstract their security layer from the back-end. This way the microservices can focus on the business logic of the application, while the API gateway can tackle the administrative aspects of the architecture. Tyk provides the flexibility of using Tyk’s out of the box authentication and authorisation capabilities, or delegating your security needs to external systems such as Identity Providers(IdPs) for Single Sign-On (SSO) or Dynamic Client Registration (DCR). Whichever the case, the consistent security policies provided at the gateway level ensures that all underlying microservices follow the same security standards across the application, thereby laying the foundation for scaling the application in a secure manner.
Authentication and authorisation
Tyk provides out of the box support for a variety of authentication and authorisation methodologies including those mentioned in this article previously. From Authentication (bearer) Tokens to OAuth2.0, from JSON Web Tokens (JWTs) to Role-based Access Control (RBAC), Tyk’s got your application covered. What’s even better is that if you wanted to combine or chain together multiple security methodologies, you could easily do that too!
Dynamic Client Registration (DCR)
Dynamic Client Registration (DCR) enables the dynamic registration of clients with your organisation’s existing authorisation server. Whether your organisation is using Keycloak, Gluu or Okta as your external Identity Provider (IdP), our DCR capability integrates with the Tyk developer portal without the need to overhaul the underlying authorisation mechanism.
Open Policy Agent (OPA)
API governance is an integral part of the modern enterprise FLAPIM (full lifecycle API management) stack. A key aspect of this is fine-grained access control. To enable this, Tyk has baked the OPA rule engine right into the gateway making it possible to create custom permissions securely and effectively. The OPA rule engine sits in front of the Tyk Dashboard, providing a high-level declarative language (Rego) that lets you specify policy as code and simple APIs, to offload policy decision-making from your software.
API monitoring and audit logs
Tyk provides the ability to monitor all API traffic in and out of the gateway. You can access and store detailed logs and audit trails of your entire API portfolio within Tyk’s dashboard. If you want to use an external monitoring system together with alerts such as Logstash or DataDog, you can easily do so by connecting to the Pump, which is responsible for the observability of your APIs.
API security is a very important topic as many applications today use APIs to communicate between systems. In this article, you have learned what API security is, how it can affect your software, and various methods and best practices you can apply to mitigate cybercrime or exposure of confidential data. You also learned the role DevSecOps culture plays in securing APIs, how security testing should be performed at each stage of the software development lifecycle, thereby reducing the time it takes to develop and deploy applications to the end users. Finally, by using tools like Tyk’s API management platform, you can ensure security across your entire application in a powerful, flexible and efficient way.