Is Continuous Security Part of Tinder’s API Strategy?

[This article was written by Ben Austin.]

 Have we completely forgotten that some doors need locks…that work?

With companies like Apple, Tinder, and SnapChat releasing APIs that have significant security concerns, it makes you wonder what, if any, process do app and service providers have to make sure they’re safe from attack. Everyone’s scrambling to build, deploy, scale, and support great experiences, that it’s common practice to underplay security testing even in the most enlightened continuous delivery models.

Team Alignment Impacts Security

I work at a company where we consider APIs fundamental to all people and businesses. Dev shops, multinationals, public sector, health and finance, you name it, they use our software. Some of the most successful teams align to business strategies rather than departments, allowing them to consider the quality of their APIs and apps throughout the entire software delivery lifecycle. From code to test, deploy to monitor, everyone talks to everyone and all team members care about the final product.

So how is it that even large, well-funded organizations still miss critical vulnerabilities in their APIs?

Often and Early, More Time for Security

Moonpig’s egregious security flaw earlier this year could have been easily prevented by testing with dynamic data to validate account information was properly isolated. Tinder’s recent hack, while less about leaking personally identifiable data, is alarming in that it shows how API abstraction itself can easily go a bit too far into the impersonal, in that their API doesn’t distinguish between a bot and a real user.

Security is a Big Problem for IoT

And how does security in the Internet of Things work into the security conversation? With billions of devices connecting to each other, to services in the cloud, and to very sensitive information about us all, how can we possible afford to treat security as anything less than a first-class citizen in IoT strategy?

Whatever the endpoint, architecture, or technology, the topic of security needs to be a consideration that everyone shares rather than a post-deployment afterthought. Developers are not solely responsible for unsafe systems; architects, project management, testers and operations are all on the hook when it comes to delivering high performance services that also respect personal privacy and data security best practices.

The Solution Up To Us All

Since security is such a broad topic, it may seem like we haven’t even properly defined the “problem” to begin with, but that isn’t quite right either. We all know what that a security breach is a bad thing, and there’s always ways to plug it once it’s known.

The key is “continuous security”, keeping the topic of security in the iterative delivery process and on everyone’s mind. It doesn’t have to be complicated, maybe a weekly stand-up, but consistent and collaborative with all members of the product team. This approach encourages conversation and resolution, ultimately bringing us closer to a connected world where security is a given everywhere.