How to Secure Mobile Web Activity Pages: Human Verification, Tokens, and Code Obfuscation

Security Challenges of Activity Web Pages

In the e‑commerce sector, marketing activities are frequently delivered through mobile web pages because they allow rapid deployment and real‑time updates. However, the inherent transparency of web pages makes them vulnerable to abuse, such as bots scraping activity APIs to claim coupons or red packets, which leads to unfair advantages for malicious users and financial loss for operators.

Basic Risk‑Control Process

To improve security, a professional risk‑control service is typically introduced. The workflow generally includes front‑end data collection, a risk‑control service that provides verification SDKs (e.g., captchas, slider challenges), and back‑end business services that process activity logic only after verification.

Industry Human‑Verification Practices

Google’s reCAPTCHA is a widely used human‑verification service. Early versions required users to transcribe distorted characters, while modern versions analyze user behavior (mouse trajectory, device environment) and only require a simple "I am not a robot" click, improving user experience.

Technical Challenges of Human‑Verification

The ideal solution validates users without affecting experience, but faces three main challenges:

Designing algorithms that adapt to different user scenarios and collect interaction data on the front‑end for verification.

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

Preventing reverse‑engineering of verification logic and algorithms.

Challenge 1: Scenario‑Based Verification Algorithms

Normal users follow a sequence: page entry, brief stay, scrolling, and button click. Bots skip these steps. By logging each action with timestamps and validating the logical order, a simple yet effective verification can be built. Additional data such as device type, browser, and dummy “noise” data increase robustness.

Challenge 2: Secure Communication

Sensitive data must be transmitted over HTTPS, with a unique token generated by the risk‑control service and attached to every request. The token should be short, unique, time‑limited (e.g., 10 minutes), and stored in a cache like Redis. It also serves to identify valid participants, generate dynamic encryption keys, and sign API calls.

Sensitive payloads should be encrypted with symmetric algorithms, using dynamically generated keys agreed upon by front‑end and back‑end.

Token Design

The token is issued after the user loads the activity page, passed to the front‑end via an API or cookie, and then returned unchanged with the activity request. Because the token is server‑generated and time‑bound, attackers cannot forge valid requests.

Data Encryption

Encrypting sensitive fields prevents attackers from reading or tampering with the data even if they capture network traffic.

Challenge 3: Mitigating the "Paper Tiger" Effect

Front‑end JavaScript, even after minification, remains readable via browser dev tools, exposing logic to attackers. Code obfuscation—beyond simple minification—reduces readability. Custom or carefully configured tools (e.g., Uglify.js) can rename identifiers and restructure code, but excessive obfuscation may break functionality or increase bundle size.

Additional defenses include detecting debugger breakpoints by measuring execution delays and inserting anti‑debugging checks.

Technical Solution Architecture

The complete solution combines basic risk‑control at the Nginx layer, token issuance, front‑end generation of sensitive data, HTTPS‑signed API calls, back‑end verification of token and decryption, and finally business logic execution.

Step 0: Basic risk interception (frequency limits, black/white lists) at Nginx, returning 403 for malicious requests.

Step 1: Risk service generates a token and sends it to the front‑end.

Step 2: Front‑end collects interaction, device, business, and dummy data, then encrypts it.

Step 3: Front‑end sends the encrypted payload over HTTPS, attaching the token in the Authorization header.

Step 4: Back‑end validates the token, decrypts the payload, and checks human‑verification criteria.

Step 5: After successful verification, the back‑end processes the actual activity logic and returns the result.

Conclusion

By integrating human‑verification, token‑based communication, data encryption, and front‑end code obfuscation, the security of mobile web activity pages can be significantly enhanced. Continuous monitoring of API success rates helps fine‑tune the system, balancing false positives and true detections. While the approach is exemplified by Meituan, similar practices are employed by other platforms such as Taobao and Tmall, and security must evolve constantly to stay ahead of attackers.