WebApp Security v/s API Security
Recently I had an interesting conversation with one of my friends. He said "You know APIs and Web Apps are almost the same in that they need the same kind of security measures"...I heard this a lot of times. "API security is the same as Web App security because most of the times APIs enable Web Apps, you protect the WebApps thats enough.... blah blah .. "..
I beg to disagree. Yes, APIs enable Web Apps but seeing both with same security perspective is not right.
With evolution of Web and Mobile Devices the "app" got bigger and more diverse playground for itself. The more diverse the playground the more diverse security requirements are.A secure Web App does not automatically means secure APIs that it consumes.
In the service sector industries, be it retail, hospitality, food etc. there is a common adage "Know Thy Customers”. The same holds true when it comes to APIs. Most of the times we end up exposing "some" APIs and then "adjusting" the app's major functionality/capability according to what API provides. This is not the correct approach esp. when we are exposing APIs to public networks.
For APIs always follow "Know Thy Consumers".
That means you need to keep the "Target Consumer or App" in mind when you design and develop your APIs. And for different classifications of apps (mobile v/s system v/s Web-App v/s SPA) the API should protect itself and its data with necessary security measures.
For instance usually when people think of Web-App security they perceive that covering OWASP top 10 is good enough measure and their application is secure. Well! To some extent OWASP's guide for web app would provide a good measure of security.But it does not ends there.What about the API ?
From an API's perspective the security measures are determined by which app is calling its service" for what operation and scope on the data. For example for a SPA (Singe Page App) that just displays a set of static read-only data to the end user a minimal set of authentication/authorization (say certificate validation, app credentials) is required between the app and the API service. But for cases where the end user credentials and authorization is required and/or session management is required OWASP Top 10 + Token based authentication/authorization (OAuth, Open ID, SSO etc.) maybe required.
API security, is characterized by access scopes, access time, rate limiting...etc. An API sees the app and not the consumer of the app. So when one have to plan different strategies of securing an API one needs to consider the below points
1. Authentication/Authorization for different apps and the categories of apps that are going to consume the service
2. Sensitivity of the data exchange between the app and the API service
3. Legitimacy of the data in the requests/response (injection threat protection)
4. High Availability and Scalability of the service
5. Constraints of the business model for the services exposed, for example one would want to have a rate limit on the number of request served for B2B scenarios
6. Visibility into all the aspects of the API ecosystem (the dependent resources, the developers, the Apps, the request-response traffic that the API serves). Proper visibility will help in responding quickly to any hack or breach that may occur due to API vulnerability.
Quiet a lot of effort goes into ensuring that the services and functionality provided by the Web-App powered by APIs are secure and flexible. Security does not end at the Web-App level but it continues on to the enablers (APIs and other dependent resources).
Nice read Naveen Singh, ITIL. One question I have is, do we need to think about securing our API based on the content of the data exchanged? Or the rule is to secure any API exposed on the web?