Four Pillars of API Security

API Security is complex! Vendors like Forum Systems, IBM, CA and Axway have invested almost 2 decades of engineering effort and significant capital in building API Security stacks to lockdown APIs. The API Security stack diagram shown below is essential for rapidly locking down APIs. In this article, we review “The Four Pillars of API Security” — SSL, Identity, Content Validation and Architecture.

API Security Stack

Before addressing the Four Pillars of API Security, it is essential to recognize that a robust PKI is a must for enterprise-grade API Security. Without proper key life-cycle management, the API Security Pillars cannot be built.

Once a solid PKI foundation is in place, an organization can build API Security Pillars on this foundation. Without a robust PKI foundation to stand on, API security pillars will collapse. With a solid foundation and strong pillars, a corporation’s API attack surface area is significantly reduced. To deploy API Security, we recommend the following four pillars:

1. Strong SSL: One can rapidly protect API traffic by enabling SSL and changing http to https. This is a good first step in protecting traffic from an API consumer to an API producer, however, the following items should be considered in tightening secure API communication:
   • Check X.509s: Even BMW was exposed to a man-in-the-middle (MitM) attack because it failed to validate SSL certificates. Without Signer Groups, CRLs and proper cert chain validation, even SSL connections are vulnerable to MitM. See for example: Signer Groups and CRLs for API Security.
   • Be crypto selective: Be snobby in your choice of ciphers and key sizes. Bigger is indeed better. 4096 size keys should now be standard for API Security along with AES-256. See for example: SSL Policies for Securing your APIs.
   • Avoid OpenSSL stack: Do we really need to be reminded of Heartbleed, POODLE, BEAST, and other SSL vulnerabilities. If you must continue using OpenSSL, ensure that the latest security patches are installed, SSL 3.0 is disabled and the TLS 1.2 is enabled.
2. Robust Identity: Any API of commercial value will typically identify the client by, at-a-minimum, issuing a developer-id or app-id that the client has to embedded in each API invocation. The more commercial-grade an API, the more sophisticated identity tokens it will deploy. OAuth, SAML and X.509 identity tokens are typically used in most enterprise-grade APIs for identity decisions.
   • Token Integrity: Once a user is authenticated, ensure that the session/token integrity is preserved. OAuth provides a good mechanism in protection identity tokens.
   • Understand token lifecycle: OAuth and SAML provide mechanisms for token lifecycle with time-to-live (TTL) and expiry times that should be understood and managed. For details, see How to Implement Enterprise SAML and Intro to OAuth. Also see:
     • SAML or OAuth — which is Best for your Organization?
   • Authentication is not enough: APIs are facades to complex and typically proprietary business logic and data. Egress and ingress data should be strongly coupled with an API invoker’s identity. Once the invoker is authenticated, a check must be made on whether the user is authorized to invoke the API. Beyond authorization, an enterprise should perform deep Content-based Access Control (CBAC). For example, an enterprise should check whether the content leaving their boundaries is indeed permissible for the authorized API invoker. This last step is crucial in ensuring that enterprise data remain fully protected. For more details on understanding CBAC, see for example:
     • Content-based Access Control — Three Areas of Consideration
3. Valid API Content: APIs typically have a request-response structure. Input is sent in as URL parameters or in the body of the request to the API endpoint, the business process engine executes the functionality based on the inputs and responded with XML, JSON or other complex data-types.
   • Parameter Validation: Anything that goes into the URL as a name-value pair can be tampered with for Denial-of-Service or data extraction attacks. Validating the number of parameters and expected size should be the first step in preserving the integrity of URL parameters or query strings. More sophisticated URL parameter signature mechanisms are available as a part of the OAuth specifications.
   • Content Validation: The content including the header, body and attachments in an API request-response has to be evaluated and validated. This includes XML and JSON validation and checking the headers in detail and especially looking for the HTTP Method: GET, POST, PUT, DELETE. For example, API calls that check for status should be barred from using any method except GET. The published schemas for XML and JSON content can be used to validate the data traversing API calls. Further integrity checks can be enforced by using signature mechanisms such as XML Signatures and JWT. Response data should be inspected to ensure that there is no data leak and that the API requestors receive only that data that they are entitled to see.
   • Malware Scans: Looking for malware, viruses, SQL injection and ensuring that the APIs are immune to API-borne threats, such as those listed in OWASP Top 10, is an essential function for establishing API Security within an enterprise.
4. Consistent Security Architecture: Choosing the right architecture for enforcing API Security within your enterprise is an important first step. Most companies, regardless of their size, now rely on multiple API vendors for critical business needs including CRM, inventory management, financial services, HR, and order fulfillment. As business processes and logic are implemented using a variety of software platforms, API Security decisions should be clearly separated from the business code and centralized for rapid event auditing and policy management. Coding API Security logic in along with business logic can have significant security and scalability issues and can result in a brittle API Security architecture.

The four fundamental items listed above for implementing API Security within your enterprise should be considered a baseline minimum. Additional security provisions should also be addressed, but without these 4 pillars of API Security, enterprises are exposed to an ever-increasing attack surface area. Core systems, embedded deep within proprietary enterprise processes are now being brought to an enterprise’s edge through APIs. Without API Security, enterprise core functions are at risk of data theft and disruption. IT professionals, regardless of their function, should keep a close eye on building the foundations for their infrastructure on the 4 tenants of API security: SSL, Identity, Content Validation and Centralized Enforcement.