Securing JSON APIs with Wrapper Objects ift.tt/1xYlavy At VividCortex, security is a top priority. Leading companies such as Zappos, Dyn, and Etsy use our cloud-based database performance management service to monitor MySQL in production. We’ve designed for performance, isolation, and security from the start. Even small decisions can make a big difference. One of those micro-decisions is making all of our APIs return a top-level object in JSON, never a top-level array. This is to avoid an old, obscure, unlikely, but still possible JSON security vulnerability. If you have never heard of JSON security vulnerabilities, you should go read Anatomy of a subtle JSON vulnerability before continuing. Now that you’ve read that, you know a lot more than most people about JSON and security! Although modern browsers have fixed the underlying vulnerability, older browsers are still in use, and so although it’s not as convenient, we think it’s still important not to leave this potential hole open to exploit. What does this look like in practice? It simply means that APIs that return lists of objects wrap the list in a top-level object. For example, suppose you have a Person data type in your API. If you GET a single Person, you might end up with the following JSON response: { name: John Smith } All’s well so far. But what if you want a list instead of a single one? The most intuitive way might be as follows: [{name: John Smith}, {name: Jane Smith}] But that’s exactly the situation we need to avoid. As a result, all of our APIs at VividCortex use a top-level object for lists such as this, with a single data property: {data: [{name: John Smith}, {name: Jane Smith}]} Some people object to this; it seems inherently wrong to them. Our view is that security trumps elegance, and it’s not a big deal for consumers of the API to look for a nested list instead of a top-level list. Developing a large-scale service-oriented application involves making lots of decisions, many of which include tradeoffs. Here are a few resources you may find interesting: HTTP API Design Guide based on lessons learned at Heroku Microservices - not a free lunch and Microservices - the good, the bad, the it works What do you think of this convention and the underlying security concerns? Leave your suggestions and thoughts in the comments! Thumbnail Cred from Planet MySQL ift.tt/1du18ol
Posted on: Wed, 21 Jan 2015 20:18:09 +0000
Trending Topics
Recently Viewed Topics
© 2015