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.
The post Ahead in 2020: Preparing for new mechanisms that will help secure APIs appeared first on JAXenter.
Source : JAXenter
