API Security

Best Practices for Building Secure APIs

API designers and developers generally understand the importance of adhering to design principles while implementing an interface. No one wants to design or implement a bad API!

Even so, it’s sometimes tempting to look for shortcuts to reach those aggressive sprint timelines, get to the finish line, and deploy an API. These shortcuts may pose a serious risk — unsecured APIs.

Developers should remember to wear the hat of an API hacker before deploying. If a developer neglects to identify the vulnerabilities in an API, the API could become an open gateway for malicious activity.

Identifying and solving API vulnerabilities

An API can work for or against its provider depending on how well the provider has understood and implemented its API users’ requirements. If a company builds an incredibly secure API, it might end up very hard to use. A fine balance needs to be struck between the purpose of an API and ease of consumption. In this post, we’ll explore some of the API vulnerabilities we’ve come across through our work as part of Google’s Apigee team, including how these vulnerabilities might have been prevented.

Injections

APIs are the gateways for enterprises to digitally connect with the world. Unfortunately, there are malicious users who aim to gain access to enterprises’ backend systems by injecting unintended commands or expressions to drop, delete, update, and even create arbitrary data available to APIs.

In October 2014, for example, Drupal announced a SQL injection vulnerability that granted attackers access to databases, code, and file directories. The attack was so severe that attackers may have copied all data out of clients’ sites. There are many types of injection threats, but the most common are SQL Injection, RegEx Injection, and XML Injection. More than once, we have seen APIs go live without threat protection — it’s not uncommon.

APIs without authentication

An API built without protection from malicious threats through authentication represents an API design failure that can threaten an organization’s databases. Ignoring proper authentication — even if transport layer encryption (TLS) is used — can cause problems. With a valid mobile number in an API request, for instance, any person could get personal email addresses and device identification data. Industry-standard strong authentication and authorization mechanisms like OAuth/OpenID Connect, in conjunction with TLS, are therefore critical.

Sensitive data in the open

Normally, operations teams and other internal teams have access to trace tools for debugging issues, which may provide a clear view of API payload information. Ideally, PCI cardholder data (CHD) and Personal Health data (PHI) is encrypted from the point where data is captured all the way to where data is consumed, though this is not always the case.

With growing concerns about API security , encryption of sensitive and confidential data needs to be a top priority. For example, in June 2016, an http proxy vulnerability was disclosed that provided multiple ways for attackers to proxy the outgoing request to a server of choice, capture sensitive information from the request, and gain intelligence about internal data. Beyond using TLS, it’s important for API traffic to be protected by encrypting sensitive data, implementing data masking for trace/logging, and using tokenization for card information.

Replay attacks

A major potential concern for enterprise architects is the so-called “transaction replay.” APIs that are open to the public face the challenge of figuring out whether to trust incoming requests. In many cases, even if an untrusted request is made and denied, the API may politely allow the — potentially malicious — user to try and try again.

Attackers leverage this misplaced trust by attempting to playback or replay a legitimate user request (in some cases using brute force techniques) until they are successful. In 2016, hackers got into Github accounts via a playback attack by reusing email addresses and passwords from other online services that had been compromised and trying them on Github accounts.

Countermeasures include rate-limiting policies to throttle requests, the use of sophisticated tools like Apigee Sense to analyze API request traffic, and identification of patterns that represent unwanted bot requests. Additional security measures to stymie replay attacks include:

  • HMAC, which incorporates timestamps to limit the validity of the transaction to a defined time period
  • two-factor authentication
  • enabling a short-lived access token by using OAuth

Unexpected surges in API usage

It’s always tricky to estimate the usage of an API. A good example is the app that briefly brought down the National Weather Service API. This particular API didn’t have any kind of traffic surge prevention or throttling mechanism, so the unexpected surge in traffic directly hit the backend.

A good practice is to enforce an arrest in spike traffic or a per-app usage quota, so that the backend won’t be impacted. This can be easily rolled out with the help of a sophisticated API management platform with policies like quota and spike arrest.

Keys in URI

For some use cases, implementing API keys for authentication and authorization is good enough. However, sending the key as part of the Uniform Resource Identifier (URI) can lead to the key being compromised. As explained in IETF RFC 6819, because URI details can appear in browser or system logs, another user might be able to view the URIs from the browser history, which makes API keys, passwords, and sensitive date in API URIs easily accessible.

It’s safer to send API keys is in the message authorization header, which is not logged by network elements. As a rule of thumb, the use of the HTTP POST method with payload carrying sensitive information is recommended.

