This has been a really interesting point of discussion with my API users (especially with the potential users).
Users want to make sure the API is secure, however most are actively put off by the steps required to implement the proposed security measures.
There are a number of common security practices that your API can follow, some are simple, some extremely complex, but all are there to achieve one purpose; allow access to only those users that are allowed to see the data.
The main security practices (that I’ve noticed) being;
|Security Practice||Description||Types of APIs|
|No authorization required||Users can access the API without any security at all||Open data APIs, general information provided to all e.g. Library Book API|
|Shared Key Access||Users must know some key prior to being able to access the API. This key can be shared, but is generally permitted on a per application basis||Secure open data APIs, general information provided to all, but some security required e.g. Train Line API|
|Per-User Access||Users must be provided an API key or Username and Password to access the API.||Secure private data APIs, information is normally provided on a per user basis. Service based APIs.|
Within the secured models, there are a number of different methods that you can also use to secure the API, from Base64 encoded username and passwords through to HMAC (as described in my post here).
The important thing to remember is; the more secure your API is, the more effort is required from the developer to gain access.
|Security Practice||Time to get going|
|None||Users will be up and running as soon as they can make their first request (< 1 hour)|
|Key Required / Basic Authorization||Users will be up and running once they are provided access. With a self-provisioning model this can be the same as above, but most service providers will only provide keys after approval, so this generally takes a bit longer. (1 – 2 hrs)|
|Complex Signature Generation / Certificate Authorization||Users will need to understand your signature generation methodology and custom build this into their application. Unless you’ve provided an SDK in their language, this is generally difficult and annoying for the user. (2 – 4 hrs)|
In my experience, getting users into your API as fast as possible and showing them how easy it is to use is key to retaining these users.
If there’s another API on the market that offers the same capability and is easier to use, users will naturally gravitate towards that service instead of yours.
That said, most API product managers offering a service based API will find themselves locked in a discussion with the Security Manager from a potential customer about how secure their API is.
This is often a discussion for the Security Manager to re-enforce how important they are, more than the actual security vulnerability on your API, but nevertheless it is a discussion that is needed in most sales cycles.
What you’ll need to get through this discussion is reasoning as to why you chose the security model on your API, and an understanding as to what the potential threats are. As long as you’ve mitigated the risks, the security manager will give your API a pass.
So what are the possible threats?
There are thousands of possible threats, but the main ones that I’ve worried about in my API design are:
|User Input||When someone is trying to input information into your database that doesn’t belong there (e.g. SQL injection)||Input sanitisation and validation|
|Unauthorised Access||When someone who doesn’t have access attempts to gain access to your API.||Using one of the security measures described above e.g. Basic Auth, Keys, Signatures or OAuth|
|Denial of Service (DoS)||When someone intentionally floods your API with requests to try and reduce your service capacity, or bring it down altogether.||Rate Limiting with an API Provider, or building this into Apache with mod_qos|
|Man in the Middle attack (MitM)||When someone is monitoring the requests made on a connection (e.g. wifi) and can easily re-run those requests, or modify them slightly, to perform a similar outcome.||Signatures, timestamps or other request level uniqueness will prevent this type of attack.|
And the list goes on..
The take away from this post should be that it doesn’t really matter how you choose to secure your API. As long as you think it is secure enough for the data that you are providing, and you can stand up to scrutiny (e.g. you know what the threats are, and you’re confident you’ve mitigated them, or understood the risks) then it is likely it’s secure enough.