Serverless and API Gateways
Serverless and API Gateways
Learn what API gateways are and how they protect serverless systems and similar environments from malicious code, data, and attacks.
Join the DZone community and get the full member experience.Join For Free
Although the serverless, Function as a Service (FaaS), and microservice architecture models allow services to be built more effectively and efficiently, they also highlight the clear need and necessity of appropriate governance, risk, and compliance management. These models are termed “serverless,” yet there is an environment component involved. The code has to reside on some platform to function and the similar issues one would have encountered with any other server or environment have to be deliberated.
As anyone would say, once access to the environment is gained, you can do a lot of damage to the wider network, so one should still be mindful of numerous exploits such as code injection and cross site scripting. In the microservices world, information exchange and communication between service endpoints happen via messages and any content within a message sent to an upstream endpoint can potentially lead to a state that might encourage an attacker.
Some possible scenarios:
- A message containing malicious data causing a service to fail inadvertently.
- A message containing malicious code that the service unintentionally executes.
- A mechanism that enables unauthorized access to system resources.
What Is an API Gateway?
In a nutshell, an API Gateway is a proxy that has information about the main microservice endpoints, mediates, and routes and invokes a respective endpoint after request verification, content filtering, authentication, and authorization.
A demonstrative functional view of an API gateway is depicted below:
A typical API gateway would have the below ingrained serviceable competencies or features:
- Content Attack Prevention (CAP)
- Security Policy Configurations and Enforcement
- API Registration and Publishing
- Routing and Service Mediation
- Traffic Management and Message Throttling
- Monitoring of Microservices (QoS)
Role of API Gateways in the Microservices World
Every solution that provides Function as a Service (FaaS) or microservice based models has to have an API gateway that sits between the invocation of the function and the web. This is extremely important as the primary objective of API gateways is to impede and prevent the offending traffic before it does any damage to the entire system. Putting the API gateway in between means that only a trusted source has the ability to access the API gateway, and that provides added protection.
Gone are the days of the domain being the only way in. One of the nice things that an API gateway enables is that the client doesn’t have to know a component’s address. The main API URL published with the gateway is obfuscated and abstracted on a separate layer so that implementation or the interface can be changed while still keeping the public interface the same for existing clients.
Policy Configuration in API Gateways
Content attacks are messages that contain malicious data, which is sent to a service. Content attacks include special characters, text patterns, and SQL and XPATH injections. As part of the security implementation process, CAP policies should be configured for both inbound and outbound traffic that can protect against SQL and XPATH injection attacks and forbid DTD’s through
- Limiting HTTP Versions, Methods, and URL Path
- Defining a Whitelist of Domain Names
- Defining a Whitelist of Client IP Addresses
- Defining a Blacklist of Client IP Addresses
- Limiting Query Parameters
- Limiting HTTP Headers
- Creating a List of Forbidden Words
- Creating a List of Forbidden Regular Expression
- Creating a List of Required Regular Expression
Illustrative Request Response Workflow Sequence
One of the best practices would be to apply the predefined security policies on an incoming message before routing to a particular microservice, and also to the microservice message response being sent to the client. A symbolic request-response sequential workflow between the client and microservice would be as follows:
- The client or IoT device sends a message request to micro service via an API gateway.
- An inbound CAP policy scans the message request details for content-based attacks. If the message request violates the CAP policy, then the API gateway drops the message request and returns an error to the client. The error indicates that the message request violates the CAP policy.
- The API gateway passes verified messages to the service mediation layer.
- The service mediation layer performs identity verification and authenticates and authorizes the request.
- Based on the authorized and authenticated request type, the respective microservice endpoint is invoked and messages are processed. The microservice might internally call another microservice, or multiple microservices are invoked based on the request type configured.
- An outbound CAP policy scans the message response details for content-based attacks. The API gateway passes the verified response back to the clients. The message can be enriched or transformed before sending the response.
- If the message response violates the CAP policy, then the gateway drops the message response and returns an error to the client. The error indicates the message response violates the CAP policy.
Opinions expressed by DZone contributors are their own.