Earlier this month OWASP updated its list of top 10 security vulnerabilities for the first time since 2010. Judging by the accompanying assessment, security has continued to be a major concern with today’s applications. This is especially true now in the era of APIs, where companies are making their core assets and business processes available for others to integrate in the hope of becoming a crucial (and thus monetizable) part of an ecosystem.
In this era, the risk for intrusion attacks, data theft or plain-old DOS attacks is evident. The risk might seem small, but the consequences are enormous. Consider the Playstation Network outage that exposed 77 million user accounts, or the more recent Twitter security breach, which exposed more than 250,000 accounts in Februrary.
Strangely, testing for security vulnerabilities and making sure that your application or API can’t be exploited through common security attacks still seems to be something most development teams either don’t know about or flat out ignore. At both StarWEST and StarEAST in 2013, only three of the more than 70 sessions were focused on security vulnerabilities. An analyst firm I spoke with recently was “baffled” by the lack of attention to API security. Vendors, API providers and API consumers don’t seem to be putting much effort into this area.
I have a couple thoughts on why that is the case:
- First up is simple ignorance. “It won’t happen to us,” or “I don’t know what you’re talking about.” The notion that no one would care to attack your application or API, or that the technologies, components or languages you are using aren’t vulnerable to attacks is just plain wrong.
- Early adoption of new and cool technologies. As stated above, far too often development teams don’t care about assessing their code for security vulnerabilities, and of course that goes for developers of new components and frameworks as well. The risk is even higher here; their focus is probably on adding new features and disrupting their landscape, not on making sure that their error messages don’t disclose sensitive information or that their APIs aren’t vulnerable to injection attacks.
- Security is a vast field. which means different things to different people. Some think of authentication and authorization, some think of SSL, encryption and signatures – and some think of VPNs, Firewalls and BYOD. Add a never-ending list of standards and acronyms to the mix (WS-Security, SAML, OAuth, SSL, etc.) and the risk is high that only a few of these areas will be pro-actively assessed during the development of your project. Oh, did I leave vulnerabilities and attacks out of that list? There you go…
A number of trends in computing mandate the need for proactive security assessments and know-how:
- The general trend to move applications and data to the cloud ultimately puts them in an environment where they’re more accessible to others than they were in your private data center – no matter how much firewall and routing configuration is built around them.
- Exposing core business data and processes over APIs makes them more accessible both for potential business partners (good) and hackers (bad).
- Big Data/NoSQL is all about storing as much data as possible – there is the risk that this data could be misused if it ends up in the wrong hands.
Obviously, you need to take security seriously: you are vulnerable to attacks no matter what technology or platform you use. Here are some recommendations for anyone who is building a new application or API:
- Make sure to add security to your requirements and backlog processes. It deserves to be made visible, just like performance, functionality, usability, etc.
- Proactively invest in security know-how and testing at the ground level. Make sure your developers and testers understand common security breaches and how to guard against them, just like they are hopefully aware of common performance pitfalls and how to avoid them.
- Test and assess security early in your project and don’t leave it to some single individual at the end right before production.
- Continuously monitor your applications for security vulnerabilities using available tools or homegrown solutions – just like you are monitoring performance and functionality (right?). Especially if you are in a fast-moving organization that has embraced DevOps and continuous deployment practices, new components or changes can have unwanted side effects.
- Make use of free tools and resources (like those available at OWASP) to get an overview of relevant vulnerabilities and how to make sure they do not affect you.
As a side note, if you are consuming third-party APIs, an interesting question is how defensive you should be in regard to them being compromised or “compromisable”? For example, what if an attacker manages to inject a malicious script into a third-party solution which returns that script in an API response that you are handling? Should you scan for this yourself? Or what if you are inserting sensitive data into a third-party solution via their APIs – should you proactively encrypt or sign data to “handle” an eventual intrusion on their side? Once again, these are questions that should be proactively assessed, even if your answer to both scenarios is “we’ll do nothing.”
Ultimately, security is hard, and it requires both time and in-depth technological know-how to master. As such, please don’t make security “Somebody Else’s Problem” - especially since that “Somebody Else” might ultimately be your users or customer if you are compromised. They deserve better, right?
- A Little Federal Swagger for your APIs
- Emulated vs. Real Device Mobile App Testing
- Automated Testing is Not Agile Testing