Our Blog

Latest news and updates from BinaryOps.io

API Security and 5 ways to limit your exposure

With nearly 15,000 items published in the ProgrammableWeb API repository, it seems that the API economy is booming. That's great for users who get access to services and data integrated into everyday life, it can also catch them by surprise when things don't go as planned. Take Snapchat for example, where in 2014 an unofficial SnapChat App was compromised and leaked 'compromising' photos of users to 4chan. Or in March of 2015, when the Tinder API was re-worked to have unsuspecting men flirting with each other.

API's are used everywhere and then some, so it's no wonder that hackers are having fun and abusing them in ways that were never intended. Developing an API strategy is more important than ever before and being aware of what information is exposed and who can access it should be given proper attention. A properly designed API allows companies to innovate faster and give customers value where a closed system simply cannot.

Websites such as Salesforce and Expedia generate huge portions of their revenues, 50 and 90 percent respectively, by publishing API services. Even US President Obama is on the bandwagon with his Open Data Executive Order that requires government agencies to publish data in publicly documented APIs.

API's by their very nature are open to the Internet where they can be explored and poked at by anyone with a computer. API security must be at the top of the list when connecting to potentially sensitive and user-identifying data. API's don't have a visual interface so when they get hacked, it's not for shock value or to simply take down a website, it's worse than that because it's so easy to go unnoticed. Greeting card provider Moonpig exposed details about 3 million customers before they were alerted to the problem and shut down their mobile apps to investigate.

How do these security holes go unnoticed?

Often developers are subject to fluid requirements and short timelines so time is spent on parts of the app that consumers see, not so much below the waterline. There's often too little consideration to the impact of providing certain pieces of data, how it might be used or how it could be mis-handled. Other times there’s confusion among developers between something as simple as authentication vs authorization. A user may be authenticated by the system, but not authorized to fetch or modify certain data as was the case with Moonpig.

How can we limit our exposure?

1) API's need to enforce SSL

There's no excuse to server API data over http anymore. Certificates aren't that expensive and picking off data sent to an unsecured API is too easy. If your API is running on the same host as your website, you can re-use the same certificate. If it's not, then consider a multi-domain or a wildcard certificate.

2) Credentials need to be protected

Credentials should never get stored unencrypted, whether that's passwords in the database or client-side baked inside an application. There's too much at risk if the app cache is compromised or user data gets logged in a file somewhere.

3) Authenticated and Authorized

Every request should be both authenticated and authorized. It's not enough to know that the request comes from a valid system user, developers need to ensure the each request only has access to data that's appropriate for that individual. Authentication needs to be temporary, as is the case with access tokens, which expire or can be revoked. Validating against a hashed username and password means that the hashed value could remain the same indefinitely.

4) Limit exposed data and actions

It's too easy for a developer to simply lo shuffle out the same object that was stored in the database as an API response but too often that means sensitive data gets shipped out when it should not. Mapping only the necessary properties is a much safer solution as new object properties must be explicitly coded into the response.

5) Validate input

When users submit data it’s not good enough to simply take the complete request and shove it into the database. Expected values should be validated and unexpected ones should either produce an error, or simply get ignored.

Following these five recommendations will help keep your data safe, and reduce the chances that your API gets fingered in another data breach article at theregister.co.uk.

Tags :  security  api