by: Paul Bruce
What do you do to ensure that your APIs are as secure as possible and still meet your release deadlines?
A major UK-based online greeting card provider, Moonpig, has been found to contain numerous security flaws in their front-facing REST API. Developer Paul Price posted a detailed review of the problems on his blog, but in essence the following major flaws have been identified:
- Use of Basic Authentication over the internet
- Use of Account ID data in request without proper authorization checks
- Exposure of unnecessary Credit Card details
- Exposure of internal DNS details
- Little or no rate limiting
We Have the Technology
We have already been hitting the topic of API security hard, addressing how to think like a bad guy, providing how-tos and methods to prevent hacking attempts against your API, illuminating on lessons learned from other industry failures. We’re not the only people who understand the urgency either.
But at SmartBear, we believe that protecting customer data with layers of precaution should rightly be the focus of social media and industry professionals. Whether your APIs are “more than just glue” or the critical SPOF in your product delivery path, consumer confidence is shattered when security vulnerabilities are publically exposed.
How This Could Have Been Easily Avoided
In Moonpig’s case, if they had run some data-driven tests validating that the credit card information returned for a customer was their own and not others, the very simple process of, say, applying some data-driven assertions in Ready! API would have surfaced two of the worst issues above (authorization checks and PII exposure).
Basic authorization has pretty much always been a bad idea, sending PII in the clear across protocols that themselves do not ensure tampering. For most modern services, implementing OAuth is a great step to ensuring that your authentication process is both hack-proof and flexible between technologies. This is why SoapUI NG has out-of-box support for OAuth as well as other legacy authentication schemes.
Covering Other Areas of Security Concern
However, a lack of rate-throttling itself is a big problem if your service becomes unavailable. Paul Price’s further insight about how quickly a database of hacked data from a known vulnerability like the ‘GetCreditCardDetails’ method is genius, and very scary. In either case, any developer or quality technician equipped with Ready! API is able to run simple load tests against their service to prove either a lack or breach of rate-limiting controls.
A complete quality strategy involves more than just one type of test. If you really want to get serious about ensuring your API’s readiness, you need tools that directly address security testing and help you integrate security considerations into your API design process from beginning to end.
Article source: http://feedproxy.google.com/~r/SmartBear/~3/QagrZ1_l3e0/
Powered by Facebook Comments