Web Application Programming Interfaces, or Web APIs, are essential building blocks of our digital lives. They provide the tools and protocols that enable web and mobile applications to provide dynamic content and up to date, personalized information.

Our cars, bikes, and fitness trackers rely on Web APIs to track and guide us to our personal goals. In our homes, digital personal assistants help us manage our schedules, control our home, play our music, and much more, and they do so by interacting with an API provided as a service in the cloud. Google Pay, Apple Pay, PayPal, and many others enable businesses around to globe to process customer payments by the press of a button or a swipe of their phone. Their APIs provide easy integration and increased security for online commercial businesses. Smart cities and Industry 4.0 are taking over the manufacturing world and allow new interconnected and automated manufacturing technologies and processes.

Cyber-physical systems monitor physical processes and make decentralized decisions based on a virtual model of the real world. Industrial Internet of Things (IoT) communicate and cooperate in real-time with users and across organizations.

These are only a few examples of the digital world we live in today and which relies on one very essential building block: the Web API.

What Are Web APIs?

A Web API is a set of tools and protocols that provide a predefined interface for a request and response messaging system between two programs. It exposes reliable content and provides operation negotiation through a common defined language. REST, short for REpresentational State Transfer, and the Simple Object Access Protocol (SOAP) are the most common protocol styles for cloud service architectures, with REST by far the most common one.

[You may also like: How to Prevent Real-Time API Abuse]

SOAP used to be the go-to messaging protocol that almost every web service used; it is a standardized protocol that allows the exchange of messages using underlying protocols such as HTTP, SMTP, TCP, UDP, and others. SOAP builds on a large number of frameworks using XML to format the messages. The standard includes a Web Services Description Language (WSDL) which defines the structure of the data in the message. SOAP is an official web standard with specifications maintained and developed by the World Wide Web Consortium (W3C).

As opposed to SOAP, REST is much less of a protocol and more of an architectural style. REST only provides a set of guidelines and allows much more flexibility in the implementation of the protocol by its developers. As such, the REST architecture gained much popularity and fitted better the agile and continuously evolving specs and requirements of modern-day web services.

