How to Secure Mobile Web Campaign Pages Against Bot Attacks

Security Challenges of Activity Web Pages

Marketing activities on e‑commerce sites often rely on web pages for rapid deployment and real‑time content updates, but the inherent transparency of web pages makes them vulnerable compared to native mobile apps.

Common activity patterns such as coupon collection, red‑packet distribution, and lottery draws are easy to abuse by bots that directly call the activity APIs, leading to unfairness for genuine users and significant financial loss for operators.

Operators must worry about distinguishing real users from machines, ensuring requests originate from legitimate browsers, and preventing security vulnerabilities from being exploited by “wool‑pullers”.

Basic Security Process

To improve the security of activity web pages, enterprises typically integrate professional risk‑control services. The overall protection workflow is illustrated below.

Web Front‑end: Collects user interaction data for human‑verification (different for mobile H5 and PC pages).

Risk‑Control Service: Provides frequency limits, blacklist/whitelist checks, and advanced models (Bayesian, neural networks) based on large‑scale data. Supplies SDKs for captchas, sliding verification, and API validation.

Backend Business Service: Executes core activity logic (issuing coupons, red‑packets, lottery) after the request passes risk‑control validation.

The primary goal of integrating risk‑control is to perform reliable human‑verification.

Industry Human‑Verification Practices

Google’s reCAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is the most widely used captcha system.

Modern reCAPTCHA no longer requires users to type distorted characters; it analyses mouse trajectories and environment data, allowing a simple “I’m not a robot” click.

Simply adding a captcha or a “I’m not a robot” button can hurt user experience in high‑interaction activity pages, so a more seamless verification method is needed.

Technical Challenges of Human Verification

Ideally, verification should be invisible to users while remaining secure.

Key challenges include:

Designing algorithms that adapt to different usage scenarios and validate collected interaction data.

Ensuring secure communication between the front‑end and risk‑control service.

Preventing the verification logic from being reverse‑engineered.

Challenge 1: Scenario‑Based Verification Algorithms

Normal users follow a sequence: page entry → short stay → scroll → click button, generating logs for each step. Bots may skip these actions and directly call the activity API.

Collecting timestamps, action types, device environment data, and even “decoy” data creates a robust dataset that is difficult for bots to mimic.

Challenge 2: Secure Communication

All sensitive data must be transmitted over HTTPS, with a unique token included in each request.

Token Design

The token is a short server‑generated string tied to the user’s identity, stored in Redis with a limited lifespan (e.g., 10 minutes). It is passed to the front‑end via an API or cookie and must be sent back unchanged with subsequent activity requests.

Tokens also serve to identify valid participants, generate dynamic encryption keys, and sign API calls.

Sensitive Data Encryption

Symmetric encryption protects the payload; dynamic keys derived from the token further increase security.

Challenge 3: Mitigating “Paper Tiger” Risks

Even after minification, front‑end JavaScript remains readable via browser devtools, enabling reverse engineering.

Code obfuscation—beyond simple minification—reduces readability. Custom or heavily‑configured tools (e.g., Uglify.js) can rename identifiers, restructure control flow, and insert dummy code, while keeping bundle size reasonable.

Additional defenses include delaying execution to thwart breakpoint tools.

Technical Solution Design

The complete solution integrates the following steps:

Step 0 – Basic Risk Interception : Nginx filters high‑frequency or blacklisted requests, returning 403 for obvious attacks.

Step 1 – Token Generation : Risk‑control service issues a token to the front‑end before the activity page loads.

Step 2 – Front‑end Data Assembly : Collect interaction, device, business, and decoy data.

Step 3 – HTTPS Signed Request : Send encrypted data with the token in the Authorization header.

Step 4 – Server‑side Validation : Verify token, decrypt payload, then assess human‑verification criteria.

Step 5 – Business Logic Execution : After passing all checks, process the activity (issue coupon, run lottery, etc.).

Summary

Improving the security of activity web pages requires a multi‑layered approach: front‑end behavior tracking, robust risk‑control services, token‑based HTTPS communication, data encryption, and thorough JavaScript obfuscation. Each component must be correctly implemented; otherwise, vulnerabilities can be exploited, compromising the entire verification flow.

Effectiveness can be measured by monitoring API success rates and analyzing false‑positive versus blocked requests, allowing continuous tuning of the protection mechanisms.