7 tips for building an API-secure architecture

Application programming interfaces are a common tool for powering public sector engagement, but when APIs are underprotected, agencies leave themselves vulnerable to attack. The risk is so acute that the Open Web Application Security Project added Underprotected APIs to its OWASP Top 10 security risks of 2017.

Because APIs expose systems of record that typically reside within an agency’s trusted network, additional considerations must be made to avoid security risks that exposure can create. Organizations can mitigate many of the risks by using an API gateway to facilitate these requests. 

API gateways act as a specialized proxy server that controls the requested traffic, detects and defends against distributed denial-of-service attacks and leverages existing investments in malware/antivirus scanners.  Below are seven key best practices to consider when designing a secure architecture needed to implement a trusted API gateway:

1. Control requests into the agency’s trusted network. The API gateway should not permit connections directly into the ATN that originate from the network’s demilitarized zone. Instead, an internal gateway component in the ATN should connect outward to the API gateway in a tunneled fashion. This approach removes the need to open incoming firewall ports from the DMZ into the ATN, preventing any connections from servers in the DMZ should they become compromised. Additionally, connections from the ATN to the API gateway should be persistent, so that encryption handshakes are not continually re-established, which can negatively impact performance.

2. Establish filtering rules and alerts. The API gateway should be configurable to actively filter requests based on agency security and operating policies. Filters should include the ability to block specific IP address ranges and to act dynamically based on request type, endpoint name, request payload size and authentication. Automated alerts should be sent to system administrators and management dashboards when requests violate filter rules.

3. Implement protective caching. Depending on the data and use case, the API gateway should be employed to store and serve frequently accessed data directly from caches of random-access memory. This provides a high-performance buffering layer that can insulate the internal endpoint from spikes in volume. In addition to protecting the internal endpoint, this technique increases API service performance, facilitates scalability and decreases internal network traffic. For example, a weather API might only deliver updated data every five minutes, but during a hurricane the API might be inundated with concurrent requests. In this use case, protective caching could provide an extremely affordable scaling mechanism that helps the data provider avoid sizing its architecture to accommodate unpredictable spikes in utilization. 

4. Operationalize cyber threat information. The API gateway itself should provide flexible administrative APIs to allow for fast, automated and scripted configuration. With a dynamically configurable API gateway, agencies can quickly operationalize actionable threat indicators from the National Cybersecurity and Communications Integration Center. Additionally, certain rule violations or alerts triggered on an agency’s API gateway may reveal threats that should be shared with the cyber community through the Department of Homeland Security’s Automated Indicator Sharing service.

5. Manage identity and access. The API gateway should provide a robust policy action to effectively identify and validate clients, with the ability to support a wide variety of identification and authorization options. This gives agencies flexibility to identify clients who are trying to access the APIs. At a minimum, the gateway’s supported identification options should include: hostname address, API key, IP address change, SSL certificate, OAuth2 token, XPath expression, WSS username token and WSS X.509 certificate. 

6. Protect against payload threats. Another important factor is how the API gateway blocks attacks coming through JSON or XML string lengths and payloads by setting:

• Maximum number of entries allowed in an object.
• Maximum string length allowed for a property name within an object.
• Maximum number of elements allowed in an array.

It should also specify XML attributes such as:

• Maximum number of characters permitted in the namespace prefix.
• Character limit for any namespace universal resource identifiers present in the XML document.
• Maximum number of child elements allowed for any element.
• Maximum node depth allowed in the XML.

7. Deploy SQL injection filters. The API gateway should include the ability to block SQL query requests based on custom blacklisted items, such as invalid special characters. The ability to dynamically configure rules gives agencies maximum flexibility to adjust as new threats are identified.

Employing an API gateway and following these steps is a proactive way for agencies to address specific security challenges to data and applications that require open, public access. Although no security solution is ever complete, agencies must deploy the latest security techniques to reduce their risk profile. An API that fails to deliver the expected level of security, reliability and performance can have tremendous mission impacts -- to both the organization producing it and those consuming it.