A few weeks ago I blogged about different Mobile Middleware usage models for enterprise. Continuing that thread, this post will drill down into API security considerations for enterprise mobile apps.
Mobile applications are typically intended for use outside of the corporate network. This requires the enterprise to expose APIs and web services to the Internet, where previously they were made inaccessible by the corporate firewall. While it is a good practice to protect even inward-facing services, the likelihood of a malicious attack is orders of magnitude higher for external-facing APIs.
Even if these services were previously exposed through a web portal, additional security must be considered. Most modern web portals adopt some variation on the classic three-tier architecture, in which only the presentation tier is exposed to the Internet. On the other hand, many web services place business logic at the endpoint, exposing the server. Furthermore, the API server will have access to a database, so a compromised server can lead more directly to data loss.
A services gateway allows the enterprise to minimize the attack surface for the mobilization program. Rather than having to protect one or more servers for each external-facing API, the proxy model results in a single server or cluster responding to external traffic. The actual web services can then be further restricted, only allowing connections to the gateway and to internal systems inside the DMZ or corporate intranet.
A variation on this model, illustrated by the figure below, uses a pair of gateways to securely expose internal APIs while eliminating the need for a duplicate instance of the API deployed to the DMZ. This involves deploying one gateway inside the DMZ and a second gateway inside a secure enclave. Inbound traffic is permitted to access the first instance, while the second instance only accepts traffic from the first. It should be noted that this is only feasible with gateways that can be deployed on-premise due to the need to securely host one gateway inside the secure enclave.
Use of a security gateway also makes it easier to implement and enforce consistent security policies for all APIs. Instead of adding custom code to each API or tuning each server individually, a consistent set of checks can be performed at the gateway layer. For example, an enterprise can define a package of checks that includes SQL injection scanning, overflow scanning, and cross-site scripting prevention.