API security areas to think about when coding

👋 Hello technical folks ~

Upon knowing the business requirements for the upcoming sprint, which of the following are you (and your team) likely to be:

Is implementing a system feature really that straightforward and easy — just “following what the Product Owner (PO) wants”?

Of course not! There’s a lot more to it than meets the eye! In today’s article, we’ll be discussing what are some of the security areas SWEs can think about before and during coding.

Note: We will be using the terms “feature” and “API endpoint” interchangeably.

After having to conduct many rounds of security reviews, we observed the following common issues with API endpoints:

1. No/insufficient validation on the incoming data

Data can be sent via various ways — external trusted system, form submitted by users, or CSV file upload. Most people (surprisingly not all) will remember to validate inputs from users, but the validations may not be enough. A very common missing validation is checking what’s inside a JSON object (how many attributes are you expecting?, checking the length and format of each attribute, etc).

What’s more worrying is this — teams always don’t perform checks on the data (or data files) received from the external (trusted) system(s) and/or trusted users via the file upload features. We often hear comments like:

Sounds familiar to you?

When building any features/systems, always do it from the zero-trust policy. Never ever trust anything that is entering your system! Always check what kind of content is coming in, just like how you’d check for the expiry date and the ingredients of the food/drinks you’re consuming. 😏

Oh just in case, frontend (or client-side) validation cannot replace backend (or server-side) validation ya~ 😉

2. Returning the online file storage path(s) as clear-text

If you’re storing files/contents online, chances are, you’re returning the path as clear-text as the API response or hard coding these paths in the Javascript file(s). And to make it even more convenient, the file storage is also made public (anyone can access it unauthenticated).

Now, you may ask: “If I’m only storing static contents (i.e. JSON files, images, videos), does it matter if I keep those paths as public? 🤔”

Of course it does! If an attacker grabs hold of the path of these static contents and replaces these contents with fake/rubbish/offensive/obscene contents, it will cause the organisation’s reputation to be tarnished.

3. Missing user-access check for API endpoint

All authenticated features should have user access rights in place, and it may be missed out due to any of the following reasons:

• Permission granted to the wrong user group(s) due to copying and pasting mistakes.
• Product team forgets to check if the user (making the API call) has the access rights to even call this endpoint. They may have missed out adding in the check(s) due to having too much code in a source file.
• Making the endpoint as public (by commenting off the code that checks for user access) during the development and/or testing phases (to save time) and forgetting to set the access rights back before going to the production environment.

This is why testing is a crucial job as most of such issues will be identified and resolved. 😉

Implementing any feature is not as simple as what we think to be; there’s a lot of deeper things to ponder about. We cannot stress enough the importance of validating all incoming data and restricting access to files/data and/or systems/storages. This is also why previously we mentioned having cybersecurity controls in place and running security scans for your application before going live are important.

Think a little deeper each time to prevent another security incident. 😊

🧙🏼‍♀Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.