How Server-Side App Attestation Protects APIs From Bot Attacks

It has finally happened; to no one’s surprise, the majority of internet traffic is no longer human. Bots make up more than half of all web traffic. As people have shifted their online activity to mobile apps and devices, bots have followed making mobile the new battleground for automated attacks.

How can developers distinguish between bot and human interactions with their applications? What techniques can they employ to differentiate and identify malicious imitators from genuine users?

Server-side app attestation is the key. Not only does it stop bots in their tracks, it mitigates the impact and probability of future attacks. We’ll dive into the details below about the benefits of app attestation and how it increases protections from bots. But first, how does the interaction of APIs in mobile apps relate to bots? And why is authentication critical for API protection?

Why user and app authentication are critical for proper bot defense

Today's digital ecosystem is built on the foundation of APIs, and for mobile applications, these APIs are the lifeblood that connects the user interface to the server's data and logic. A user presses a button and, in the blink of an eye, a request is sent to a server, a database is queried, and the result is returned to the app. This seamless interaction, however, has created a critical vulnerability. The challenge isn't just knowing who the user is, but what is making the request. In the world of automated attacks, this distinction is paramount.

The problem, in its simplest form, is that an API can’t inherently verify who or what is making the request. While authentication protocols have become sophisticated at verifying a user's identity, there is no reliable, universal protocol to authenticate the application itself. This gap allows malicious actors to reverse-engineer and replicate the legitimate app's API calls. By bypassing the mobile app's user interface, attackers can launch automated bot attacks that mimic genuine interactions but at a massive and relentless scale. These bots can then manipulate the API without ever interacting with the intended user experience.

The motivation behind these bot attacks is often profit-driven and can lead to significant consequences. Attackers can use bots for a variety of malicious purposes, including credential stuffing to take over user accounts, scraping valuable data, or exploiting business logic to create fraudulent transactions. Because these bots are designed to mimic human behavior, they can operate "low and slow" and evade traditional security measures. Without a robust defense at the API layer, a business's valuable data, revenue, and reputation are at risk. A proactive approach to mobile API security is therefore not just a technical necessity but a crucial business imperative.

Why and how bad actors use bots to execute automated attacks

The “Dead Internet Theory” has been circulating the interwebs for some time. With recent studies stating that over half of all internet traffic is bot traffic, the theory’s popularity is no surprise. And with traffic shifting from web to mobile devices, the bots are following suit. You may have seen this already on social media apps like X or Instagram. You might have even unknowingly interacted with bots.

What this ultimately means is that it’s critical to protect your app against these bots, as their share of mobile traffic will continue to increase in tandem with the shift to a mobile-first user experience. Below are reasons why bad actors have come to proliferate the internet and mobile apps with bots, with examples of common bot attack methods.

Bots fake human activity cheap and fast

The cost of bots can be as low as fractions of a cent when compared to human activity. They’re not just cheap, these bots are also fast and effective: a bot can make multiple API requests in a single second. As you might imagine, this is highly scalable. Just a few bots can simulate hundreds of genuine, human interactions with an application. An attacker with hundreds of bots has an army ready to execute automated attacks. If applications are not prepared, their gates are wide open for this bot army to flood inside.

Easier to commit fraud at scale

Bots are used to commit fraud at scale that otherwise would not be possible. Attackers use several different methods to accomplish this. One method is credential stuffing. An attacker will use illegally obtained login credentials to execute a variety of combinations in order to gain access to an application using these verified accounts. Once inside, they have the ability to create numerous accounts they can use for future attacks. They may also use stolen Multi-factor authentication (MFA) codes. They’ll accomplish this by having bots waiting day and night on malware or phishing websites to swoop in and take these codes, negating the advantage of them being short-lived.

An attacker may also use a brute force attack. As the name suggests, the attacker will organize a swarm of bots to target an application in the hopes of overriding its servers to gain access.

Finally, an attacker may use deep-fake images for fake account creation or credential stuffing. With the advent and growth of AI technologies, this is a growing concern for many mobile applications. Many apps today, particularly financial apps, rely on registration or authentication through biometric means, like face ID. This was a reliable method of security until recently. Now, bad actors use AI models to generate faces to match real profiles. With the assistance of bots, bad actors can rapidly generate, iterate, and submit these illegitimate faces.

