2020 predictions on securing APIs

Ahead in 2020: Preparing for new mechanisms that will help secure APIs

Ryan Breen
© Shutterstock / BAIVECTOR

If you’re like me, you’ve spent the last several weeks reviewing the vast number of predictions industry players have been making in and around the software development space. One that I don’t think has received enough coverage is the exciting prospect that browser vendors will eventually start adding mechanisms to secure localStorage, a JavaScript accessible storage technology commonly, but dangerously, used to store critical data such as authentication tokens. While it’s unlikely we’ll see browsers implement any improvements in 2020, the sad reality is that we’re likely to see attacks that necessitate a response.

Let me back up a bit. Today, the most common mechanism for securing APIs is OAuth2 with Bearer tokens in the form of JWTs. When calling APIs from interactive sessions in a user’s browser, the path of least resistance is to log the user in, stuff their JWT in the browser’s localStorage, and go about your business calling APIs with that JWT. There’s just one problem: security experts say not to do that. That’s because anyone running JavaScript on a page can read any value out of localStorage, so if you treat it as a store for passwords (which, ultimately, a JWT is), you’re opening your customers up to trivially exploitable cross-site scripting attacks. A better approach is to use HTTP cookies to convey this authentication information as 20 years of incremental security enhancements from the browser community have gradually buttressed cookies from cross-site scripting and cross-site request forgery attacks.

SEE ALSO: Serverless and DevOps in 2020 – “Going serverless is a great way of cutting costs”

Possible issues with handling cookies

However, the use of cookies is easier said than done. Developers building microservices routinely fail to incorporate the handling of cookies: those are legacy, browser-related implementation details that we oftentimes assume have nothing to do with the API ecosystem. We prefer to start off building an API with a clean AWS API Gateway Custom Authorizer to validate a Bearer token. We get our API all polished up in production for machine-to-machine calls, and that’s in production for a few months creating shareholder value before someone decides they want to call an API from a browser. Then, someone stumbles over an article telling them not to put JWTs in a browser, and they begin to take steps to rearchitect everything to introduce cookies into the mix. This is not an easy thing to do because cookies are just a fundamentally alien technology to the OAuth flows most of us are building for, so you end up with this odd architectural special case for one particular audience of users.

Many developers at this point search for an iconoclastic article telling them it really is okay to use localStorage rather than rebuild everything to use cookies. At the same time, a whole class of developers never found the articles telling them not to put JWTs in localStorage in the first place, leaving them inherently insecure forever.

Securing localStorage is only a matter of time

So, we have a situation where many, many developers are doing a bad security thing because the right thing to do is hard and non-obvious. That’s why I believe that in the year ahead browser vendors will begin to recognize the need to roll out mitigations to help secure localStorage, adding in the moral equivalent of all the mechanisms cookies have been gifted over the last 20 years. Cookies started out with many of the same security vulnerability localStorage originally had, and only through bolt-ons like the Secure, HttpOnly, and SameSite flags have they acquired all the properties that make them a better choice than localStorage for JWTs. It’s only a matter of time before localStorage is similarly secured by adding new mechanisms to declare which scripts should be allowed to read and write which values in the store – solving major headaches for developers everywhere.

SEE ALSO: Software development trends for 2020

Ideally, this happens before a spate of attacks exploiting the common, insecure practice. But nothing galvanizes a response like a wave of unflattering media coverage, so it’s just as likely that 2020 is the year of the localStorage exploit and 2021 is the year of the response.

Ryan Breen
Ryan Breen is the Director of API Management at Cimpress, the parent company to Vistaprint and other leading mass customization businesses. Ryan has been at Cimpress for the last 5 years, helping advance the organization's shift to an internal platform built on microservices. Ryan is responsible for managing the API ecosystem as well as the documentation, training, and UX that unites the platform. Prior to Cimpress, Ryan was the Chief Architect at Everbridge, the world's leading mass notification service.

Inline Feedbacks
View all comments