API security starts with authentication and authorization, then data security and availability. In this post, I will review security considerations for an API gateway and how the capabilities of the Kong Gateway address them.
First, let's review different aspects of API security in detail.
API Security
A well-designed API should support the following security characteristics or pillars:
Authentication: An API should guarantee the confidentiality of the information it processes by making it visible only to the users, applications and servers that are authorized to consume it. Let’s collectively call the users, applications and servers the "consumers" of the API. In order to guarantee this security quality, APIs should have the ability to identify these consumers. This is achieved through various forms of authentication.
Authorization: An API should support role-based access to data and provide the data only if consumers are authorized to consume it. This is achieved through retrieving scopes, roles, groups and other attributes associated with these consumers based on the identity.
Integrity: It must be able to guarantee the integrity of the information it receives from the consumers and servers that it collaborates with. It will only process if it knows that it has not been modified or tampered with by a third party in transit. This is achieved through verification that the message was not modified using digital signatures.
Confidentiality: It must be able to guarantee information confidentiality. The integrity of a message sent by a known consumer is assured, but in transit, it may have been spied on or sniffed by a third party. The message/data may have private details like personally identifiable information (PII), personal health information(PHI) or financial information that should be kept confidential.
It is necessary to hide those details from the point of delivery by the consumers to the reception by the API and server. This is achieved through message encryption and transport layer security (TLS).
Safety: It must provide interface documentation that details request, response and authentication/security schemes. Interface/API documentation provides security benefits like message validation that prevents harmful data attacks, SQL injection, sending too big messages (by validating the size of the message), etc.
Availability: It must be always available and respond to requests. This includes the ability to scale API based on load, prevent overloading of upstream services and protect against denial of service attacks.
Let's review each of these characteristics or pillars in detail.
Authentication and Authorization
Authentication involves identifying the requester of information or resource and challenging that entity for authentication material or credentials. Authorization involves verifying whether that authenticated entity actually has permissions to execute a function or CRUD (create, read, update and delete) operations on data. Authentication and authorization are foundational to all security domains, including API security.
As organizations have shifted towards heavily distributed architectures and the use of cloud services, the traditional security best practice of locking down a perimeter has become less useful. The identity of the consumers is stored in Identity Access Management (IAM) and is now used heavily to control access to functionality and data, and is also an enabler of zero-trust architectures.
When considering security best practices for authentication and authorization, API and the IAM should be able to differentiate between user identities and machine identities. While it is possible to challenge a user for additional authentication material in a session, this option is not available for machine communication. The API also should support federated identity providers as most organizations have multiple security contexts and identity stores/providers.
There are several methods that support authentication:
- Basic Authentication: This is where consumers pass username/password in headers. It is an older authentication method and is not recommended.
- API Keys: This is a static key or id identifying the consumer. API keys alone are not a sufficient form of authentication and should be used primarily as one form of identification. If API keys are used, ensure that consumption is monitored and rotate API keys often. Realistically, API keys should be paired with additional authentication factors such as certificates (option d).
- OAuth Tokens: OAuth tokens are based on newer authentication protocols like OpenID Connect and authorization protocols where the tokens are valid for a limited period.
- Mutual TLS: Certificate-based authentication is more common for machine-to-machine communication and automation scenarios where it is not possible to obtain additional credentials.
Authorization is mostly achieved through the scope (what level of information and action requested), roles (the roles that user or applications play in the organization for example claims customer representative or Teller, etc), groups (department or group the user or application belongs to) and other attributes associated with consumer identity or token. These attributes are validated against the approved list, and access is then allowed.
Data Integrity
Data/message integrity includes the verification that the message was not compromised in transit by a malicious third party. In other words, the message received by the API is verified as being exactly the one sent by the consumer. The same goes for when the API acts as a client to a server.
This is typically achieved by using JSON Web Token (JWT), an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.
JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA. JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are.
The idea here is that consumers create a signature using parts of the message, some algorithms, and a secret code or certificate. As the signature is calculated using the header and the payload, you can also verify that the content hasn’t been tampered with. Then the API should apply the same algorithm with shared secret code or certificate to produce its own signature and compare the incoming signature against this.
Data Confidentiality
Data confidentiality is about securing private data and protecting against sniffing attacks in transit by a malicious third party. Depending on the data security goals and impacting regulation, appropriate techniques for protecting data include masking, tokenizing or encrypting.
Many data security efforts focus on securing data at rest in the back-end, such as database encryption or field-level encryption. These approaches protect organizations from attacks where the data storage is targeted directly but doesn't prevent attacks during data transit. The API should protect data during transit.
The encryption or tokenization can be achieved by using an algorithm and shared secret or certificate. It is not recommended to encrypt the entire message but selectively only the private data and not to send too much data.
Data Safety
Data safety is about protecting the API and the backend from potentially harmful data in the message. These attacks are often done by sending huge JSON or XML data, binary executables, SQL injection, etc. in the message.
Data safety starts with a well-defined interface of the API using open standards like OpenAPI Specification (OAS). This API definition is also known by different terms in the industry, like Swagger and RAML. Once the interface is defined, it can be used for message/data validation that will help reject messages that don’t conform to the interface specification.
This validation can protect against bad actors sending binary executables, attachments and huge data that can either attack the server hosting the APIs or the backend that API connects to.
API Availability
The API must guarantee that it is always available to respond to calls within service level agreement (SLA) and it can handle the traffic without losing data or dropping the message. This can be achieved by horizontally scaling the API across multiple servers and protecting against attacks like denial of service (DoS) attacks, bots and bad actors that may keep the API or server busy and not respond to actual/valid consumers requests.
This is achieved by fronting the API gateway with a web application firewall (WAF) and API gateways' built-in features like IP address restriction, bot detection, dynamic rate limiting, etc.
How an API Gateway Secures APIs
Kong Gateway is a lightweight API gateway that lets you secure, manage and extend APIs and microservices across hybrid or multi-cloud infrastructure. Kong Gateway is available as an on-premise or private cloud and with Konnect, the SaaS platform.
The power and flexibility of the Kong API gateway come through its plugins that integrate seamlessly with the deployments. There are multiple Kong plugins available to handle authentication, data security, rate limiting and more. Check out Kong's Plugins Hub for more information.
Kong's API gateway addresses most of the API security characteristics or pillars listed in the above section. In this section, let's review what those options are and how Kong supports them.
Authentication and Authorization
Kong Gateway provides the following plugins for authentication and authorization:
The first set of plugins is provided to support legacy consumers that still use API keys and username/password-based authentication.
Key Auth Plugin: Apply this plugin if the consumers use API keys to get authenticated. Note that API keys alone will not be sufficient, and we recommend combining with a mutual TLS plugin. This plugin allows you to auto-generate the API keys or keys from existing platforms or identity stores if you are migrating.
Basic Auth Plugin: Apply this plugin to pass client id/client secret-based authentication where either Kong or external identity provider acts as the identity store. If it’s Kong, the id and secret are auto-generated, whereas with an external provider, you have the option to upload that id and secret.
LDAP Authentication: Apply this plugin if LDAP-based authentication is still in place. This is mostly used to support legacy consumers during migration.
Vault Authentication: This is almost the same as the Basic Authentication plugin, but the ids are stored in an external vault with the expiry time. These ids can be sent in the basic auth header or custom headers.
ACL: Use this plugin in combination with the above authentication plugins to validate authorization.
Beyond the basic login steps of entering a username and password or passing API keys, other means of facilitating authentication and authorization include OAuth2.0, OpenID Connect and mutual TLS, which are all supported by Kong using the below plugins
- OAuth 2.0: Use this plugin when Kong acts as the identity provider supporting all OAuth 2.0 grants.
- OpenID Connect: Use this plugin when external identity providers are used for OAuth 2.0. To assert the authorization, make use of consumers, roles, groups and scopes attributes.
- Mutual TLS: If the consumers cannot support OAuth 2.0 and/or process more secured data, make use of the mutual TLS (certificate-based authentication) plugin.
- CORS: Add this plugin to prevent any cross-origin resource sharing hack. This plugin should be combined with API keys and OAuth 2.0-based authentication when the consumer is accessing the APIs directly from the browser.
Data Integrity
Kong Gateway provides the following plugins for data or message integrity:
- JWT Signer: Use this plugin to validate signatures and/or sign using certificates
- HMAC: Add HMAC Signature authentication to a Service or a Route to establish the integrity of the incoming request
Data Confidentiality
There is no out-of-the-box plugin that supports message encryption or masking. But you can create custom plugins using Lua crypto libraries. The Kong API gateway mostly acts as a pure proxy and doesn’t access/modify the message, so this can be offloaded to the service providers.
Data Safety
Kong Gateway provides the following plugins for data safety or protection against harmful data. Kong recommends a design-first approach and provides Insomnia to create the API specifications using OAS standards. These API specifications are published to the developer portal (catalog), where the consuming application developers can explore and the specifications are used by Kong proxy for data validation.
- Request Validator: Use this plugin to validate requests before they reach the upstream service. Supports validating the schema of the body and the parameters of the request. This validation protects the API and service from any harmful or unwanted data. The messages are rejected if they don't adhere to the schema.
- Request Size Limit: Apply this plugin to allow requests only with valid sizes. It also can be used against denial of service attacks.
- Custom plugins are available to protect against JSON/XML threats.
API Availability
Kong Gateway does not provide a Web Application firewall and OWASP protection, but can be done through external providers like Akamai, Amazon Advanced Shield, etc. There are other Kong plugins provided by security vendors like Salt Security, Cleafy, Signal Sciences and Wallarm that protect the APIs against most of the attacks below. These plugins require subscriptions from the vendors and require connectivity to their systems from Kong runtime.
- OWASP Top 10
- Application DoS
- Brute force attacks
- Account abuse and misuse
- Request rate-limiting
- Account takeover attacks
- Bad bots
- Virtual patching
Kong Gateway provides the following plugins for API availability and protection against denial of service attacks.
- IP Restriction: Use this plugin to allow only known consumers to use IP addresses. It has both allow and deny rules.
- Rate Limiting: Use this plugin to dynamically rate limit or throttle consumers based on their identity or IP address.
- Bot Detection: Use this plugin to reject messages that are sent by bots that may try denial of service attacks.
- Request Size Limit:Use this plugin to limit message size that protects from denial of service attacks.
- Proxy Caching: Use this plugin to cache frequently requested messages, reducing the time to serve and protect from stressing the upstream API.
- Web Attack Protection: Use plugins from Signal Sciences, Salt Security, Cleafy and Wallarm
Kong Gateway also provides full support for automation that allows scaling Kong dynamically using Kubernetes or using CI/CD pipelines
Conclusion
In this post, we reviewed API security considerations and how Kong Gateway addresses all those security concerns.