After creating these fake faces, bad actors will register new bank accounts that can be used for receiving and sending dirty money. These accounts will often go unnoticed and bad actors will continue to operate them until they’re found. While fraud teams have gotten better at identifying and closing fake accounts, it is easier than ever to create these accounts by using a combination of bots and AI technology.

Bad actors can use bots to cheat the system

Many applications, from games to loyalty apps, reward users for activity. This may include interacting with sponsors, viewing ads for a certain length of time, or interacting with content. Unfortunately, bad actors can take advantage of this situation by using bots. Bots can be programmed to facilitate specific app actions at scale that are known to lead to rewards, effectively cheating the system.

Another example is multi-player mobile games. Unethical players may deploy bots to garner coins or other rewards for in-game activity. This disrupts the entire game ecosystem for honest players, and may even drive users to quit. With plenty of mobile games to play on the app store, game developers cannot risk having an unethical game environment when competition is already so fierce.

Social media is a well-known example of malicious bot traffic. There have even been instances of content creators paying for bot farms to distribute likes, comments, and shares of their content to drive up views and their account’s value. Again, this is a way to cheat the system at scale while disrupting the larger ecosystem of the social media content landscape.

Block resources and paralyze competitors

Bots can also be used in targeted attacks against competing organizations. Distributed denial of service, or DDoS, attacks have been used to flood servers with requests with the goal of overwhelming them to the point an application has been rendered unusable by its users. To get back up and running, an application will require significant time and development resources. Customer success teams will then need to commit more time and resources to answering user requests and resolving the fallout.

Online ticket platforms are a common example of this type of attack. When popular events go on sale with pent-up demand, a bad actor may execute a bot attack in order to gain tickets for the purpose of scalping off-market. When paired with the unusual demand placed on the platform, this can cause an outage that takes considerable time to rectify.

Interestingly, a new type of scalping emerged during the pandemic: restaurant reservation scalping. When going out to places like restaurants was subject to seating quotas in the early days of the pandemic, platforms like Resy, OpenTable, and Toast took off as convenient methods to book reservations at home. However, with the limited supply came increased demand, and the opportunity for attackers to take advantage of the situation.

Now a persistent problem in major dining destinations like NYC, bad actors quickly discovered these apps did not have security protections or basic limitations in place. They realized they could book multiple tables on the same evening, even at the same time, for the same restaurant. After deploying automated bot attacks to book these reservations with methods like credential stuffing, they could sell these reservations off the platform. Restaurants and diners alike have been dealing with this problem, and the aforementioned apps have begun implementing new protections to help curb this illicit activity.

Scrape data for reselling to other parties

While it may seem harmless at first glance, simple querying of your servers can be taken advantage of by bots to scrape valuable data for the purpose of reselling. Data like product catalogs, price lists, inventory information, and contact information are all highly valuable.

For instance, a developer may create a start-up application by scraping data from different sources and gathering it in their application. This could be as simple as a developer wishing to create an application to find the lowest car rental price. They can deploy hundreds of bots to scrape pricing and inventory information from different vendors then place it in their application. They can even match promotions and discounts that are “only” available through your application. Users may instead prefer their app to visiting different apps to price shop, and may even make the purchase from the new application. While it may benefit the user, it harms the car rental vendors that no longer have customers using their application to complete their purchase.

The trilemma of app attestation

Solving the problem of bots attacking your APIs is not an easy task. The main source of the difficulty is that there are two parties interacting with each other for each API request: your server and the client-facing application. The difficulty is that your server is under your control but does not have the necessary client-side information; meanwhile the client-side application has all the information but is susceptible to complete control of an attacker if using a malicious application. So, what’s the solution?

The solution is to introduce an independent attesting party into the schema. Here is where mobile application attestation comes into play.

How does verification with app attestation work?

On the surface, mobile app attestation is very simple. Imagine every security request that comes through the client is accompanied by a piece of payload that contains a verdict about the security state on the client side. The task for your server after receiving the request with the payload is trivial. The server examines the payload to determine if it meets predetermined security requirements and protocols. If they are met, the request is allowed through. If not, the request is denied and blocked.