Stack trace

Many API developers become comfortable using 200 for all success requests, 404 for all failures, 500 for some internal server errors, and, in some extreme cases, 200 with a failure message in the body, on top of a detailed stack trace. A stack trace can potentially become an information leak to a malicious user when it reveals underlying design or architecture implementations in the form of package names, class names, framework names, versions, server names, and SQL queries.

Attackers can exploit this information by submitting crafted URL requests, as explained in this Cisco example. It’s a good practice to return a “balanced” error object, with the right HTTP status code, with minimum required error message(s) and “no stack trace” during error conditions. This will improve error handling and protect API implementation details from an attacker. The API gateway can be used to transform backend error messages into standardized messages so that all error messages look similar; this also eliminates exposing the backend code structure.

Keep APIs safe

As we have reviewed in this article, many potential threats can be avoided by putting some thought into API design and establishing governance policies that can be applied across the enterprise. It is important to guard APIs against malicious message content by accessing and masking sensitive encrypted data at runtime and protecting backend services against direct access. An API security mistake can have significant consequences — but with the right forethought and management, businesses can make themselves much safer.

This post originally appeared in Medium.

GDPR: Are You Ready?

On May 25, 2018, one of the most  significant pieces of European data protection legislation to be introduced in 20 years will come into force. The EU General Data Protection Regulation (GDPR) replaces the 1995 EU Data Protection Directive. The GDPR aims to strengthen individuals’ rights regarding their personal data and seeks to unify data protection laws across Europe, regardless of where that data is processed.

Apigee, which is part of Google Cloud, is committed to GDPR compliance across our API management services. We are also committed to helping our customers with their GDPR compliance journey by providing them with the privacy and security protections we have built into our services over the years.

Apigee Edge customers will typically act as the data controller for any personal data they provide in connection with their use of Apigee Edge. The data controller determines the purposes and means of processing personal data, while the data processor processes data on behalf of the data controller.

Our terms of service articulate our commitments to customers, and we are updating them to address GDPR changes and making those updates available to customers in the coming weeks.  

If you’re a data controller, you can familiarize yourself with and find guidance related to your responsibilities under the GDPR by regularly checking the website of your national or lead data protection authority (as applicable). You should also seek independent legal advice relating to your status and obligations under the GDPR. Bear in mind that nothing in this article is intended to provide you with, or should be used as a substitute for, legal advice.

 

Apigee Up Close: Protecting APIs with OWASP Best Practices

Webcast replay

Apigee Up Close is a webcast series featuring the Apigee Edge platform and live demos on select topics that users have been asking about.

Do you know how to protect your APIs from malformed client payloads? Do you have a solid grasp of how your application layer is exposing the underlying database?

In this webcast replay, you’ll learn how Apigee Edge can be configured to protect your APIs and backend resources from common OWASP security vulnerabilities and other threats.

We’ll look at an example that uses injection flaw and input validation protections to mitigate the risk of a malicious attacker compromising your API and backend resources.

When we’re done, you'll have a clearer picture of how to:

  • Create an API that protects against injection flaws and input validation from malicious clients
  • Keep it as simple as possible to make adoption easy
  • Report on usage

Register now for the next webcast in this series. It will help you build an API using composite resources.

Autodesk: Enabling New Revenue with the Apigee Platform

New case study

Autodesk makes software for people who build things. Founded in 1982, the company has been synonymous with industry-leading 3D design software for desktops, and it has used APIs for decades. But as the world moved to mobile devices and cloud, the need to transform from desktop technology to cloud offerings took center stage.

That’s why Autodesk has committed itself to digital reinvention, not only moving its award-winning software to the cloud but also investing in APIs to enable new, data-driven revenue streams.

Creating an ecosystem became a key part of achieving this goal.

“We are trying to drive a movement to the cloud in the industries we serve,” said Shawn Gilmour, Autodesk’s director of PaaS strategy. “To really be successful, we need to build an ecosystem. We really need partners and data sharing and integrations to do this—and that’s where APIs come in.”

Internally, leveraging modern APIs and the Apigee API platform enabled Autodesk to empower its development teams to easily and securely leverage the company's long-term software applications and resources for new applications and create customized and connected workflows. But it also opened doors to untapped markets, beyond Autodesk's bread-and-butter customer base of professional designers.

Read this new case study to learn how the Apigee platform helped Autodesk attract new customers and provided new levels of flexibility and scalability to the company's development efforts.

How Moving Apigee Sense to GCP Reduced Our “Data Litter”

