The Queue-it virtual waiting room lets you filter and throttle visitors before they arrive on your site, making it a powerful tool for mitigating bots and abuse.
Queue-it’s virtual waiting room includes several bot and abuse management features that you can use in parallel with your other mitigation tools to bolster your defenses.
We define “malicious traffic” as traffic coming from bots or users that try to unfairly access your website or app.
Traffic coming from bots and scripts includes:
- Off-the-shelf bots
- Custom-built applications
- Curl / wget command line scripting
- Headless browsers
- Brute force attempts trying to avoid the queue/guess the target URL
Traffic from malicious users involves:
- Visitors trying to obtain multiple places in line via multiple browsers / devices
- Visitors trying to bypass the waiting room by avoiding invoking the queue logic
- Visitors waiting through the queue and then sharing sessions/cookies with others so they don’t have to wait
- Visitors disabling cookies / AJAX calls to Queue-it to avoid invoking the queue logic
Malicious traffic can have real, negative consequences for your business:
- Malicious traffic adds extra load, which could cause your website and app to slow or crash earlier than anticipated.
- Malicious traffic undermines fairness and therefore harms your brand image. For example, if you’re selling sneakers or concert tickets and most of them end up on the secondary market at huge markups, customers will be upset and lose faith in your ability to control your sales.
Bots and malicious users try to gain an unfair advantage by using one or several of these strategies:
- Bypassing the waiting room (i.e. navigating directly to the target URL and skipping ahead of others in line)
- Using speed to get the best possible queue number
- Obtaining multiple queue numbers, for example by using many unique sessions on different devices to have several places in line
Bots and malicious users operate using their speed and volume advantages to unfairly access your site.
Scripted bots use their speed advantage to enter a site milliseconds after the start of a sale and quickly advance past human users to the checkout page. When done at scale, these bots can come away with a massive amount of product.
Even when there is a waiting room in place, malicious users will try to use a volume advantage to gain many spots in the waiting room, giving them a better chance of getting first access to the products.
Here is a list of steps you can take with Queue-it to prevent bots and abuse, from the simple to the sophisticated.
Queue-it Connectors support integrations with native mobile apps and leading CDN, load balancer, tag management, ticketing, and ecommerce platforms in all languages. They can normally be configured in one day by a skilled developer.
To learn more about integration options, visit our Queue-it Connectors page.
All visitors who arrive before a timed sale or registration starts are placed in a waiting room that counts down to the start of the sale or registration. When the sale or registration begins, everyone in the pre-queue is randomized.
The scheduled waiting room has two benefits. First, it offloads early visitors from your infrastructure, preventing early traffic from overwhelming your site or app.
Second, it neutralizes bots designed to arrive just before the start of the sale or registration and beat out genuine visitors.
To learn more about setting up a scheduled waiting room, get the Technical Integration white paper.
Traffic from data centers has a high probability of coming from a server rather than a laptop, smartphone, tablet or other device. Data center servers are often where bots or scripts are executed for malicious purposes. Scalpers and other bad actors can purchase server space in a data center and easily obtain hundreds of IP addresses to obtain multiple places in the waiting room.
With Queue-it’s data center IP blocking it’s possible to block traffic originating from data centers in two ways. You can “soft-block” the traffic, meaning visitors will be met with a security challenge/CAPTCHA to verify that they are genuine users. Or you can “hard-block” all data center traffic, where all such visitors receive an HTTP 403 Forbidden response.
To learn more about data center IP blocking, read our product update.
Queue-it’s virtual waiting room monitors all traffic arriving to your protected pages or site. If the virtual waiting room identifies suspicious traffic from an IP address, which is often initiated by automatic scripts or robots, that IP will be soft-blocked.
A significant percentage of the blocked bots by our platform are blocked in this way, as malicious users attempt to simulate real users on a massive scale from one IP address.
This kind of access pattern is often different from normal human interaction with the web (e.g. very short latency and high rate of attempts), and therefore can be detected by Queue-it.
To learn more about configuring anomaly detection for your waiting room, get the Bots and Abuse Management white paper.
You can display Google’s CAPTCHA to visitors which they must pass before entering the pre-queue countdown page or a running waiting room. Blocking bots before they enter the waiting room neutralizes their unfair speed advantage.
You can configure Queue-it to show all visitors the CAPTCHA challenge, or only to suspicious users.
To learn more about configuring CAPTCHA for your waiting room, get the Bots and Abuse Management white paper.
Bots that just run a few HTTP requests are simple and cheap to make. But forcing bots to complete performance-intensive tasks—tasks that a real visitor’s browser could complete easily—significantly increases the costs to the bot makers and bad actors.
Well established in bitcoin technology, Proof of Work requires a service requester (in this case your visitor’s browser) to solve a mathematical puzzle using computing power.
Queue-it’s Proof-of-Work challenge raises the bar for how complex bots need to be and uses computing processing power as the cost driver during execution. The more queue numbers that bad actors seek to obtain, the more CPU is drained and the more costly their project becomes.
At the same time, the Proof-of-Work challenge will be barely if at all noticeable to real visitors. Their browsers can easily solve the puzzle to grant them a spot in line.
To learn more about Queue-it’s Proof-of-Work Challenge, read our product update.
Visitor identification allows you to block malicious traffic and bad bots prior to them entering the waiting room. With a visitor identification key and an enqueue (enter-queue) token, you can determine which visitors are genuine and can move forward.
Visitor identification keys are any data point that can be used to identify a visitor, such as an account ID, email address, or promo code. The enqueue token is a vehicle for transmitting visitor identification keys between your application and Queue-it. The token is signed and encrypted so that it can’t be altered as it’s passed from one system to another. Linking waiting room entry to a physical identification or controlled virtual ID in this way is a powerful method of combating bots and abuse.
You have the option to enforce uniqueness on visitor identification keys (i.e. each ID is only allowed one place in the waiting room) and to require an enqueue token to enter the waiting room, meaning that visitors cannot share entry with others.
You put these tools into practice in several ways. For instance, you can assign an enqueue token only for visitors who’ve logged into your system. Or, only for those who’ve received a personalized link via email.
After visitors exit the waiting room, you can add an additional level of security by verifying that the visitor has a valid enqueue token and has been through the waiting room (i.e. didn’t find a way to bypass the waiting room).
For instance, when visitors try to complete a transaction you can call the Queue-it API to verify that they have a valid enqueue token before they’re allowed to complete their transaction. Alternatively, you can allow visitors to complete the transactions unimpeded and verify the transaction was associated with a valid enqueue token before you ship their order.
While validating visitors who’ve exited the waiting room requires more complex setup on your end, it creates a reinforced, enclosed flow where only desired visitors enter the waiting room and only those who’ve passed through the waiting room can complete transactions.