Nowadays webservices are used a lot and a "new" kind of product is in the streets: the API Gateway. This solucion is published to Internet, receives the requests for webservices from external parties and mobile apps, do some security (authentication, authorization, some products do validation of inputs, XML and JSON security, etc.) and then the request is passed to the internal webservice.

What security controls should be done in the API Gateway and what security controls should be done in the web service?

For example,

  • Where should be done validation of inputs?

  • Authentication?

  • Authorization? Business logic security?

Moreover, one person today asked me if we should put the API Gateway between a web application in our DMZ and our internal bus...I replied that in this scenario all the security needed should be performed by the web application so the API GW is not needed...Am I right?

  • Not really a duplicate but closely related: What is the real benefit of a three tier architecture?. Within a multi-tier architecture you usually have clear and comprehensible roles where authentication, validation and business logic is done and such a architecture is recommend for security reasons too. Commented Sep 3, 2016 at 12:30

1 Answer 1


An API Gateway is responsible for managing the public interface presented to external customers. It should handle low level issues like:

  • protocol compliance
  • blacklisting
  • rate limiting
  • quotas
  • versioning
  • request normalization

It can interface with:

  • a discovery system to know which internal web services should handle what public endpoints
  • a routing system to know how to translate public routes to internal routes
  • an authorization system to know how to translate external API tokens to internal authorization credentials, so that individual web services don't have to repeatedly ask for those themselves.

In short it should handle common issues across the public surface area of API. It should not have any knowledge of the specific business logic details of a particular web service or a particular route.

Individual web services need to validate their own inputs. Only individual services know what parameters are valid and what types those parameters can assume. However, if the web services use JSON payloads, the API Gateway can do basic JSON validation and perhaps even check payloads against JSON Schemas for them on a per-URL basis.

An API Gateway can handle authentication, as it usually can be connected to an Identity Provider, has knowledge of various authentication protocols, and can be configured to provision authorization tokens. Though often folks have their own authentication schemes and workflows that go beyond what an API Gateway provides out of the box.

An API Gateway should certainly validate authorization tokens provided by external callers, and should help simplify some aspects of access control that individual web services face by enhancing payloads with roles or rights the authorization token is entitled to. But individual services are still responsible for granular checks of those roles, and business logic security.

An API Gateway is often configured at the edge or in a DMZ, as it faces untrusted traffic and has a responsibility to transform it into a more syntactically normalized form. Web services are still responsible for semantics.

If an HTML-generating web application consumes APIs, there is a policy decision about whether that application consumes only public-facing APIs, or also can consume internal APIs directly from internal web services. There are pros and cons to both sides. The architecture emerges from that decision.

  • Does this mean that core validation should be done in the services? For instance, if I would like to add a validation that allows an user to only add 10 comments to a post, while I want an admin to be able to skip that validation, should this also be done in the service? or is it possible to add custom validations in each gateway if many are used for different apps ?
    – Kilise
    Commented Mar 27, 2018 at 15:16
  • Hey @kilise- that's a good example of a service-level validation. A gateway can be used in a general way to prevent non-admins from accessing admin-only URLs, but specific logic/rules for admins vs nonadmins really lives in the application. Enshrining it in the gateway becomes difficult to support. That said, having to produce a new build to just change a rule can also be painful. The solution there is to separate security/validation policy from code, either by putting it into configuration or using a policy language. Commented Mar 27, 2018 at 16:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .