When switching from a single application to a microservice, the client cannot behave the same as if the client had an entry point to the application. Simply put, a part of the function on the microservice is different than if the application were implemented separately.

When using micro service at present, the client must deal with micro service architecture to bring all the complexity, the aggregate data from a variety of services, for example, maintain multiple endpoints, the connection between the client and the server and to separate each service authentication, etc., at the same time the client for micro service dependency is also directly contributing to the reconstruction of difficulties. An intuitive approach is to hide these services behind a new service layer and provide an API tailored to each client. This aggregator service layer, also known as an API gateway, is a common approach to this problem. This article introduces the advantages of API gateways in addressing security. See the full article for details:

All requests from the client first pass through the API gateway, which then forwards the request to the appropriate microservice.

Typical API gateways include

  • Security (authentication and potential authorization)
  • Manage access quotas and restrictions
  • Caching (proxy statements and caching)
  • API composition and processing
  • Route (” relay “) to the “internal” API
  • API Health Monitoring (Performance Monitoring)
  • Version Control (automated processes)

Advantages of API gateways

  • Managed and implemented in a unified location
  • Externalize most of the problems, thus simplifying the API source code
  • Provide an API administrator and view to facilitate consistent policy adoption

Disadvantages of API gateways

  • Prone to single points of failure or bottlenecks
  • Because all the API rules are in one place, there is a risk of complexity
  • The risk of being locked is not easy for future system migration

The growth of apis brings both opportunities and challenges

To grasp the rapid growth of apis, one need only look at the statistics of ProgrammableWeb, a database that has been collecting open apis since 2005. From about 100 listed apis in 2005, there are now more than 10,000 public apis, and this growth is increasingly dependent on the economy of user data repositories. Salesforce reportedly generates more than 50% of its $3 billion in annual revenue and Expedia nearly 90% of its $2 billion in annual revenue through apis.

Companies generate API revenue by calculating access to apis and the resources behind them in a variety of ways. For example, Twitter, Facebook and others offer ad-based apis that allow targeted advertising based on reports and analytics, but AD agencies and other brands must pay for access to these apis.

The ROLE of API gateways in security: authentication and access control

Access control is the first big security driver for API gateway technology, acting as a kind of controller so that organizations can manage who has access to the API and establish rules about how data requests are handled. Access control can almost extend to establishing other policies, including rate limits on API calls to certain sources, and even requirements to access all or some resources through the API.

The access control functionality of an API gateway typically starts with an authentication mechanism to determine the actual source of any API calls. Currently, the most popular gateway is OAuth, which acts as an intermediary for accessing Web-based resources without exposing passwords to services and is retained based on authentication, in which case the enterprise can afford to lose data and keep the keys completely secret.

Communications security

Gateways are a great way to evaluate, transform, and secure communications across an organization by connecting all API services over a single channel. When all traffic is routed through the gateway, the IT security specialist is able to move to all project dynamics.

API gateways can make internal services more secure by introducing message security between them, and messages that pass back and forth between them are encrypted. Ignoring proper authentication can cause problems even when transport layer encryption (TLS) is used. For example, by using a valid mobile phone number in an API request, anyone can obtain personal email addresses and device identification data. Industry standard strong authentication and authorization mechanisms like OAuth/OpenIDConnect, as well as TLS, are critical.

Threat protection

Without threat protection, the API gateway, its API, and the native services of the integration server are essentially insecure. This means that potential hackers, malware or any anonymous external person can easily try to spread a range of attacks, such as DDoS or SQL injection.

Apis are the gateway for an enterprise to connect digitally to the world. Unfortunately, some malicious users aim to access back-end systems by injecting “extra” commands or expressions to delete, update, or even create arbitrary data that can be used with the API.

For example, in October 2014, Drupal announced an SQL injection vulnerability that gave attackers access to databases, code, and file directories. Even the most serious aspect of the attack is how much of an impact it would have on the enterprise if the attacker could copy all the data outside of the client site. There are many types of injection threats, but the most common are SQL injection, RegExInjection, and XML injection. Not uncommon in reality, we’ve seen apis go live without threat protection on more than one occasion.

Information protection

Many API developers are used to using 200 for successful requests, 404 for all failures, 500 for internal server errors, and, in some extreme cases, 200 for the body with a failure message on top of a detailed stack trace. When stack traces reveal the underlying design or architectural implementation in the form of package names, class names, framework names, versions, server names, and SQL queries, they can leak information to malicious users.

It is appropriate to return a “balanced” error object with the correct HTTP status code, the minimum number of error messages required, and no stack trace in error cases. This will improve error handling and protect API implementation details from attackers. The API gateway can be used to transform back-end error messages into standardized messages, making all error messages look standardized and eliminating the hassle and danger of exposing back-end code structures.

Whitelisting and methods for allowing whitelisting

For API traffic at the IP address level, there should be a known list of device, server, network, and client IP addresses. The size of this list will vary depending on how tight the network is.

RESTful services are common and allow multiple methods to access a given URL for different operations on that entity. For example, a GET request might read an entity, a PUT would update an existing entity, A POST would create a new entity, and a DELETE would DELETE an existing entity.

It is important for the service to limit the allowed verbs appropriately so that only the allowed verb requests work and all the other verbs will return the correct response code (for example, 403 Forbidden).

Message size

It’s good to have message size limits. If you are absolutely certain that you will not receive large file messages (for example, messages larger than 2MB), limiting the size of large file messages to filter out can prevent unknown attacks as much as possible.

SQL injection

SQL injection protection allows you to block requests that could lead to SQL injection attacks.

JSON Threat Prevention

JavaScript object representation (JSON) is vulnerable to content-level attacks. Such attacks attempt to overwhelm the parser with huge JSON files and eventually crash the service.

XML Threat Prevention

Malicious attacks on XML applications typically involve large recursive payloads, XPath/XSLT or SQL injection, and CData to overwhelm parsers and eventually crash the service. For more information about input validation, visit here.

The speed limit

All API users need to be authenticated and all API calls logged so that the API provider can limit the utilization of all API users. Many API gateways allow you to limit the number of API calls that can be made to any single API resource, specifying consumption in seconds, minutes, days, or other relevant constraints.

API Gateway: Open source

Here are some products worth using:

  • GOKU API Gateway
  • Kong API Gateway
  • Tyk API Gateway

conclusion

When talking about API security, it is important to understand that security is a top priority for companies, organizations, institutions, and government agencies considering investing more resources into their API infrastructure and protecting their existing work. It is also the most under-represented area in terms of investment in API infrastructure by existing API providers. Many companies are building their own apis as products to deploy Web, mobile, IoT, and other applications, but at every step of the way they need to secure information, and API gateways are one of the most popular and effective solutions for these applications.

The resources

Dzone.com/articles/th…