API Security Best Practices

Building APIs is an essential way to enable API integrations between your system and other applications around the web.  They are the building blocks that enable your service to be consumed by composable, data-mixing services, Phone apps, IoT, and more. 

There are thousands of useful APIs out there. They can be used to pull data, manipulate it, store it, combine, and refine information to enhance user experience and turn plain Data into Information. However, when designing and implementing APIs, there are some common pitfalls. These pitfalls should be avoided to stop data from falling into the wrong hands.

Pitfall One – Broken Object Level Authorisation

Consider this API endpoint example:

GET /hr/employee/{id}/salary/
Authorization: Bearer Token

Using this API with a staff member ID (e.g. 1234) retrieves a salary object with pay grade, tax information and so on for the corporate iPhone App.  Improper permission checking and authentication on this endpoint would allow an employee to submit a request with any ID and see their colleague’s salary information. This is because the endpoint has Broken Object Level Authorisation.

How to avoid:

• Always check that the requesting principal has access to the object being requested – look at that bearer token! Does it have permissions to this employee’s data?
• It would be better to use random UUIDs for keys than an easily guessable Int for the employee ID – perhaps inject a new ID for external API use into the object store so you are not exposing internal simple integer IDs?
• As always, write tests to test scope issues and act if one fails!

Pitfall Two – Broken Authentication

Authentication needs to be protected like any other asset your API deals with.  Imagine this example endpoint:

PUT /account
Authorization: Bearer Token


{"email": "<some new value>"}

This will be vulnerable to token stealing. A bad actor who has stolen a user’s auth token could update the email address to then start the “forgotten password” flow with an email address they control.

How to avoid:

• Require re-authentication on any sensitive endpoints
• Rate limit authentication endpoints to prevent credential stuffing and brute force attacks
• Don’t reinvent the wheel for authentication – use well-known standards
• Where possible, implement multi-factor authentication

Pitfall Three – Unrestricted Resource Consumption

API requests consume resources: Compute, RAM, Storage, and sometimes paid services like SMS delivery.  APIs that do not limit the consumption of these resources are vulnerable to creating surprise bills at the end of the month. As well as opening DDoS attack vectors.

Consider this example endpoint for a restaurant chain:

POST /resend-confirmation


{"confirmationID": "124124125"}

Behind the scenes, an API call is made to an SMS provider’s endpoint:

POST /sms/send/template/12/


{"phonenumber": "xxxxxxx"}

The SMS provider charges $0.03 for each SMS sent.

A bad actor could write a script to call the resend confirmation hundreds of thousands of times. As a result, they will rack up a huge bill for the restaurant.

How to avoid:

• Use technologies to make it easy to set memory, compute, storage, etc. limits such as serverless code and managed container services
• Set limits on incoming resource sizes, such as file size, array lengths, etc. and reject processing any request that breaches the limit
• Implement rate limiting on endpoints, tuned to your business needs
• Limit the number of times a single API key or user can carry out an operation, e.g. get an SMS resent
• Configure spending limits or spend alerts on third-party suppliers to avoid huge surprise bills

Pitfall Four – Broken Object Property Level Authorisation

APIs often deal with JSON data, accepting JSON to update and process information about a resource.  Incorrectly implemented object property processing can lead to unauthorised updates of resources.  Consider the following two endpoints:

An account endpoint:

GET /account
Authorization: Bearer Token
{"accountID": "389235983752"}

Returns:

{
 "accountID": "389235983752",
 "firstname": "Bob",
 "lastname": "Smith",
 "phonenumber": "5554566556",
 "address": "1 Red Hill, London, EC1 1EC",
 "isadmin": false
}

And an account update endpoint:

PUT /account
Authorization: Bearer Token
<account object>

With incorrectly implemented property authorisation, a bad actor may send this PUT request that is designed to allow a user to update their account details. This could be Phone Number, Address and so on:

PUT /account
Authorization: Bearer Token
{
 "accountID": "389235983752",
 "isadmin": true
}

If the supplied properties are blindly set on the target resource, a bad actor can elevate themselves to admin by exploiting this pitfall.

How to avoid:

• When exposing resources via an API, always make sure you are only exposing what the user should have access to
• Avoid using helper methods such as to_json() or to_string(), instead only pick the object properties to process given the scope and the user’s authorisation
• If possible, avoid automatically binding client input to data structures, variables, or objects.
• Don’t return too much data – there’s no need to tell a user if they are admin or not!

Pitfall Five – Unsafe Consumption of APIs

Requests received from third-party APIs tend to be trusted more than user input, especially APIs offered by larger companies.  This can lead to weaker security standards applied to API input sanitation and validation.

An example may be that an API pulls in data from a social media blogging service.  A blog post that is being processed is named

'; drop db;--

Now, when the API takes this blog entry and saves it to an internal database, a SQL injection vulnerability is triggered to delete the backend Database.

How to avoid:

• Make sure to assess the security posture of any API or service being consumed as part of your offering
• Enforce TLS over all channels
• Always sanitise and validate data passing into your API, regardless of its source.  Treat all data as untrustworthy!
• Maintain a list of valid URLs that should be part of any third-party APIs – don’t blindly follow redirects to supplied URLs

API Security Conclusion

This is just a brief selection of issues and pitfalls the API developer may encounter. Hopefully, your API-building journey will be a bit safer going forward.  For a more detailed list of the top 10 API Security pitfalls visit the OWASP Top 10 here.