APIs are critical to the majority of businesses and are thus high impact targets that should be protected with secure tooling and secure architecture. The OWASP Foundation has recently published their API Security Top 10 which outlines common threats to APIs. In this article, we will explore these vulnerabilities (and more) within a cloud security context. Note that the following advice is applicable for all major API implementations including: REST, SOAP, GraphQL, and gRPC.
Taking a cloud-first approach by using a cloud service provider such as Amazon Web Services (AWS) or Google Cloud Platform (GCP) affords organizations the ability to use managed services geared towards API security. Cloud services by nature are extensible, configurable, and scalable - which are key features of a properly secured API. By leveraging cloud native AWS and GCP services, you unlock security functions such as DDoS protection, threat prevention, secure hybrid architectures, logging, and monitoring. Following are some security recommendations from a cloud infrastructure perspective.
Rate limiting and throttling are two techniques that help mitigate distributed denial of services (DDoS) attacks. This is typically enabled in the configuration of an API Gateway (for more information see “Introduce Rate Limiting and/or Throttling” below), however both AWS and GCP have services that help with DDoS as soon as the service is deployed. AWS Shield is a managed service that safeguards DDoS attacks. Similar to AWS Shield, Google Cloud Armor is a managed protection service that mitigates network layer 3 and 4 DDoS attacks. Both Cloud Armor and Shield have Standard (free) and Premium/Advanced (paid) tiers, and it is recommended to enable the paid tiers to protect against DDoS attacks directed at an organization’s cloud resources.
Using a WAF can help protect against OWASP Top 10 web vulnerabilities, including cross-site scripting (XSS) and injection flaws such as SQL injection. In addition to DDoS protection, Cloud Armor has WAF protection capabilities utilizing layer 7 filtering policies and out of the box OWASP Top 10 mitigations. AWS WAF is the web application firewall service for AWS. It is recommended that all API endpoints be fronted by a WAF for application layer network security.
An often unsung hero of security is logging and monitoring. Proper logging and monitoring is at the heart of essential cloud security capabilities such as incident response, forensics, automation, and application debugging. It is imperative to have sufficient logging capabilities for all deployed APIs. On AWS, CloudWatch logging can be configured for API Gateway deployments of REST APIs, Websocket APIs, and HTTP APIs. On GCP, Logging is available for API Gateway and Cloud Endpoints via Extensible Service Proxy (ESP). All endpoints should have logging and monitoring enabled for security audit purposes.
On-premises resources can be fronted with Amazon CloudFront via custom origins, a private API in Amazon API Gateway, or Apigee hybrid to take advantage of cloud security services, including AWS WAF and Google Cloud Armor.
Google Cloud has many options when it comes to servicing API architectures. It is easy to become confused by the different solutions. The table below breaks down several features to compare:
| Cloud Endpoints | Google Cloud API Gateway | Apigee | |
|---|---|---|---|
|
Works with many GCP Services |
Yes, with ESP | Yes | Yes |
|
Routes to Multiple Backends |
No | Yes | Yes |
|
Hybrid Support |
No | No | Yes |
|
Advanced Security Features |
No | No | Yes |
|
Cost |
Low | Medium | High |
Some highlights of Apigee’s advanced security features are data masking/hiding, content-based security, key/value maps, and property sets. These position an organization for enterprise-level security - at an enterprise-level cost. For most organizations, Cloud Endpoints or API Gateway provide the security capabilities that are highlighted throughout this article.
Just as important as having a secure cloud infrastructure configuration for APIs, is having endpoint (or “last mile”) security enabled for API endpoints as well. The following sections speak to API endpoints security and how AWS and GCP features can assist organizations in their security journey.
A healthy vulnerability management program is an important part to any organization’s risk management strategy. This is especially true for public-facing or mission critical APIs, and for that reason we recommend prioritizing the scans of those endpoints. We recommend scanning and fixing API vulnerabilities at least quarterly (based on PCI standards), and optimally on a continuous basis using services such as GCP Web Security Scanner.
Misconfigurations should be constantly remediated in an organization’s environment as well. Employing a continuous monitoring solution such as AWS Config API Gateway configuration monitoring can significantly reduce the risk associated with misconfiguration of API gateways and endpoints.
Encryption in transit helps ensure the confidentiality of information as it is transmitted over the internet or within internal networks and is mandated by many compliance regimes such as the PCI-DSS and NIST. HTTPS uses Transport Layer Security (TLS), which ensures secure connections for APIs. It is recommended to use TLS 1.2+ for this. In addition to having HTTPS enabled for API endpoints, HTTPS should also be enabled for APIs that are interacting with other backend APIs (via mutual TLS or encryption/re-encryption at service points).
For AWS, Amazon API Gateway has integration with Amazon Certificate Manager (ACM) to issue both public and private TLS certificates for securing APIs. For GCP, services are registered with Google Front End (GFE), which allows configuration of public TLS certificates. For private certificate authorities (CAs) on GCP, the Certificate Authority Service is currently in preview.
An API should always be able to identify a client or user properly. Using JWTs helps ensure that a strong authentication mechanism is in place and mitigates the threat of API compromise. The main difference is that an API key is generally a static credential that is not rotated often, whereas a JWT is an access token that has an expiration period. The shorter the expiration period, the less likely the credential can be used to impact resources, and thus the less risk an organization accepts by using them. In addition to authorization capabilities, authenticity and nonrepudiation are also guaranteed because a JWT contains a digital signature. Both AWS and Google Cloud allow controlling access to APIs by using JWTs with configurable refresh tokens.
Security in general is constantly undermined in complex systems due to the larger attack surface that these types of systems tend to have. Authentication is no exception - having complex hierarchies, roles, and groups can make separation of duties difficult to accomplish. Using a straightforward identity store with simple, yet well defined, control policies removes friction for (and therefore encourages) developers to create secure APIs. AWS Cognito allows a simple user sign-up, sign-in, and access control via AWS Identity and Access Management (IAM). For Google Cloud, user objects in Firebase projects can be used in a user database.
Ensure that authenticated identities only have access to the objects necessary to perform the action given to the API endpoint, and no more. For AWS, rightsized IAM policies can help restrict permissions once an IAM principal is authenticated to an API. For Google Cloud IAM, least privilege can be enforced using IAM Recommender. Organizations should follow the principle of least privilege throughout their cloud environment and not just their API endpoints.
OAuth 2.0 is an authorization framework used for REST APIs. It uses JWTs to represent claims from a client to a server. In OAuth 2.0, scopes may be used to restrict the types of operations (and therefore data) that a token bearer may have access to. It is recommended to only allow limited, clearly defined OAuth scopes to perform only the actions necessary for an application’s or user’s purpose. To secure REST APIs, either AWS Lambda authorizers or GCP Cloud Functions can be used to authorize OAuth 2.0 services. Note that the use of OAuth 2.0 requires an identity provider (IdP), which could be AWS Cognito, Firebase, or a third-party IdP. Organizations should strongly consider using OAuth 2.0 to enhance the security of their APIs.
Parallel to following the principle of least privilege, an API endpoint should only return the minimal amount of data necessary for a request. Limits on data exposure should be defined in API requirements. For the sake of convenience, developers tend to create generic implementations of objects returned by APIs ,which in turn can expose more of an object’s properties than is necessary. For APIs that are used as backends for frontend clients, the onus should not be on a client to perform data filtering - rather the threat of sensitive data exposure should be stopped at the backend API layer wherever possible. To achieve this, an allowlist to explicitly define all parameters and payloads that are expected can be implemented. Using an allowlist mitigates risks associated with mass assignment.
It’s important to know if the requests your API is receiving are valid. Attempting to process invalid requests can result in a security breach or lack of availability due to the processing required to serve these requests. It is recommended that organizations validate requests for all of their API endpoints. Request validation can be enabled in AWS API Gateway and Apigee.
Rate limiting and throttling helps mitigate threats against the availability of APIs. A proper throttling strategy helps mitigate DDoS attacks and brute force attacks. The amount of rate limiting and throttling required depends on how often the API should be accessed and the ability of the client to retry the request using techniques such as exponential backoff, caching, and circuit breaking. AWS has limit settings (throttling) or usage plans (rate limiting) that can be configured for API Gateway. Google Cloud has prescriptive guidance on rate-limiting strategies and techniques that covers Cloud Endpoints, Apigee, and other GCP services.
This article has been written to address the main security concerns when it comes to API security and serving infrastructure and endpoints inside a cloud environment. Having robust API security is essential for business operations, and can be achieved by leveraging cloud native solutions.