In the case above, a bot or modified application would be identified when the server determines a negative verdict then denies the request. A positive verdict verifies that the request is coming from a trusted user on a genuine, unmodified instance of the application. But where does the verdict come from?

This is where a third party attestation service comes into play. First, the application collects the necessary data to make a conclusion regarding the security of an application. Then, that information is sent to the attesting third party. An example service is Guardsquare’s mobile app attestation capability. After the information is sent to a threat monitoring or similar service, the app attestation capability responds with a verdict that’s packaged in a token.

However, before arriving at a verdict, the app attestation capability consults predetermined security policies. These policies form the foundation at which a decision is arrived at and supported by, the constitution of attestation, if you will. These policies are determined by development and security teams on what is and is not acceptable criteria for an application to meet in order to interact with the application’s server. Criteria may include certain allowable app behaviors, environments, etc. that can be changed at any time.

Regardless, the check will only be conducted on the server side. The client-side of the application will never know what the policies are, which provides a crucial added layer of security. Now, back to the verdict. A verdict, determined by the app attestation capability, is issued in a packaged payload token back to the application. The application, in turn, sends the same token to the server. This token is cryptographically encrypted and short-lived, making it quite difficult for attackers to read, learn, and iterate for future attacks.

The server then analyzes the token and determines whether to interact with the application based on the verdict. After verifying the authenticity of the request, the service is complete. All done securely in the app developer’s cloud, out of attackers’ reach.

The benefits of app attestation

Find what to take into account

For those already practicing secure mobile app protection strategies, there are a few tangible benefits to moving protection logic to your server side. You do not have to resort to crashing the application to stop the execution of an attack. Unlike the client side, you can consult your server-side database to gain more data about the actor or attempted transaction. This is because your server stores many other sources of data, unlike the client side.

Examples of data you might want to look into are if this actor is sending the wrong signal but also executes a transaction that’s atypical for the client. Do they regularly interact with other users of the system? A developer could use data on the server side to pull out ranks of potential fraudsters from the system.

Understand how to react

Not only does the developer learn what data to use but how to react to a potential attacker. The simple solution is to crash the application or not respond to the request. However, this is not the only solution. Since the data needed to act is now available, more precise action can be taken. For instance, flags can be set and recorded in a CRM or fraud system, reply with automated comments in a ticketing system, and even notify security teams.

Know when to react

Development teams utilizing app attestation no longer have to just autoreject requests. A team may want to find further information regarding a request, but does not want to risk tipping off the threat actor. In this case, the team can issue a seemingly positive response to keep the threat actor on stand by while they investigate.

While the threat actor that issued the request is kept waiting, the development team in the background can investigate its authenticity. This includes communicating the threat at a deeper level. For instance, they may wish to wait until the user authenticates before rejecting the request. By taking this approach, the development team collects more information while avoiding putting their servers or applications at risk.

Deploy instant security policy updates

Policies can be configured at any time without having to release a new version of the application. They will begin taking effect immediately. Thus, significant development time and resources that otherwise would be needed are now available for other tasks. If there is a gap in your protections, for example protection against rooted devices but not emulators, it can be addressed instantly. This rapid deployment and customization of security protections is possible because they are on the server side.

Monitor using continuous threat detection updates

App attestation threat definitions are continuously updated and maintained by Guardsquare, based on security research and the data captured from end user devices. Certificate revocation lists are a prime example. A team may decide they are going to work with devices that have bootloaders signed by valid certificates or keys. If a manufactured key is compromised, they do not have to issue a new release of their app. Rather, it will automatically be updated by Guardsquare’s system to automatically react when it becomes known. No action is needed by the development team. The certificate revocation list will be updated and so will the team’s security. An online solution like the one provided by Guardsquare will always use the latest data to protect against emerging threats. Teams save significant time and resources that would otherwise be dedicated to researching protections against the newest attack methods.

Bridge the gap between client-side and server-side security

Just like mobile applications, mobile app security strategies are not focused on just the server or client side. Both are essential to building an application, and each requires specific security protections to mitigate risk, including bots. Solutions like mobile app attestation help establish a bridge between the client and server sides for better communication to stop bad actors and bots from executing devastating attacks.

For more information about how Guardsquare can help build your mobile app protection strategy, including app attestation, contact us here.