In the year-plus since Apigee joined the Google Cloud family, we’ve had the opportunity to deploy several of our services to Google Cloud Platform (GCP). Most recently, we completely moved Apigee Sense to GCP to use its advanced machine learning capabilities. Along the way, we also experienced some important performance improvements as judged by a drop in what we call “data litter.”

In this post, we explain what data litter is, and our perspective on how various GCP services keep it at bay. Through this account, you may come to recognize your own application, and come to see data litter as an important metric to consider.

First, let’s take a look at Apigee Sense and its application characteristics. At its core, Apigee Sense protects APIs running on Apigee Edge from attacks and unwanted exploitation. Those attacks are usually performed by automated processes, or "bots," which run without the permission of the API owner. Sense is built around a four-element "CAVA" cycle: collect, analyze, visualize and act. It enhances human vigilance with statistical machine learning algorithms.

We collect a lot of traffic data as a by-product of billions of API calls that pass through Apigee Edge daily. The output end of each of the four elements in the CAVA cycle is stored in a database system. Therefore, the costs, performance and scalability of data management and data analysis toolchains are of great interest to us.

Read the whole story on the Google Cloud Platform blog

Apigee’s Top API Editorials of 2017

2017 was a big year for APIs.

They continued to solidify their position as the mechanism through which value is exchanged in modern economies, with literally quadrillions of API calls connecting apps, data, and systems throughout the world each day.

Apigee experts published dozens of editorials last year, both externally and via our Medium publication, to help developers, IT architects, and business leaders understand how to maximize the value of APIs and keep pace with constant technological change.

Here are some of our top articles from 2017, organized by some of the year’s biggest themes. Thank you to all of our readers, and stay tuned for more in 2018!

API management best practices

The nitty gritty details of API management can be challenging, but Apigee experts are here to help with their observations from the field. Be sure to check out “KPIs for APIs and Digital Programs: A Comprehensive Guide” by Michael Leppitsch and “Building an Outside-In Approach to APIs” by Chris Von See.

APIs and digital transformation

Virtually all companies understand the digital transformation imperative: if you don’t continually use technology to evolve your business, you’ll go out of business.

John Rethans explains why APIs are central to this imperative in his Forbes article, “APIs: Leverage for Digital Transformation.” And to explore why the technologies that businesses have been using for years are simply no longer good enough, read Brian Pagano’s “Legacy IT: Like a Horse on the Autobahn.”

To maximize the leverage John discusses in Forbes, APIs must be managed as products that empower developers—not as middleware. For details, see my article “How APIs Become API Products,” which includes real-world examples from Apigee customers Pitney Bowes, Walgreens, and AccuWeather.  

To appreciate the full scope of an API-first business evolution, check out “Lessons from Magazine Luiza’s Digital Transformation,” in which John interviews the CTO of one of South America’s hottest companies. And to understand where multicloud strategies fit into the mix, read David Feuer’s “Multicloud: Taming the Rookery.”

Caught up on how APIs are used today? For a glimpse into the future of digital transformation and the role APIs will play as new technologies emerge, don’t miss our article in Business Insider,How APIs are Key to Successful Digital Transformation.”

Security

New software vulnerabilities and attacker techniques emerge on a daily basis, so security remained a leading concern for enterprises in 2017. David Andrzejek wrote two of our top articles on the topic. “Using Behavior Analysis to Solve API Security Problems” in Help Net Security examines how user behavior can be monitored in near-real time to identify suspicious behavior and block malicious actors, and “Grinch Bots are out to Spoil the Holidays” in VentureBeat explains how businesses can stop a trend that plagued many online shoppers last year: attackers who use bots to buy up the most in-demand, supply-constrained items.

Digital ecosystems

To adapt to shifts in customer behavior and the competitive landscape, a business doesn’t need to become a platform company, invent new machine learning technologies, or build loads of new software in-house. Instead, it should leverage what others have built to complement its own capabilities, reach new user groups, and explore adjacent markets.

Anant Jhingran and I discuss these ideas in our CIO.com articles “APIs, Ecosystems, and the Democratization of Machine Intelligence” and “Do You Really Want to be a Platform?” For a deep look at these ecosystem dynamics, including a set of simulations, check out Anant and Prashanth Subrahmanyam’s CIO.com article, “3 Golden Rules for Winning in Software-Driven Ecosystems.”

Industry trends

