Where is the truth and what’s the fiction ?
In this webinar Alexei Balaganski, Lead Analyst at Kuppinger Cole and myself contrasted our experience with customers and prospects and came up with a list of facts and fictions about API security. We both have seen a surge of interest in API security after a challenging 2018: breaches through APIs are accelerating at a high pace and it’s only the beginning.
Here are a few key takeaways from this webinar:
- The basics are still not covered: many of the issues that occurred last year could have been avoided if proper input and output validation were in place. Do not trust any of the contents coming to you, should that be params value, headers value, requests bodies, or tokens. Validate thoroughly before accepting any request: one of the first thing a hacker or bad bots will do is throwing all kind of bad data to your API and see how it reacts, then collect valuable information depending on how your API responds (such as the framework used to develop the APIs, or the hosting platform). In order to detect such API issues, you should be testing what I call the “hacky path” and not only focus on the “happy path”.
- Security, development and operation teams are still not collaborating enough to be efficient: none of these teams can do it alone, they need to collaborate. Each team has something critical to bring to the table in terms of knowledge, experience and protection. You can’t properly secure an API with data validation: albeit a key requirement, proper deployment of the APIs is also critical. For example, you must not expose data APIs directly on the Internet.
- API Security is not a one-off thing: putting some tools in place and forgetting about it is not going to cut it. As APIs evolve, security needs to follow: it needs to be fully part of the API lifecycle, and as much as possible automated. Meet DevSecOps and a culture of including security from Day 1 in your API development strategy.
- Trust None: most people we talk to understand the need for public APIs security, but in general do not care so much about protecting what they consider as non-public. First of all, public means on public internet. Anything with an IP on the public internet is public, even if you don’t advertise it in a developer portal. Furthermore, even internal APIs must be treated as equally exposed. Why ? Attacks could come an angry employee with a grudge against the company. But that is quite rare. Rather, your colleagues could have been victims of malware, phishing or social engineering. Moreover, your IoT devices (such as aĀ fish tank)Ā could have been hacked!
I let you discover other recommendations and advice through the webinar replay here:Ā https://www.kuppingercole.com/events/n40434. I hope you find it informative!
