DZone Research: How To Secure APIs

To gather insights on the current and future state of API management, we talked to 17 executives who are using APIs in their own organization, as well as helping clients use APIs to accelerate their digital transformation and the development of quality applications. We asked them "What kind of security techniques and tools do you find most effective for securing APIs?"

Here's what they told us:

OAuth

• Delegate to the infrastructure and rely on OAuth, delegate to the container. All secured behind OAuth. The controlled ecosystem doesn’t look the same as public facing like Twitter of Facebook. 

• Take a microservices based approach internally to isolate services and ensure it's behind a firewall with OAuth 2 for authentication. Different failures or security breaches can be identified and cut off. 
• We rely on OAuth 2, with appropriately defined scopes for security APIs. OAuth 2 is a standard based modern authentication protocol. 
• OAuth is the primary method of access control for delegated access to APIs. For instance, when you allow an app to log in using your Facebook identity, or get access to your photos on Instagram, there is a carefully controlled three-way handshake that allows you to grant permission to that app for a specific scope of access. However, OAuth and related specifications such as OpenID Connect are difficult to implement and require tools that enable developers to focus on user experience rather than writing potentially insecure code. In addition to access control, there’s a broad spectrum of threat protection capabilities that can be enforced in an API Management offering to guard against common exploits. A series of highly-public API breaches have led to significant costs in both revenue and business reputation but could have been prevented by a competent threat posture. And while standard filters can protect against known vulnerabilities, a positive security model that accepts only the data, format, and protocol defined by the API provider create a more effective barrier against as-yet-undiscovered threats. 
• Besides support for the common API security schemes such as HTTPS, OAuth or JWT, typically provided by API gateways, we think security needs to be a core part of the development culture and not simplify delegated to the operations team as an afterthought or at best a secondary thought. This is critical if you want to achieve continuous delivery in a secure way. Automated testing is a core requirement. Security is a team sport and goes all the way from data at rest to data in flight towards the consumer. Security needs to be governed and enforced all the way through, including internally to respect data privacy and be compliant with industry standards such as PSD2 and HL7.

Other

• It's an age-old question and we have not learned all of our lessons. Data is exfiltrated from organizations far too often. Not enough thought goes into the design perspective. Security as a design component is really important rather than an add-on at the end. Security by design. OWASP top ten is a great starting point as a matter of principle.
• We take a layered approach. Good coding practices and standards, automated testing and standards. Pen testing. Patch management. Regular audits through SOC2 and internal teams.
• There are seven or eight ways for open ID-based authentication. The one you choose depends on what you are trying to deliver. Start with the use of the API perspective to determine the security to put in. If humans are using, you need a password. If the machine is using, it can be certificate based. Build on what you need to do. The need to deliver the certificates will change every three months.
• Integral to API discussion on edge or multi-cloud. API security is the number one concern. Very rich gateway with Apiary and gateway with security policies as part of the platform – testing versus security policies, as part of documentation best practices around security. Identity cloud service at Oracle. Most gateways are not backed by identity tool (IDCS). Open platform with SDK where customers can add own policies.
• Use different tools for API management platforms that help scale, rate limit. A security tool should be used in conjunction with other resources. Security is a sufficiently strong challenge you need a separate initiative and software to deal with this. Use a third-party security platform to manage security. As API attacks get more sophisticated protection will always change. How do I stop most attacks and respond to advanced attacks? How quickly can you respond to new threats? Think about the response, not just upfront blocking.
• VPN or authentication access to the code. Don’t just give to anyone. Must have a right to have access.
• A lot of different levels of SOC 1 2 and 3, pen testing, employee security standards, patch vulnerabilities, features in product IP whitelisting, SSO, three layers of security – company, code, product feature.
• Critical things to do. There’s a performance dimension, ease of use, and secureness. Very secure mutual TLS hard to scale and use. API key but easy to exploit. Open AUTH OpenID Connect easy to use but secure. We recommend pen ID Connect for external and mobile.
• We are locked down at the application level we make sure we do everything in HTTPS, locking down all of the ports that could be open. That is part of our standard security protocol. We are monitoring all activity for API calls successful, unsuccessful, volume, and able to see anomalies. If we see things that look off, we’ll drill in. We’re hardening at the application layer.
• You need a security platform and be able to use the features and identify the inflection points and use the right set of security features at each inflection point. Security training is important for developers. Application security testing improves outcomes. The more tools and techniques at inflection points in SDLC you will see more secure products.
• Having a strong identity understanding of who is using and the scope of access after that. Logging to track activity. Equifax had very few use cases justifying the download of 147 million customer records.
• Most commonly, API gateways are used to manage security on behalf of the APIs they protect. With the rise in adoption of microservices and event-driven patterns, micro-gateways, particularly those that can handle event-driven patterns from the ground up, are being used to provide the last-mile security tailored to a microservice. API security typically involves a combination of several different techniques and tools e.g.: API access (authentication and authorization), API content-based validation for threat detection, API load-based protection mechanisms, for e.g., to protect against DDos attacks, integration with other internal systems that may already be in use, e.g., IAM system. API gateways commonly provide out-of-the-box ready to configure API security policies across a range of above-mentioned use-cases to protect. Apart from these pre-configured policies for API security, machine learning models and tools can also be brought to bear on API security problems to proactively identify and fend off possible API security attacks.

Here's who we talked to:

•  Maxime Prades, Vice President of Product, Algolia

• Jaime Ryan, Senior Director, Product Management & Strategy API Management, CA Technologies

• Ross Garrett, VP Marketing, Cloud Elements

• OJ Ngo, CTO, DH2i

• Reid Tatoris, Vice President Product Outreach and Marketing, Distil Networks

• Oren Novotny, Chief Architect, DevOps and Modern Software, Digital Innovation, Insight

• Raj Sabhlok, CEO, ManageEngine

• Keith Casey, API Problem Solver, Okta

• Vikas Anand, Vice President Product Development, Oracle

• Mike LaFleur, Global Director Solution Architecture, Provenir

• Steve Willmott, Senior Director and Head of API Infrastructure, Red Hat

• Keshav Vasudevan, Product Marketing Manager, SmartBear

• Chris McFadden, V.P. of Operations, SparkPost

• Jerome Louvel, VP of Product Management, Talend

• Derek Birdsong, Product Marketing Manager, Connected Intelligence Cloud, TIBCO

• Setu Kulkarni, Vice-President of Product and Corporate Strategy, WhiteHat Security

• Roman Shaposhnik, Co-founder VP Product Strategy, and Vijay Tapaskar, Co-founder VP Engineering and Ops, Zededa