APIs are playing into business strategies in virtually all industries, but there are still scores of specific trends, use cases, and regulatory requirements from one vertical to the next. Some of our top industry-specific stories from 2017 included David Andrzejek’s “Why Haven’t More Banks Embraced Digital Platforms?” in The Financial Brand and Aashima Gupta’s “Voice Interfaces Will Revolutionize Patient Care” in VentureBeat.

Image: Flickr Creative Commons/Jlm Ronan

Apigee Sense: API Protection with Intelligent Behavior Detection

New explainer video

APIs are everywhere. With their pervasiveness comes a whole new set of security threats. They can come in the form of automated software programs that commit brute force attacks, information scraping, and account abuse. They can probe for API security weaknesses and skew analytics.

What’s worse, these threats can be difficult to detect because they blend in with normal API traffic.

That’s where Apigee Sense comes in. Apigee Sense detects, collects, analyzes, and mitigates API attacks, and is purpose-built to protect APIs.

Learn more in this two-minute video.


And visit the Apigee Sense page for details.

How Secure Are Your APIs?

Webcast replay

APIs have revolutionized how companies build new marketing channels, access new customers, and create ecosystems. Enabling all this requires the exposure of APIs to a broad range of partners and developers—and potential threats.

Watch this webcast replay to learn more about the latest API security issues. We discuss:

  • The API threat landscape
  • API security best practices
  • How Apigee is helping customers protect their APIs

 

 

API Security: It's More than Web Security

Since the advent of smartphones over a decade ago, enterprises and internet companies have focused on building apps to reach customers and to provide a richer, interactive experience.   This shift to apps has also impacted threats to the enterprise with bots and malicious actors shifting from attacking web sites to attacking public APIs.

When Apigee’s customers expose critical business functions through APIs, they tempt a variety of bad actors, who try to break in by probing login interfaces or scraping data from catalogs, among other methods.      

These threats also exist in web interfaces, of course. But the move toward apps has changed the basic interaction metaphor between the client and server. Apps can store more data and preserve more state between sessions. This, in turn, has changed security paradigms, and new approaches to securing the application using features like an API key have emerged.    

More than a firewall

A new security approach based on the application layer is required; one that understands the structure of APIs, rather than security at the networking layer based mostly on traffic volume.

But API security shouldn’t be considered merely an extension of web security. A common method of providing web security is a WAF (web application firewall), which enables one to set rules based on IP addresses and traffic volume, among other things. The intention is to block individual IP addresses from attacking the system.   

These rules can be effective in warding off simple attacks, but applying these same techniques to the API layer doesn’t take advantage of the richer data available for analysis and action in the application layer.

More than IP addresses

API traffic analysis can go beyond IP addresses; API keys and access tokens can be scrutinized. If the analysis determines that a combination of the IP address and API proxy is under attack, the action taken (blocking or tagging of the IP) can also be fine-tuned to the appropriate scope.    

In other words, API security enables a finer degree of control to block specific bad actors within the appropriate context rather than blocking all traffic from an IP address. The API security layer should be part of a multi-layered approach to protecting back ends against malicious behavior.

Because of its placement in the data stream, an API platform presents an opportunity to monitor for and detect anomalies in API traffic. But the possibilities go beyond detection—and they have to, in order to protect an organization’s backend.

 

Built on the Apigee Edge API platform, Apigee Sense is a full-cycle API security solution that was purpose-built for APIs. It detects bad behavior patterns at the API level, and blocks bad actors from access based on administrator specifications. Identifying behavior patterns enables a finer grain of control for blocking, so the system doesn’t have to block all users from a particular geography or service provider, which could potentially block normal behavior.

Joy Thomas is a data scientist on Google Cloud’s Apigee team. He is coauthor of “Elements of Information Theory.”

 

How To Submit Security Tokens to an API Provider, Pt. 2

Robert Broeckelmann is a principal consultant at Levvel. He focuses on API management, integration, and identity–especially where these three intersect. He’s worked with clients across the financial, healthcare, and retail fields. Lately, he’s been working with Apigee Edge, WebSphere DataPower, and 3Scale by Red Hat.

In a previous post, I discussed a variety of considerations regarding how bearer tokens should be passed from an API consumer to an API provider. I explored two approaches to client-side bearer token storage: cookies and HTML5 local storage. Here, I’ll look at the implications that these two approaches pose for native mobile apps, traditional web apps, and single page applications (SPAs).

Of course, there are plenty of things that don’t fall perfectly into one of these categories (for a more detailed analysis of the evolution of web applications, see this), but mobile, web, and SPAs comprise a large proportion of the use cases.

