Understanding what it takes to secure your API

Several crucial decisions need to be made around security. Securing an API is an often neglected task, yet doing so is at the heart of an effective API strategy.

An API is not secure if it is private or has no documentation. This is often referred to as "security by obscurity" and can lead to a culture that regularly neglects security because internal teams don't consider how people external to the organization could have knowledge of theoretically private APIs. Just because an API is undocumented or unavailable externally doesn't mean that it won't be accessed.

A recent study by Ovum and Distil Networks found that a third of all APIs are designed and implemented without any input from an enterprise's security team.

Isabelle Mauny is CTO and cofounder of 42Crunch , an end-to-end API security platform, urges API teams to consider security throughout all decision-making processes. For example, when forming an API team (Part Two: How To Get the Team and Support in Place for Your API Strategy) at the start of a project, Mauny says that "while it will vary from company to company depending on the size and maturity of their security team, we would advocate that security is a common responsibility. As the API is being developed, everyone must have the tools to decide on how security issues will be managed when the API is deployed." In other words, all API stakeholders in the organization should be sensitized to API security issues.

Mauny says that before DevOps became a common way for development teams to operate, teams would often rush through API design with a focus predominately on business concerns. "Than at the last minute, it would be reviewed by the security team, and that rarely works well," Mauny warned.

Mauny says one good place to start is when deciding what functionalities and datasets to open up via API. One very useful step is creating a detailed data schema noting who should have permission to access each functionality and data item, and to define exact constraints for each data field. For example, to avoid security risks like SQL injections, Mauny says that as the API is designed, clarifying exactly which data can go in and out is indeed possible. "If you have a field that should only take a credit card, it should only take 16 numbers. If you specify that qualification in your data model, then it makes it very difficult to inject anything else that doesn't correspond to 16 digits," explained Mauny. "So if you specify what each data field is, we could stop a lot of attacks. We are advocating for its inclusion in the API definition." The specification can do the work for you and prevent anything that doesn't conform to it. The tighter your specification, the fewer attacks can get through, she says.

An example of what Mauny is referring to is how the different API specifications, such as OpenAPI Specification (OAS) and RESTful API Modeling Language (RAML), can include references to JSON Schema-based validation logic in which everything from data types (string, boolean, etc.) to field lengths to format (URI) to acceptable values ("hot" or "cold") can be used to constrain input in ways that help secure the API.

Mauny says there are four main areas of decisions to make around API security: infrastructure, accessibility, availability, and testing.

Mauny says that when first developing an API, the team needs to understand what the security constraints are going to be. When mapping the current infrastructure and architecture context for the API (Part Six: How to Choose Architectural Styles and Specification Formats For Your APIs), the team needs to ask:

• Where will this API be hosted? Is it on a public cloud or an internal system?
• If this is an API being exposed externally, do I need high-level security for manipulating keys?

Mauny says infrastructure decisions for the API will depend on the sensitivity of what is being exposed. “For a weather API, for example, there is a low security requirement in terms of data. It is open to everyone and it is not going to expose any critical data, whereas for something like an API that handles transactional data with partners, then that will require more stringent security protocols,” says Mauny.

Mauny says that overall security decisions come down to evaluating the risk that comes with the API, so conducting an API risk assessment — which is at the core of what her company 42Crunch does — helps everyone work together and to share risk management across a variety of roles.

By doing a risk assessment, it is then possible to establish pre-defined security policies to manage those identified risks.

When developers are deciding which data and functionality to expose via API, they need to create a data model and share those decisions with those given access at each level of capability or data. Mauny says OAuth scopes (which define permission roles and what each role can access; for example, a "user" role may provide scope for read-only permissions) often do not give the granularity needed to make the best decisions around authentication and authorization permissions. For example, where role- or identity-based access control dictates what resources should and should not be available to the end user, an application, or both through a given API, developers may need to incorporate other technologies like OpenID or Security Assertion Markup Language (SAML) into an API's workflow so as to make the property security assertions.

Mauny explained, "You need to answer questions about the sensitivity of what you are exposing:

• How sensitive is the operation being done; for example, is it updating data?
• Do I have any compliance requirements with this data or transaction? (Will I need to prove this transaction for compliance requirements later?)
• Is auditing required?
• Are there any business logic risks or domain-specific requirements, such as healthcare data, meeting the General Data Protection Regulation requirements in Europe, or a business' contract-specific requirements, such as when content streaming has different agreements in different countries?"

The overall idea of asking these questions, says Mauny, is to give the team members a clear understanding of the data manipulations they may make, to start making decisions around how to treat this decision, and who should have the rights to access.

In addition to permissions and access policies, security risks are introduced simply from the availability of an API. These can take the form of things like denial of service (DoS) attacks whereby an API is bombarded with frequent calls.

Mauny says this requires decisions around putting rate limits on the number of calls the API can receive to no more than 100 calls per minute, for example. This is more like a technical quota and will vary depending on the size of the developer community using the API (and may not necessarily offset a DoS attack), but it does add a layer of protection against possible threats. For example, when hackers penetrated Apple's Find My iPhone API, they allegedly took advantage of the API's lack of any rate limiting.

The Open Web Application Security Project (OWASP) has added unprotected APIs to the organization's annual top 10 list of security threats for the first time. "Every new application has APIs as the backend, so that becomes an entry point to the enterprise," Mauny warned. "We still have SQL injections, request forgery... you have to validate the data that goes through your API."

The final set of decisions developers need to make around security is how best to ensure that regular security testing is carried out, Mauny says.

"Don't leave security to the last minute. In the same way you do functional testing, apply that to security. This is DevSecOps [which is a combination of SecOps and DevOps], and it is a great way to make sure that as you develop your API, you are testing its security along the way," she says.

ProgrammableWeb's editor in chief, David Berlind, is an industry thought leader on issues relating to API security. Based on his testimony in January 2016 to the Office of the National Coordinator for Health Information Technology's API Security and Privacy Task Force, he created the API University series, Understanding the Realities of API Security.

The series covers decisions that developers need to make regarding API security, including:

• API attack risk vectors
• Decisions that developers need to make when publishing public APIs
• Whether companies should make API documentation available to third-party developers when an API is internal or partner based
• Managing authorization and accessibility to APIs
• Certifying external developers for security and privacy standards
• Recognizing security issues in API terms of service
• Assessing and mitigating API security risks and vulnerabilities
• Managing API security as an ongoing part of API product management

Read the API University series, Understanding the Realities of API Security, now to make the right decisions around how to secure your API.

In our next chapter, we look at how to document your API.