How we wrote a secure app without writing security code

You can’t half-ass security

Build half a product, not a half-ass product — 37signals — Getting Real

With an app that deals with any kind of user data, not securing the data is a half-assed way of building the product.

Dumpstr is about saving your thoughts, and that’s about the only thing it does. We knew we had to secure these in a way that’s uncompromising.

Doing security right takes a lot of work

Building a web app is enough work without dealing with security.

OAuth, tokens, cookies, storing passwords, sign up flow, sign in flow, password reminder emails. All ample subjects to tackle. Coding, debugging, and maintaining all this is quite a chunk of dev time, especially for a bootstrapping startup (and I would argue, for any startup).

Keep Calm and Use an API

So we messed around with a few open source password management and security frameworks, and we ended up going for Stormpath for it’s stability, free plan, and the ease of implementation.

All the sign up / login flows, user and password storing is neatly abstracted away. They call this “Identity As A Service” (IAAS).

This is not to say that you can just write code without security in mind. But the heavy lifting (and all those hours developing and maintaining it) is done by Stormpath.

Basically, on each server endpoint we want to secure, we add a nice little “stormpath.loginRequired”. Boom, secured.

IAAS — the good

• Stores our users and their passwords
• Handles the sign up, sign in, and forgot password flows (including password reminder emails)
• Great support for our every question
• Great up time
• No lock-in: you can get all your users’ data out whenever you want
• Free to start with — great for early stage / bootstrapped products

IAAS— the bad

• If Stormpath is down, your app is down (this actually only happened once for a few minutes in months of using, but still a scary concept.)