Most concerns come down to XSS vulnerabilities and cross-site request forgery (CSRF) attacks. Of course, if the device or server-side components have been compromised in some way, then this entire discussion is moot.

SPAs

If HTML5 local storage is used, then the token is passed in the authorization header. Unlike with cookies, information stored in local storage is not automatically transmitted to the server (this does place an additional burden on the developer, but can be mitigated with supporting libraries).

Attack vectors include:

  • XSS: If an attacker successfully gets valid JavaScript inserted into input to your API, then later, when it is retrieved, it could be interpreted and executed by the browser’s JavaScript engine, which in turn could access the bearer token from local storage (because the script was technically loaded from your site and API endpoint). The standard defense against XSS attacks should be sufficient in this situation. Escape all HTML characters that are used to delimit JavaScript in HTML (&, <, >, “, ’,/) with HTML entity encoding (&amp;, &lt;, &gt;, &quot;, &#x27;, &#x2F;) referenced in input and other steps recommended by OWASP (see OWASP recommendations). Not all of these are relevant for API endpoints; for example, APIs typically don’t generate HTML. There is gn support for most of these recommendations built into modern web frameworks.
  • CSRF: Conventional wisdom suggests that this is not an issue because the attacking code would not have access to the JWT in the HTML5 local storage for the API endpoint. I’m not going to debate this or dissect the notion here, but let’s assume that all interaction between the SPA and its backend API use standard anti-CSRF patterns as described by OWASP. They describe two steps that should be taken: verify the same origin with standard headers (or a known origin), and require some type of randomly generated value be presented with each request that wouldn’t be known to the CSRF instigator. In a stateless REST API, both of these can be challenging. But many of the major frameworks provide support for implementing this functionality.
  • JavaScript from site A accessing data stored in local storage for site B: Not possible based on the security model implemented in browsers. This includes access by code on sub-domains.

If HTTP cookies are used for storage and transportation, then the attack vectors of concern are:

  • XSS: The token value stored in a cookie cannot be accessed by JavaScript injected as bad input and later interpreted in the browser. Nevertheless, use the same mitigation patterns described above.
  • CSRF: This is possible. Any request that is made (regardless of what’s triggering it) to the API from a browser session will include all cookies that are defined for the API endpoint. In this case, the mitigation strategies described above are absolutely imperative.
  • JavaScript code from site A accessing cookies from site B: By default, not possible, but CORS can override this.

Mobile apps

A native mobile application doesn’t run in a browser. It likely uses a library that either acts as a user agent to interact with the identity provider or launches the system browser to handle the IdP login workflow interaction. The library used to handle IdP interactions and login shouldn’t be a general purpose JavaScript engine (although it is likely launching the system browser that is). The login workflow that the browser interacts with should be a self-contained entity that isn’t relying upon external JavaScript sources.

Likewise, a native mobile app isn’t going to have local session storage. The use of cookies is limited to the HTTP client library or framework used to make API calls. The best option for securely storing a bearer token on each mobile platform is beyond the scope of this article.

Let’s assume that the API the mobile application is interacting with is the same one that is utilized by a SPA application and other API consumer actors. Attack vectors include:

  • XSS: If the native mobile app is using a component that has a JavaScript interpreter, then this is possible. In this case, the mitigation strategies described in the previous section should be utilized.
  • CSRF: This is only possible if a library is being use that includes cookies automatically. So, it depends. However, as always, the mitigation strategies described in the previous section should be used.

Traditional web applications

For our purposes, the difference between the SPA above and the traditional web application hinges on whether the server returns full HTML pages or JSON objects (or maybe XML). For the most part, the information provided in the SPA section applies here with the following exceptions.

If HTTP cookies are used for storage and transportation, then the attack vectors of concern are:

  • XSS: Same patterns described above should be used.
  • CSRF: Synchronizer (CSRF) token patterns can be used with the stateful security model.
  • JavaScript code from site A accessing cookies from site B: Comments in the previous section apply here.

So which approach should be used?

As I’ve mentioned in other posts, I always fall back on a standards-based approach to security. This implies that per RFC 6750, the bearer token should be placed in the HTTP request authorization header for each API call and the token stored in HTML5 local or session storage (for brower-based applications). For many IdPs, libraries will be provided that abstract these details away.

Is this the only way of accomplishing the desired effect? Obviously, no. But in my attempts to implement standards-based security solutions, it‘s the approach I recommend. Appropriate defense strategies for XSS and CSRF must be used, and, thankfully, can be largely accomplished with functionality in popular frameworks.