October, besides being peak fall season is also national cyber security month, hence along with enjoying ‘pumpkin spiced chai’, it’s also a good time to discuss security of the APIs we create and work with everyday.
I work with APIs a lot, particularly REST APIs, which are growing in popularity. In my experience often REST projects start with great enthusiasm. Everyone in the team is gung ho that they have finally conquered their fears of change and have moved on from a legacy API type to REST. Team members get involved in design sessions, books are read, there are ‘aha’ moments of enlightenment and then developers set out in the noble quest of implementing the pure REST API.
Finally there is a moment when everything is in place, the data model looks perfect, and there is an exact mapping from an object in the database to CRUD (Create, Read, Update and Delete) calls. Objects are being read with GET and added with POST.
Challenges in keeping up with the best practices
Everything works beautifully till the day the customer comes up with a change request, which needs modification to a data object, and insists that the object now needs to be split into two types, and very surreptitiously mentions that this needs to be delivered within a week.
Leads and developers clash, people are horrified at the prospect of doing a big change in the data model at such a short notice. Whiteboards are filled with curvy lines going from one colorful box to another, showing the impact that this seemingly little change will have on the broader design of the API. Finally it’s agreed, reluctantly, by the team that the data object will be split into two types in the database. But keeping the timelines in mind, a workaround will be implemented and a REST call for both object types will still be kept the same, with a parameter in the URL defining the type of object being accessed or created.
The above situation seems like an innocuous change to the API, but the people on the team so far who are so proud of their pure REST API are horrified. Rightfully so, as they just introduced a parameter into the URL to identify an object. A big ‘No’ in the RESTful world, a URL structure represents an entity in the REST world. A parameter in the URL to access or define an object is not so RESTey.
Security is the first victim of workarounds
Needless to say that stories such as the one above abound in the world of API development, often for the sake of time, budget and project scope, REST standards are massaged, misinterpreted and sometimes even mauled beyond recognition. This is all okay from the tactical point of view and works well in the short term, but in the broader scheme of things this may cause some major problems. Especially when the security of the API is at stake.
A major result of the change in the REST API described above is the shifting of sensitive information into workaround zones like URL parameters. This is bad news for the security of your API. For instance, if you read the REST security cheat sheet by OWASP (Open Web Application Security Project) it explicitly states that:
“The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.”
This makes a lot of sense, and not just for session tokens, but also for any other type of sensitive information, like names, merchandise types and phone numbers.
Why is it not a good idea to have information in the URL? Well, because:
- Your URL goes places, it is very much exposed to the whole world, it’s embedded in emails, in third party code, it gets shortened and gets tossed around pretty much everywhere. You do not want anything even remotely sensitive there.
- Attacks like cross site scripting can use URL parameters to introduce malicious scripts in your API calls.
Walk the tightrope, keep the best practices in sight
If you are developing or testing a REST API, you should try really hard to stick to the REST best practices. Learn from the experience of others in developing and testing a REST API. Adhering to best practices doesn’t just help you to maintain the REST APIs better, but also makes other initiatives like security testing of your API painless. For example, If you refrain from putting any data in your request parameters and instead bind your information well in your request or response body, you can test for vulnerabilities easily by running a security scan on just your body. Otherwise you have to think of myriad URLs, headers and other aspects of your API calls. Not to say that you should not scan your headers and URLs at all, you definitely should, but do not let yourself or your team get complacent to the point that they can pass sensitive information anywhere in your HTTP request or response, just because you have some sort of security testing in place.
We have focused on a thin slice of security best practices for REST here, but I would like to emphasize that security for your API is also very much intertwined with your broader processes. Good security practices in coding and testing result from better practices established at the organizational and team level. Along with thinking about REST best practices, below are a few things you should keep in mind while thinking about security:
- Know the security criteria you are testing for, figure out the risks your APIs are most vulnerable to.
- Test for security early, if possible just after coding the API. Integrate your security tests with your nightly builds and read the results first thing in the morning.
- Spread awareness, discuss test results and best practices with your team, ensure everyone is implementing them and deliverables like code and test cases are being regularly reviewed.
- Use security tools and understand the results, a good tool will help you get on track to better security, but you have to interpret the results from the tool correctly and know how to plug the gaps.
The OWASP website has a list of top 10 vulnerabilities in online services. It’s a good idea to be aware of these in order to ensure that your services are not afflicted with them. Although updates to this list are infrequent, it’s still a good idea to keep checking the list for any changes.
We at SmartBear have been continuously working to enhance support for security testing of REST APIs. We released Secure Pro 1.9 with a focus on improving REST API security. We have now added security scans for the body of API calls. These scans are designed to check the top 10 OWASP vulnerabilities. Now with holistic scanning of their API calls, developers and testers can easily stick to REST standards, keep any sensitive or personally identifiable information in the REST body and with a few clicks ensure that their API are free from vulnerabilities.