The percentages of API Architectural Styles for profiles in the ProgrammableWeb API directory [source: https://www.programmableweb.com/news/which-api-types-and-architectural-styles-are-most-used/research/2017/11/26]

REST is used to build web services that are lightweight, scalable, and easy to maintain. Services build on the REST architecture are called RESTful services. The protocol underlying REST is HTTP, the most common and standardized web protocol supported by almost every system and device on the internet. Any program that can talk HTTP is a potential REST client, any system that can process HTTP requests can expose RESTful services. Talk the talk, walk the … ; meaning there needs to be an agreement between consumer and service for them to exchange actionable and useful information, hence the use of a common language such as XML or JSON.

[You may also like: Adapting Application Security to the New World of Bots]

REST requests and JSON structures are straightforward
concepts. A request is very much like a URL with some arguments:


The response a webservice located at that URL could return might be a JSON formatted message. JSON is a human and machine readable format, very convenient and easy to find structure and derive meaning from the data by either humans and machines:

// JSON Object
 “user”: {
 “id”: 1,
 “name”: “admin”,
 “groupid”: 1,
 “password”: “123456”

The API Economy

To create new online applications within acceptable time frames, one should try to use existing and proven components for repeating and basic tasks. Focusing on the development of the innovative and differentiating parts of the application and not wasting cycles on the commodity is how in-house development stays productive and commercially viable. The why of in-house development is mainly the innovation and differentiation of the application, or what makes it stand out in the crowd.

[You may also like: 5G Security in an API-Driven Economy]

Most online applications rely on third-party and open
source components, some of which could be Web APIs hosted in different clouds.
Using third-party hosted Web APIs, developers can instantly add support for
repeated and complex processes and do so in just a few lines of code. Using and
consuming commercial-grade third-party APIs will typically not be free but is
generally billed based on a subscription and number of (API) calls model, which
embodies the ‘economy’ part of ‘the API economy.’

Credit card processing APIs are probably the most dominant
component used by all commercial websites. It is more efficient and more secure
to rely on a proven and certified third party to process customer payments. The
security aspect and trust-worthiness of, say PayPal, results in much less
resistance from visitors than to have them provide and store their credit card
details on your website. Failing to provide an extensive list of payment
options will negatively impact the success of your site. Think about how much
more sales you could realize if your mobile app integrates with Apple and
Google Pay and all your potential customer has to do is swipe from left to
right to buy your products and services? No information or personal details to
input, no additional authentication steps, all that is needed is a big smile
for their phone to authorize the transaction and complete the purchase.

The Radware ShieldSquare Bot Manager relies on this very same Web API concept. Radware Bot Manager exposes a cloud-based service into which on-premise reverse proxies and web applications make API calls to differentiate legitimate users’ and good bot from bad bot requests. The service is provided to our customers as a subscription and pricing based on tiers of maximum number of API calls per month.

[You may also like: Navigating the Bot Ecosystem]

APIs, Built For and Consumed By Machines

APIs are by definition interfaces between machines.
They are supposed to be consumed by devices and applications. Devices are
machines, and their communication with the API is from and to machines (M2M).
Mobile applications, dynamic web pages, or native user interface clients
provide a graphical representation through which humans interact with the API.
The graphical interface translates the interactions of the user into API
requests while the data received in the API’s response message is rendered into
a visual representation that makes more sense to the user.

Machines are good at processing structured data but have a harder time crunching through visual representations of that same data. Think about a paragraph in your document processor versus a scanned image of that same text. The visual representation of the text can be translated back to its original data representation, text in this case, but not without using complex tooling such as Optical Character Recognition (OCR) and only with a certain degree of success, most often not without introducing errors.

Do the exercise: this image provides tree representations of the same data. Which would you prefer to interact with and which do you think a machine would prefer? [data from https://opensource.adobe.com/Spry/samples/dataregion/JSONDataSetSample.html and formatted using http://json2table.com]_

Now put yourself in the shoes of an attacker that wants to scrape the product list from an online commercial website. Would you go at it by scraping and translating HTML pages and following links to discover and encode the full catalog? Or, would you first try to discover if an API feeds the dynamic content that gets rendered in the web browser? If you went for the latter, consider yourself a step closer to being a real hacker 😉

Securing Web APIs

The online nature of web APIs makes their
communications subject to snooping or man-in-the-middle and replay attacks.
Very much like the rest of the internet that is concerned about their privacy,
all communication should be encrypted and origins verified. As REST relies on HTTP,
SSL and TLS with certificates are the bare essentials.

Unless your Web API can verify the requesting client’s
origin through a certificate, and as such leverages mutual TLS (mTLS), there is
still no guarantee that the other side of the communication is a legitimate
program with good intentions. Web APIs build on the same stateless paradigm and
protocols used by web applications. While web applications are made stateful by
introducing (hidden) session keys that get posted on each subsequent request after
an initial login, Web API calls are by definition not stateful, but they can
leverage the same ideas and concepts.

[You may also like: Good Bots Vs. Bad Bots: What’s The Impact On Your Business?]

JSON Web Token (JWT), for
example, is an open standard (RFC 7519) that defines a self-contained way for
securely transmitting information between parties as a JSON object. The token
is signed using a secret or a public/private key pair and as such, can be
verified and trusted by a receiving service. Because of the self-contained
nature of the token, authorization can be performed based on just the token, no
need for resolving keys or tokens into actual identity.

For machine to machine communications, however, there is
no interactive authentication step after which a session key or token gets
generated. The way a consumer of a Web API can be authorized, is by using some
kind of shared secret that was agreed upon upfront and that is shared with the
API as one of the call request arguments. That secret would have been obtained
through a separate authentication and authorization step. Many third-party Web
API providers require the author of an application to register and request
access to the API, at which point he or she will be provided with a personal
access or API token. The API token identifies the client program and allows it
to consume the API, while the providing service can authorize and track
requests and utilization.

[You may also like: Application SLA: Knowing Is Half the Battle]

There are convenient APIs that provide authentication for third-party applications and can be leveraged by consumers and providers alike. Ever used your Google or Facebook account to get access to a service you never previously registered for? Applications and API providers can rely on a third party such as Google or Facebook, using them as a trusted middle-man to authenticate the consumer of the service. The consumer of the service can decide to trust the middle-man secures its private information and shares only what is agreed to and required for authorization with the provider’s service. The convenience brought to the consumer of the application is single-sign-on (SSO), meaning that the user only needs to register and login only once with Google and then can access and consume all the services and applications that rely on that middle-man. An example of such a standardized protocol is OAuth, also used by Google and Facebook in its 2.0 incarnation.

So I Secured My API. I’m Safe, Right?!

Not quite there yet, keep reading! Requests to Web APIs
can be authenticated, authorized, and their contents protected by encryption.

However, what if you host a commercial website? Your
definition of an authenticated user is that of a user that previously, in some
cases just seconds ago, registered for access your website. Automated programs,
commonly referred to as bots, are very much able to create email aliases,
register as fictitious persons, process the email validation requests and get
unlimited access to your website as do legitimate persons. A single request
performed by a bot does not look any different than a request originating from
a real human. Chaining multiple requests into an intended behavior; only then
can one reveal the legitimate or malicious nature of the other party.

[You may also like: 4 Emerging Challenges in Securing Modern Applications]

Some applications have the luxury of only servicing a limited number of consumers that can be vetted and certified through some clearance process – B2B applications typically. Even then, tokens can be compromised and unauthorized use of the API is still very much a possibility. Even if tokens are not directly compromised, client-side Cross-Site Request Forging (CSRF) and Server-Side Request Forging (SSRF) could allow malicious actors to abuse the API. Even when you have strict control on your API or host internal private APIs that are used only by your front-end servers, they are still at risk.

Mobile Apps, API Consumers With a Twist

Mobile applications are nothing more than fancy consumers of Web APIs. At least those applications that provide on-demand and data driven user experiences. Candy Crush probably not the most appropriate example, though a great user experience – no pun intended.

API requests are machine to machine and by consequence do not immediately reveal the presence of a natural person or the execution environment of the application. A web application’s environment can be challenged and identified using javascript injected into the application’s web pages. The content, application in this case, returned by a web server is dynamic and can be adapted on the fly or redirected if the need arises.

[You may also like: Web Application Security in a Digitally Connected World]

A mobile application, however, is static once delivered and installed and relies on API calls to only update that portion of the representation that contains dynamic information. Unless the mobile application includes functionality that allows it to identify human behavior through motion sensors or click and swipe patterns, and it can certify it is running on a real device and not in an emulated environment, the back end APIs cannot verify the actual state of the application.

By nature, mobile applications are publicly accessible and can easily be reversed to reveal their inner working. Reversing mobile applications uncovers the specific API calls directly following user actions such as clicks (or presses), as well as any embedded static tokens or certificates which provide the keys to the API kingdom.

Furthermore, easy access to device emulation software such as QEMU allows anyone to run the application in thousands of virtual instances and perform automated actions such as advertisement clicks which can cost you dearly.


Securing your web APIs and ensuring legitimate use of
them requires more than authentication and authorization. Even if you are sure
that your application is coded with best security practices, your
infrastructure is top-notch secured and audited, and the application contains
no vulnerabilities, there is still the threat of automated attacks that
leverage legitimate requests to build a chain of behavior that results in
malicious activity. Each individual request is legitimate, but the end game of
the thousands of bots disguised as legitimate users could be a depleted stock
or information being processed and leveraged competitively against you.

Building web APIs for B2B, providing customers with Mobile
Apps, etc. increases customer loyalty, prevents customer churn, and increases
revenue and competitiveness. However, these same APIs and mobile applications
can be turned into a weapon against your business, and in a very insidious way,
without immediate indication something or someone malicious is at work. A bot
management solution should be considered when exposing APIs that are directly
or indirectly connected with your business and revenue.

For those aware that applications without vulnerabilities
are RBUs,
consider the added layer of protection provided by a Web Application Firewall
that will prevent abuse of vulnerable code and infrastructure, and it will even
protect you from Cross-Site and Server Side Request Forgery.

Read “The Ultimate Guide to Bot Management” to learn more.

Download Now