{"id":4121,"date":"2017-10-10T17:43:48","date_gmt":"2017-10-10T16:43:48","guid":{"rendered":"https:\/\/staging-site.42crunch.com\/?p=4121"},"modified":"2022-11-24T10:24:41","modified_gmt":"2022-11-24T10:24:41","slug":"api-security-faq","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/api-security-faq\/","title":{"rendered":"API Security FAQ : the top 5 questions we answered at the APIWorld conference!"},"content":{"rendered":"
The APIWorld conference came to end last week. This was the first public preview of our platform! We had a blast talking to many attendees and presenting at the event. This also gave us the opportunity to address a few common questions relative to API security and our product.<\/p>\n
Glad you asked:)<\/p>\n
API security as illustrated by the image below covers a lot of different aspects and it’s critical to look at API security in an holistic way.<\/p>\n
<\/p>\n
As a provider, you need to:<\/p>\n
And you need to adapt the settings for all of the above depending on the API you want to secure.<\/p>\n
Yes, we know. It’s complicated, but that why we created our company in the first place , so that applying security would be easier and could be automated !<\/p>\n
WAF were built for a specific purpose: protect web applications. Web applications architecture has evolved over the past years to use APIs as their back-ends (instead of traditional application servers). Basically, APIs are now the entry point into your enterprise, exposing data and processes from your core enterprise applications. The other major change is the externalisation of some of this data and processes, to public cloud and SaaS applications. An application today is typically mashing up 5 to 10 APIs accessing internal and external systems.<\/p>\n
While WAFs are capable of filtering HTTP traffic and understand the protocol, they do not understand APIs. In order to properly protect APIs, you need to understand API specific protocols and standards. Using a WAF to protect APIs implies defining lots of specific rules to avoid false positives, a manual process which makes it hard to keep up with the constant API changes. If you are using JOSE for message encryption and signatures, your WAF will most likely be incapable of decrypting the contents to search for attacks inside the payload nor verify signatures. Similarly, it will not be able to understand\/intercept OAuth or OpenID Connect attacks\u00a0 specific to the protocol, for example by enforcing recommendations as per the OAuth2 threats and security considerations RFC<\/a>.<\/p>\n Of course, WAFs still have their place for protecting web applications!<\/p>\n An API can be described very precisely using OpenAPI (a.k.a Swagger) – OpenAPI serves as the contract between the API provider and the API consumer. If your OpenAPI describes all the data coming in and out, including string patterns, bounded values for fields, mandatory headers and query params, payload formats, many attacks will be blocked by the engine as they will not match the description. Still, a false positive can happen, and we have means to let you specify that. But most of issues will be blocked by the white list alone. Of course, we also apply a black list to further analyze the traffic, after the white list has been applied.<\/p>\n It depends on the API gateway you use and the features it offers, but most importantly it depends on how *you* configure it. You will have multiple policy building blocks to choose from and and you will need to combine them to do all the proper checks we mentioned in point 1. Can you do it? Yes. But:<\/p>\n3. Why is your API firewall better at blocking API attacks ?<\/h3>\n
4. I have an API gateway in place. Isn’t that enough to secure my APIs?<\/h3>\n