API Security is complex. Vendors like Forum Systems, IBM, CA and Axway have invested almost two decades of engineering effort and significant capital in building API Security stacks to lockdown APIs. The API Security stack diagram shown below is a building block for rapidly locking down APIs. The four fundamental pillars of API Security - SSL, Identity, Content Validation and deployment architecture - are discussed in detail below.

Here are four fundamental steps that an enterprise can take to ensure that their APIs attack surface area is significantly reduced. To implement API Security:

1. Enable SSL: One can rapidly protect API traffic by enabling SSL and changing http to https. This is a good first step in protecting the 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. Enable 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: API are facades to complex and typically proprietary business logic and data. Egress and ingress data has to be strongly coupled with who has invoked the API. Authentication should be followed by Authorization and deep Content-based Access Control (CBAC). For more details on understanding CBAC, see for example: 
     • Content-based Access Control -- Three Areas of Consideration
3. Check 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 validated the data traversing API calls. Further integrity checks can be enforced by using signature mechanisms such as XML Signatures and JWT. Response data should inspected to ensure that there is no data leak and that the API requestors receive only that data that they are entitle 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. API 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 is implemented using a variety of software platforms, separating 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.