Is Your Entire API Stack Secure?

31 Oct 2019
by: Randy Allen | 15 Minutes

True security must exist at all layers

It’s all too easy to think of your API process as a single entity with a single set of security concerns. But just because you’ve made all the right security decisions for one component doesn’t mean your API’s are safe from vulnerabilities lurking where you least expect them.

Vanick has adopted an approach that encompasses an 11-layer “API Stack,” wherein each layer has its own particular set of security concerns and solutions. Not only does this avoid a perspective that might overlook otherwise hidden weaknesses, but it also allows the security strategy to be effective at each level without compromising the speed, safety, or simplicity of other parts of the stack.

What layers are contained in the API stack?

While it is possible for an API product to exist without involving each of these layers, a well-designed API practice must have a security plan for each of them. They include both runtime and design time components, but they don’t include adjunct systems such as log management, visualization, and monitoring solutions.

1. The Content Delivery Network

The CDN plays a role in static content delivery, edge caching, and DDoS protection. Because its threats include provider overload, false positives, and improper caching, Vanick believes this layer should store only non-sensitive data, employ stringent cache-control headers, and delegate functions to the API Gateway layer when possible.

2. The OAuth Server

At this layer, bearer tokens and ID tokens are issued as well as validated. Not only is the OAuth server subject to the risk of brute force and web site attacks (e.g. CSRF, XSS, etc.), but it is also subject to information leakage. Vanick’s primary recommendation for mitigating these risks is to use OpenID Connect and to keep security measures at this layer simple. Additionally, we suggest delegating lockouts to the Identity Provider layer and throttling OAuth endpoints.

3. The Identity Provider

While similar in function to the previous layer, the Identity Provider is distinct in that its role is to authenticate and attest claims. Clearly, this means this layer is subject to many of the same risks as the OAuth Server, as well as harm that could be caused by improper configuration. Here, the security strategy should include lockouts as well as true two-factor authentication (2FA) and limitations to API access from the OAuth Server. Even more crucial is the need to hash all credentials at this level.

4. The Developer Portal

Often mistaken for nothing more than a means to offer self-service API access, the Developer Portal is furthermore a critical tool for encouraging developer engagement. In pursuit of developer engagement, however, an API practice might inadvertently grant access to too many API’s or even the wrong environment. Much like the OAuth layer, the Developer Portal can likewise be subjected to web site attacks such as CSRF. The number one way to avoid threats at this level is to always keep the portal patched. Also, creating workflows for approving access to the production environment will help avoid improper access grants.

5. The API Gateway

In many ways the beating heart of the practice, the API Gateway layer manages access control, transformation, and analytics. As in the Developer Portal, the Gateway can suffer if improper access is given out. API Gateways may also be targeted by denial of service attacks. To mitigate such threats, OAuth2 and OpenID Connect should be used for authentication validation. Moreover, the API practice needs to make use of the role-based access control, traffic throttling, and white/black list features in the Gateway. Vanick encourages limits to the complexity of policies, the use of certificate pinning, and implementing TLS.

6. The Gateway Backside Cache

This layer simply handles response and data caching. Subsequently, its main threat comes from incorrect caching and invalidation, as well as cross-API cache data access. Generally, such threats can be addressed by authorizing before reading from the cache, using separate caches for sensitive data, and enforcing cache-control headers.

7. Firewalls

As the typical means for network boundary enforcement, firewalls usually have the attention of the security team. Beyond the risks posed by cross-network access, API’s might generate unauthorized service traffic. This can be curtailed by clearly defined API network boundaries, the enforcement of mutual TLS & IP restrictions, and implementing IDS to detect anomalous traffic.

8. Façade

The façade layer is focused on transformation, orchestration, and business logic. Like the previous layers, it must address the risk of unauthorized access to data in addition to invalid data inputs. Claims from the Gateway layer should be passed to enforce attribute-based access control, mutual TLS should allow access only from the Gateway, and the API practice must emphasize that data validation is everyone’s responsibility.

9. Microservice-Aligned Data Store

Here is where CQRS query handling takes place. As a rule, the main risks at this level are data exfiltration, stale data access, and lost writes. Beyond cautious configuration, Vanick recommends the use of TLS and authentication mechanisms to reduce these risks. Additionally, only storing needed data and updating with triggers (or using write-through cache) are wise approaches.

10. Backend Service

Customarily, many security decisions have already been made at this layer, where business logic and legacy system access are conducted. Still, unauthorized service traffic, invalid data inputs, and unauthorized data access can still endanger the Backend Service. Besides these risks, this layer also possesses a limited ability to change. Mutual TLS is the obvious security measure her, but the security team should also try to delegate ABAC to the Façade layer. Again, it’s also crucial that the API practice emphasize that data validation is everyone’s responsibility.

11. Backend Data Store

Finally, the Backend Data Store is the system of record for data. Vulnerable primarily to invalid data, it must also contend with improper access to data and a limited ability to change. Vanick believes the enforcement of authentication of backend service callers must be combined with network segmentation to block unwanted access. Also, data should be encrypted at rest and in motion.

Some principles apply to all layers

When considering the particular security needs of these layers, you might benefit from keeping a few general security maxims in mind. We recommend you try to avoid re-inventing the wheel, don’t be insecure just because your clients are, don’t use old measures when newer solutions exist, don’t fly blind without monitoring, and don’t trust anyone. If you want to learn more about how best to secure your entire API stack, let Vanick know.