---
title: "Dmitry Sotnikov – REST API Security – there is no silver bullet"
url: https://appsecpodcast.com/dmitry-sotnikov-rest-api-security-there-is-no-silver-bullet/
date: 2020-09-30
duration_seconds: 2003
guests: ["Dmitry Sotnikov"]
topics: ["API Security"]
audio: https://www.buzzsprout.com/1730684/episodes/8122589-dmitry-sotnikov-rest-api-security-there-is-no-silver-bullet.mp3
video: https://www.youtube.com/watch?v=TLH_E0Oe_Y0
transcript: true
---

# Dmitry Sotnikov – REST API Security – there is no silver bullet

*September 30, 2020 · 33 min*

with [Dmitry Sotnikov](https://appsecpodcast.com/guests/dmitry-sotnikov/)

on [API Security](https://appsecpodcast.com/topics/api-security/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122589-dmitry-sotnikov-rest-api-security-there-is-no-silver-bullet.mp3) · [Video](https://www.youtube.com/watch?v=TLH_E0Oe_Y0)

## Show notes

Dmitry Sotnikov serves as Chief Product Officer at 42Crunch – an enterprise API security company. He maintains a popular community site with daily API Security news and weekly newsletter API vulnerabilities, breaches, standards, best practices, regulations, and tools. Dmitry joins us to discuss REST API Security. We talk about the top API security threats, counters to those threats, and the details on APISecurity. We hope you enjoy this conversation with ... He's also the maintainer of apisecurity. io, a popular community site with daily API security news and weekly newsletters. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term, sustainable security culture amongst all their developers.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Dmitry Sotnikov serves as Chief Product Officer at 42 Crunch, an enterprise API security company.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Dmitry Sotnikov:  
→ [APISecurity.io](https://APISecurity.io)  
→ [OWASP API Security Top 10](https://owasp.org/www-project-api-security/)

Mentioned in this episode:  
→ [APISecurity.io](https://APISecurity.io)  
→ [OWASP API Security Top 10](https://owasp.org/www-project-api-security/)

Chapters:  
00:00 Meet Dmitry Sotnikov: Dmitry Sotnikov – REST API Security – there is no silver bullet  
02:02 Oh wait, so you, you want to talk about a technical  
07:26 I'm curious though about your previous role from an API management  
09:49 Our topic today is REST APIs. I remember back in the  
12:37 We think about the differences in security then, we've acknowledged the  
16:40 With that in mind, what are some of the top security  
25:09 That points to counters, countering that kind of thing. I mean  
26:44 Yeah, I mean, and I've even seen, I mean, I'm sure  
30:27 We appreciate you joining us today, Dmitry. I was wondering if

## Transcript

*4,734 words · assemblyai*

**0:00 Chris Romeo:** Dmitry Sotnikov serves as Chief Product Officer at 42 Crunch, an enterprise API security company. He's also the maintainer of apisecurity.io, a popular community site with daily API security news and weekly newsletters. Dmitry joins us to discuss REST API security. We talk about the top API security threats, counters to those threats, and the details on apisecurity.io. We hope you enjoy this conversation with Dmitry Sotnikov. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term, sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey. I'm also joined today as normal by my co-host Robert Hurlbut. Hey Robert.

**1:39 Robert Hurlbut:** Hey Chris. Yeah, Robert Hurlbut, threat modeling architect. Good to be here today. We're going to talk about an interesting topic that I remember looking at the first time, I don't know, maybe 10, 15 years ago. Thinking about REST and in particular security around that.

**1:55 Chris Romeo:** Oh, I was thinking you were talking about rest like a nap or something, that type of rest.

**2:00 Robert Hurlbut:** No, not that kind of rest.

**2:01 Chris Romeo:** Oh wait, so you, you want to talk about a technical topic around REST? Here I was preparing to grab my pillow and begin my nap time, but we won't do that. But we are joined by a guest who is going to help us to understand a lot of things about API security. And that is Dmitry. And Dmitry, we always jump right in with our guests. We give you no time to get acclimated or anything. We're jumping right in with, what's your security origin story? How did you get into this crazy, wacky world of security?

**2:33 Dmitry Sotnikov:** Yeah, thanks, guys. So let me think about it. So I came to API security from the world of API management. So I used to work for a company called WSO2, which is the leading open source middleware company. And I was in charge of their cloud business, cloud line of business, and that included API management. As any integration middleware platforms these days, APIs are there, right? They're inevitable. And so I was there from 2014 to 2018. Building our cloud API management story. And initially back in 2014, APIs were still kind of manageable. Companies would still have relatively few APIs. They would mostly care about public APIs, APIs they would expose for their partners. They would have really few, whatever, 3, 5, 10, manageable amount. They would change relatively rarely. And security basically meant auth or basic authentication and some rate limiting. And that was API security. And so things were kind of controllable. Again, relatively few APIs, relatively rarely changing. AppSec people could look through them, look at the design, approve them, have approval workflows and so on. But then things sort of In 2016, '17, '18, things started to collapse. First of all, the whole microservices cloud-native app revolution started happening and started happening very quickly. And now all of a sudden APIs started proliferating. So companies that used to have 5 APIs now could have 50 and next time they know, 500. Just because what used to be classes and objects now would be microservices talking APIs, and developers would just spin them up just like they used to spin up classes and objects. And obviously everyone's agile, and so all of these APIs now changing every day because all of those proverbial 2-pizza teams keep pushing changes all the time. And so AppSec people could no longer control things and could no longer scrutinize design of each and every API because there were too many of them. And also that meant that attacks became more sophisticated. So now your edge started disappearing and so people would no longer attack just the frontend, just your web UI or your mobile app UI, they would start going directly after the APIs. And then APIs are obviously very close to the backends, very close to data, and so it's a whole different stack of attacks. And so basically, I started painfully observing that customers and community in general that used to just assume that API management was sufficient and was all they needed for API security That was no longer the case, right? And so attacks changed dramatically. And so that's how I got interested in API security. And then a friend of mine, Isabel Moni, she co-founded company 42 Crunch and she sort of talked me into joining. And that's how I started looking into what makes APIs different and what makes API security different. And then as part of educating myself within the company and working within 42 Crunch on all the tools for API security that we have for static analysis of APIs, for API security testing, for API runtime protection, I also started educating myself and I saw the whole flow of all the vulnerabilities coming within for our customers and the community in general. And I thought, okay, we need to do something with that information. I'm going through all those vulnerabilities and all the information and there's so much confusion on the market and in the community. So I started doing just the community website, apisecurity.io, putting some stuff there, just whatever I found. So that's how the whole newsletter started and that's how I got pulled into that whole API security thing and then OWASP and OWASP API Security Top 10 project and then OWASP AppSec California Once you're in, you're in.

**7:22 Chris Romeo:** Once you're in, there's no getting out.

**7:24 Dmitry Sotnikov:** Not of the security world.

**7:25 Chris Romeo:** I'm curious though about your previous role from an API management perspective. Were you in a product manager role?

**7:32 Dmitry Sotnikov:** I was. So I was basically kind of a general manager of the line of— of the cloud line of business for WSO2 for everything cloud. So our public cloud offerings, our dedicated cloud offerings. API management was a big part of that business. Okay.

**7:49 Chris Romeo:** And so, now in those, while you were in that role, what was your, what would you say your security knowledge level was?

**7:55 Dmitry Sotnikov:** I think it was very basic initially. So when I was just starting, I mean, I used to work and lead other SaaS sort of product development efforts and product management efforts in the SaaS world before. So I had a basic understanding that you should obviously, like, your cloud environment should be secured, you should have the lowest possible permissions everywhere, you don't store your keys where they can be grasped, don't put them in code. I mean, things like that, common sense things, but REST for me was just the path and the verb and not much more to that.

**8:40 Chris Romeo:** Okay. And so you've educated yourself as you've made that transition from an executive management position to working for 42 Crunch. You, you've educated yourself about API security. And so I just throw that out there because, you know, we probably have people listening who are thinking, well, I'd love to, to make a transition into, into security, but I don't know if it's possible from what I'm doing. And what I'm always trying to tell people is it's possible to transition into security from anything.

**9:10 Robert Hurlbut:** Exactly.

**9:11 Chris Romeo:** Doesn't matter what you were doing before. If you have some passion for this, we've got room for you, no matter what you did in the past.

**9:18 Dmitry Sotnikov:** Yeah. I mean, and frankly, I think it's actually a good career step. I think that the world needs more security specialists and more security specialists in the world of APIs. So I think that can be a good career move. Even if you're a developer and you want to stick to being a developer, a developer who knows API security is a much more valuable developer and just API security and DevSec specialists in general. I think the demand is huge.

**9:49 Robert Hurlbut:** So our topic today is REST APIs. I remember back in the early 2000s attending a security summit on SOAP and everybody was using SOAP then. But then a little bit later REST came along. And I'm curious, do you know in our modern app infrastructure how much or how prevalent is REST APIs now compared to a number of years ago? How much is REST out there today?

**10:21 Dmitry Sotnikov:** So they are very prevalent. It's very hard to tell exact numbers. The most recent exact number which I have seen was in Akamai State of the Internet report, which they publish every now and then. So the report that they published last year in early 2019 said that 83% of all web traffic was API traffic, and by far most of it, almost entirely being REST and JSON. And obviously Akamai's data is very representative because a lot of the internet traffic goes through Akamai. So I'd say very prevalent. I mean, there is still some SOAP, especially with the legacy systems and sort of intranet systems. There is now some gRPC for the microservices in the world of microservices. There is some GraphQL, and GraphQL is growing, some async APIs, but still, majority by far, the majority of web traffic and API traffic is just REST and JSON.

**11:35 Chris Romeo:** And you think about, like, from a product perspective, the prevalence of API, and sure, it's all the things we think about off the top of our heads. It's frontend UIs for web apps, it's mobile apps, but I mean, you think about, like, IoT. How does IoT function? IoT functions based on API. Like, the world runs on API is the conclusion that we're drawing here.

**12:00 Dmitry Sotnikov:** Yeah, absolutely. And yes, exactly. So when people get stunned by that 83% of all web traffic, and then they start thinking about it, and I mean, even if you use your web application, I mean, when you watch your Netflix, It's not like you're getting a static page rendered somewhere on the Netflix server. No, you have a single-page application, rich application that is using APIs, but the logic is in the app. A lot of logic is in the app. So that's how that 83% number comes from.

**12:36 Chris Romeo:** When we think about the differences in security then, we've acknowledged the fact that, yeah, REST API, JSON is the language of the internet at this stage. When you're thinking about the security differences, though, between a REST API series of endpoints and a class— more of a classic web model-view-controller, MVC-style application, what are the— can you compare and contrast the security of REST API versus an MVC app?

**13:07 Dmitry Sotnikov:** Yeah, sure, absolutely. So in the In the good old MVC days, you would have, again, that model-view-controller split. And so your browser would basically get HTML from the backend, from some sort of a web server. And so the server would have all the logic. Like when I'm clicking something in the browser, the browser sends that information that I clicked something.

**13:36 Robert Hurlbut:** Right.

**13:37 Dmitry Sotnikov:** to the backend server. The backend server would have the code, would work, would have something, some code getting executed on the server, would work with the database, create me a new HTML page, send that new HTML page to the browser, and that's how I would get my new page. And so to protect— so that is a fairly safe architecture if you think about it because your your clients don't really have access to your logic and obviously to your data. The data is behind your server and the server just talks HTML to your browser. And so obviously there were attacks like whatever, SQL injections, etc., but you could be relatively safe as long as you had a reasonable web application firewall, WAF, where you would have some sort of rules that would detect those attacks based on the signatures of different SQL injections, etc., etc. So you had a fairly well-defined edge and fairly well-defined products and approaches to control that. In the modern world of IoT, as you mentioned, Chris, and single-page applications and mobile applications and microservices, it's a much, much difficult, different picture. Because now all of these clients are smart clients working directly with the APIs. But they have, they have their own data cache. Like if, if whatever, if my mobile app, my mobile phone goes offline, I might still be able to continue playing my game or doing something. And when my connectivity is back, it will get new data from the from the cloud, it's syncing back to the cloud, etc. So it talks directly, APIs. And then my APIs often, again, it's just if I'm exposing data as a developer, if I'm exposing data to that client, to that mobile app or web app or IoT device, and there's another team working there, it's just much more easy for me from a design perspective to just expose all data and give access to all my functionality because that's sort of a clean separation between what I do and what the other team does. So, it's very easy and natural for me to just give them more before they even ask and just rely on them being my security boundary. And so, that means that people often don't realize that that the security boundaries are now at the component level, on the API level. And that brings us into a much, much different picture when it's very easy to expose your sensitive functionality. It's very easy, extremely easy to expose your sensitive data without realizing that.

**16:39 Robert Hurlbut:** And with that in mind, what are some of the top security threats? I know you mentioned exposing more than you should or sensitive data. that you shouldn't. What are some of the top threats that you see in REST API?

**16:54 Dmitry Sotnikov:** Right. So yeah, I mean, obviously exposing sensitive data is there, right? There was that infamous hack of Uber when I believe it was the API for their consent screen, which, I mean, how much data should be exposed for the consent screen for the app? But that That API returned just everything that they had on a particular client. And all you had to do, actually, it was a 2-step exposure. One step is in some of their error messages, they exposed internal ID of an object, which again, internals getting exposed through APIs. And then that consent screen API, when you supplied that object ID, the user ID, it would give everything including the current access token and all the information that they had on that driver or customer. So that kind of overexposure is definitely there. But even at the more basic level, I think number one is probably just APIs not being secured at all. Just teams relying on some sort of frontend, some sort of edge being there and not realizing that that edge might actually not exist in reality and someone might just use their app through a Burp or some other proxy and just find or discover the URLs otherwise. Or there might be some protection on the frontend but one might be able to bypass it. Like on the Black Hat conference just a couple of weeks ago, researchers were talking about how they hacked into Mercedes-Benz smart car because each of those smart cars, they have the eSIM in the car and the car talks to the backend. And so that eSIM and all of that system was relatively protected, but they could get through that hardware protection And once they got through that, they effectively connected to the intranet to which all the cars, all the smart cars were connected. And it turned out that APIs on that level were not protected at all. There was just no security on the API level because I guess the team just assumed that frontend was the edge. So that's just a lot of that. And finally, obviously, the good old IDOR BOLA is still there, that broken object-level authorization. We are seeing a lot of that, especially now with the whole COVID-19 tracing apps. A lot of these apps are now mandatory in some countries and some regions. And a lot of them, you just, you can get information about yourself, but then you take that API call, you set another ID, or you even enumerate rate IDs and you now get COVID status and all the data of everyone else. There's a lot of that too.

**20:11 Chris Romeo:** Yeah, just the overall lack of authorization on the backend is definitely a huge one. I wanted to throw another one out that I was doing some research into API security recently, looking at kind of some of the news stories and things, and there is a payment payment company who shall remain nameless, but on their website, they expose— they have an API that shows the most recent transactions across their network. Apparently, there are people who have written scraping bots that are just sitting there scraping all the API transactions, so they're catching a stream of all the trends. This is millions and millions of transactions per day, and then they're taking that data and then they're funneling it into an analysis system. And because people leave comments associated with these payments, they then take that and they put it into a big database and they start to look for patterns and things across it. So that was another example of API not protecting sensitive data, but they're not even thinking that they have a security problem there. But when I saw it, I was like, wow, that's like, you know, I think about what we can do with bulk data. We can see all kinds of fun patterns. connections between people. So just another example.

**21:30 Dmitry Sotnikov:** Exactly. Yes. Yeah, I think APIs— so in that sense, I think, Chris, that's actually a very good example because in a sense, APIs are doing to data access and to functionality what databases at some point did to data in general. I mean, the data was still there, right? But they just made things a lot more accessible. And so something that was okay in the times when everything was manual is not okay anymore because there's programmatic access. So look at all the credential stuffing attacks. It's much easier when there is an API to get authenticated and try things. And again, good old rate limiting doesn't really work because rate— I mean, in the old way, when people would use rate limiting just to get themselves protected against denial of service attacks because now there's actually application logic attacks that people can try to get more data like you mentioned or to just enumerate password reset codes and things like that. So that's definitely the case and another kind of similar Similar kind of attack would be just people trying to abuse your parameters, trying to send you something that you don't expect, try to test different edge cases, different formats. That's very hard to detect. Like if you're— a good example of that was the Tchap application that French government rolled out as their own secure messaging system. And so they rolled it out because they didn't want the employees to use WhatsApp and Telegram, etc., that off-the-shelf software for internal communications. They rolled out their own and that got hacked. And the way it got hacked was ridiculously easy. Someone registered in the app and then they tried different— they found the API for that and they started using the API rather than the UI. to get registered because some of the controls were on the app level and not in the API. API didn't really control the parameters and so instead of supplying the email address that the backend sort of wanted and they had to use that email domain of the French government, lse.fr for the French presidential administration. Attacker just took his own email address that had nothing to do with the French government and then added that @lec.fr to the end of it. And because the code in the API just looked whether that address, whether that login ends with the thing, it worked. It passed the checks and so the guy got into all the confidential internal discussion boards of French government by doing a thing that's so simple because he used directly the API and he did something, some sort of an edge case kind of variation that the backend didn't expect. So an attack like that, there's no way like a web application firewall can catch that because it has no idea what the backend needs. So that kind of parameters not being, like data not being properly validated, et cetera, is also a They're very much prevalent today.

**25:08 Robert Hurlbut:** So that points to counters, countering that kind of thing. I mean, as you just said, validation that we always talk about, not trusting user input and validating the input and so forth. What are some other counters to these kinds of threats that we've talked about?

**25:27 Dmitry Sotnikov:** Yeah, I think number one thing that anyone should probably do is just to make sure that they have a solid inventory, solid discovery process. Because like I mentioned, it's extremely easy for developers to spin up a new microservice, a new API, and it's very natural for the modern architectures. So, I think number one thing is just to make sure that all the APIs that get spun up are actually controlled, whatever you have, your CI/CD process or some other process that would discover all the APIs and you have a good grasp of the APIs that you have. And then you have a way to sort of enforce your policy, your security policy around them. So you make sure that you have security, you have authentication on each and every API, right? You have data validation like Robert, you just mentioned, on data coming in but also data going out, right? It's so easy to leak something. We still see APIs that just crash and send back the exception traces with all the information on the whole stack that they're using. That still happens.

**26:44 Chris Romeo:** Yeah, I mean, and I've even seen, I mean, I'm sure others have seen this as well, and you've seen it too, Dmitry, where the way an API is designed, they'll send extra information just because, and the frontend doesn't actually use it, but it's in the JSON. So if you look at the response from an API call, you're like, All I needed for the frontend was name and email address. Why is their birthdate, social number, and everything attached to the JSON? Well, because the developer didn't prune the JSON and didn't clarify what they wanted for the object. They just said, send that whole object to the frontend, even though I only need 2 properties from it.

**27:20 Dmitry Sotnikov:** A lot of that, I mean, to be fair, a lot of that is also coming from tooling, the development stack. Also got more complex inside to make things easier for developers. So there were, I mean, people would still run some sort of CRUD API generators, so they would just generate the APIs on top of a database and that would give everything just because that's the default mode. Or they would have, like a good example of that, of the extra functionality would be that GitHub, when they got, when they had API vulnerability, I think early this year, they had their authentication endpoint and it was supposed to only have GET and POST. You use GET to get information and then you use POST to actually authenticate. And they thought that that was the only thing that they had, but they used Ruby on Rails library and that Ruby on Rails generated HEAD each time it saw a GET. And so they had a HEAD operation which they were not aware of. And so their developers— so we think that HEAD is not a big deal. It's just kind of a bodiless version of GET. But in reality, it was a big deal because their code relied— in their code, they effectively had if-else statements assuming that if it's not a GET, it's POST, and if it's not a POST, is GET. And so being sent something unexpected, they got unexpected behavior and got hacked.

**29:03 Chris Romeo:** Dmitry, I actually was introduced to you through your apisecurity.io site that you run. And so I just wanted to help our listeners to understand if they go to apisecurity.io, what's the purpose of that site and what are they going to find there?

**29:20 Dmitry Sotnikov:** Yeah. So apisecurity.io It grew to be probably one of the most popular community sites for REST API security. We have a newsletter there and a daily newsfeed which we also have on Twitter and on LinkedIn. And so right now I think we have about, actually more than 5,000 newsletter subscribers. So it definitely became much more than just a hobby project than it was years ago. And so that's probably why most people come there, but we also have a section on OWASP APIs Security Top 10 and information about that project and the detailed description of each of those. We have API Security Encyclopedia with again kind of knowledge base of the common issues in APIs and API contracts. We've recently added calendar of events, so it sort of keeps growing and becoming a bigger community side of everything REST API security.

**30:27 Robert Hurlbut:** So we appreciate you joining us today, Dmitry. I was wondering if you could, for our listeners and our viewers, maybe some key takeaways. How, you know, somebody is trying to figure out, maybe they have a REST service and now they're, they're, they're listening to this, they go, wow, those are some things I didn't even think about. Maybe you could give us some key takeaways and maybe also a call to action. for our listeners and viewers?

**30:53 Dmitry Sotnikov:** Right. I guess I think the biggest takeaway is that APIs are a real security threat, real attack vector. I think Gartner, in one of their reports, they mentioned that they expect that by 2022 it will be number one attack vector. So it's definitely serious and that API security, it's just, you can no longer think about it as just something that AppSec people or just some operations people can handle. API security, APIs are just by their nature, they're very close to your backend, to your data, to your logic. So it's like everyone's job. And it's also at the state where It has to be automated. You just cannot, like, no matter how brilliant, like, if you have a brilliant AppSec person in your company, that person will still not be able to manually control everything unless you want that person to become the bottleneck and throttle all your development efforts. So shift left, automate as much as you can, make sure that it's discovery, it's design, it's testing, and it's runtime. And so it's just, Security is a multi-stage thing. There's no silver bullet. You automate everything, you discover everything, you properly document your APIs in a machine-readable format, and it just— you make it span your company, span your development process.

**32:32 Robert Hurlbut:** Excellent advice. I like that, no silver bullet. We've heard that before and we'll hear it again, and of course, it still applies. So thank you, Dmitry, for joining us today. Really, really appreciate it. Great advice and a great topic. Thank you again.

**32:47 Dmitry Sotnikov:** Thank you, Robert. Thanks, Chris. It was a pleasure being here.

**32:50 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute And Robert, @RobertHurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/dmitry-sotnikov-rest-api-security-there-is-no-silver-bullet/