Enhancing Security of Mobile Web Activity Pages: Human Verification and Risk Control Strategies

In the mobile Internet era, most marketing activities are still delivered through Web pages. Because Web pages are inherently transparent, they pose significant security challenges, especially for activity pages that involve coupons, red packets, and lotteries.

The article explains how to improve the security of mobile Web activity pages by introducing professional risk‑control services and human‑verification mechanisms.

Security Challenges of Activity Web Pages

Cheating users can directly call activity APIs to increase their chances of winning, leading to unfairness for genuine users and potential financial loss for operators (e.g., red packets being exhausted in one day).

Operators must ensure that requests come from real users, not automated scripts, and that no vulnerabilities are exploited.

Basic Risk‑Control Process

After integrating a risk‑control service, the protection flow typically looks like the diagram below (illustrated in the original article).

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

Risk‑control Service: Provides basic controls (frequency limits, black/white lists) and advanced models (Bayesian, neural networks). Supplies SDKs such as captchas and slider verification.

Back‑end Business Service: Executes activity logic (issuing coupons, red packets) only after the request passes risk verification.

Industry Practice – Google reCAPTCHA

Google’s reCAPTCHA evolved from text‑based captchas to a simple “I’m not a robot” button that analyzes mouse trajectories and device environment.

While effective, a naïve captcha can hurt user experience in activity scenarios.

Technical Challenges

1. Customizing Human‑Verification Algorithms: Front‑end must collect and report interaction logs (page entry, stay time, scroll, click) with timestamps and device data. Valid and decoy data are mixed to make reverse engineering difficult.

2. Ensuring Secure Communication: Use HTTPS, attach a unique token to each request, and encrypt sensitive payloads.

3. Preventing Reverse Engineering: Obfuscate front‑end JavaScript beyond simple minification.

Challenge 1 – Algorithm Customization

The normal user flow includes page entry, brief stay, scrolling, and button click. These actions generate logs with reasonable time ranges (e.g., page load >100 ms, <5 s) and coordinate bounds for clicks. Additional device information (browser type, container status) is also collected. Decoy data are added to confuse attackers.

Challenge 2 – Communication Security

All API calls must use HTTPS and include a server‑generated token. The token is a short, unique string with a limited lifetime (e.g., 10 minutes) stored in Redis and passed via header or cookie. It also serves other purposes such as user validation, dynamic symmetric‑key generation, and API signing.

Sensitive data are encrypted with symmetric algorithms; the encryption key can be derived dynamically according to a shared rule between front‑end and risk‑control service.

Challenge 3 – Code Obfuscation

Standard minification only shortens identifiers. Effective protection requires dedicated obfuscation tools (or custom Uglify.js rules) that heavily rename variables, restructure control flow, and add anti‑debugging tricks (e.g., detecting breakpoints). Over‑obfuscation may affect performance and source‑map usability, so a balance is needed.

Technical Solution Design

The complete solution can be broken down into the following steps:

Step 0 – Basic Risk Interception: Nginx blocks malicious requests (frequency limits, blacklists) with a 403 response.

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

Step 2 – Front‑end Generates Sensitive Data: Collects interaction logs, device info, business data, and decoy data.

Step 3 – HTTPS Signed Request: Sends the encrypted payload together with the token (e.g., in the Authorization header).

Step 4 – Server‑side Validation: Verifies token validity, decrypts data, and checks human‑verification rules.

Step 5 – Business Logic Execution: After passing all checks, the back‑end processes the activity (e.g., issuing a coupon) and returns the result.

Summary

Combining risk‑control, token‑based authentication, data encryption, and front‑end obfuscation dramatically improves the security of activity Web pages. Continuous monitoring of API success rates helps identify false positives and refine the protection mechanisms.

References:

Google reCAPTCHA

SegmentFault article

FreeBuf article