wechat-miniprogram-pentesting

WeChat Mini Program Penetration Testing Methodology

Phase flow: Confirm what you have → Obtain client artifacts → Unpack and restore → Source code audit → Interface surface testing → Authorization and payment logic → Output

In-depth reference

.wxapkg unpacking, subpackage merging, and restoration failure troubleshooting → references/wxapkg-unpacking.md
Front-end source code audit key points and key/interface extraction patterns → references/miniprogram-source-audit.md

Phase 0: First confirm what you have

The first fork in Mini Program testing is not technical, butthe source of the target artifacts. You must first confirm the starting point; do not blindly search the local file system by AppID—the container or test machine most likely does not have the target artifacts at all, and not finding them does not mean the package does not exist.

手上有哪一类产物?
├─ 已反编译的源码目录/压缩包  → 直接进 Phase 2（最高效，跳过解包）
├─ .wxapkg 包文件            → 进 Phase 1 解包
├─ AppID 或 #小程序:// 短链   → 进 Phase 3，仅能做接口面测试
└─ 什么都没有                → 停止本地搜索，向操作员索取（见下方「产物获取」）

Artifact acquisition (when artifacts are missing)

Do not continue execution without artifacts. Explain to the operator what is needed and provide the acquisition paths:

Target artifact	Acquisition method
`.wxapkg` package	After the Mini Program runs on an Android device, the package is cached in WeChat's private directory (requires root or adb backup); WeChat on PC also has a cache directory
Unpacked source code	The operator uses any unpacking tool to process `.wxapkg` and then directly provides the compressed package
AppID	The Mini Program details page "More Information", or the request parameters seen in packet capture
Interface traffic	The session file exported by the operator using a packet capture tool while using the Mini Program

The AppID is an 18-character,wx hexadecimal string starting with (wx + 16 hex digits).#小程序:// is a PC-side sharing short link; you need to open it once in WeChat to obtain the real package and traffic.

Boundary prerequisites

Only processauthorizedMini Programs. Handle unpacking and audit artifacts within the authorized scope; do not distribute or disclose them.
The Mini Program's front-end artifactsare all client-controllable content. Any assumption that "the front end performs validation" does not hold; all authentication and business rules must be re-verified on the server side.

Phase 1: Unpack .wxapkg

.wxapkg is the compiled artifact container of a WeChat Mini Program: the header magic number, file table, and data segment are all in a custom binary format,unzip and similar tools cannot open it.

# 基本用法：解包单个包，输出到同名目录
wxapkg ./app.wxapkg

# 分包：以主包目录为基准合并
wxapkg -s=./main ./sub-package.wxapkg

# 只解包、不做资源还原（用于判断问题出在包还是还原阶段）
wxapkg -o ./app.wxapkg

# 批量
wxapkg -f ./*.wxapkg

After unpacking, what you get are the compiled artifacts and restored resources:.js(beautified logic),.wxml(templates),.wxss(styles),.json(configuration and subpackage information).

Restoration is not lossless decompilation: the Mini Program compilation format changes with WeChat versions, and some new formats may not be handled cleanly. If restoration reports errors or the output is suspicious, first use -o to only unpack the original files, confirm that the package itself can be read, and then distinguish whether the problem is package encryption, package format, or the restoration stage. For detailed troubleshooting, see references/wxapkg-unpacking.md。

Encountering an encrypted package: The mini program package may be hardened/encrypted; in that case unpacking will directly report a magic number error. This is not a matter of technique—the operator needs to provide the corresponding unpacking environment or already-unpacked artifacts. Do not attempt brute force or bypass inside the container.

Phase 2: Frontend Source Code Audit

Once the source code is obtained, the mini program frontend is essentially no different from an ordinary web frontend. The audit goal is not "find vulnerabilities" but rathermap out the attack surface: which endpoints, which parameters, and which are controllable on the client side.

High-Value Target List

Category	Location	Points of Interest
Keys and Credentials	`.js` Global constants,`config` class files	AppSecret, cloud development keys, third-party keys for maps/SMS, encryption IV
Endpoint inventory	`request` call sites,`app.js` baseUrl	Endpoint paths, methods, parameter names, whether a login session is required
Encryption implementation	Self-written `encrypt` / `sign` functions	Whether keys are hardcoded, whether signatures can be forged offline
Permission checks	Page `onLoad` if branches	Whether there is logic that "determines role on the client"
Local storage	`wx.setStorage` / `getStorage`	What is stored, whether role or permission flags are stored
Business rules	Price, discount, and usage-count calculations	Whether calculations are done on the client and submitted directly to the server

For audit patterns and extraction commands, see references/miniprogram-source-audit.md。

Client-Controllable State Flags (High-Frequency Root Cause)

The most common root cause of privilege escalation in mini programs is thatthe server trusts state or identity fields sent by the client. Typical form: the frontend stores a role/identity flag locally, includes it in requests, and the server returns data based on it without performing server-side authorization.

During the audit, look for it using this approach:

搜索这类字段名 → 找请求里谁携带它 → 尝试改成其他值 → 看响应是否变化
role / isAdmin / userType / level / identity / statenow / storeId / tenantId

Treat such fields as client-controllable in all cases; as long as they can be modified, you must actually test whether the server re-verifies them. Once found, do not just report "the frontend has a role field"—actually change the value, send the request, and prove the privilege escalation holds using the response difference.

Phase 3: Endpoint Surface Testing

All business in a mini program is done through endpoints; the endpoint surface is the most reliable direction for producing results.

Authentication Boundaries

After obtaining the endpoint inventory, first determine three questions:

Which endpoints do not require a login session? Remove the token/Cookie and replay; endpoints that still work should be separated out from the "requires login" list in Phase 2.
How is the login session verified? Is it a self-issued token or a WeChat code exchanged session? If the issuance logic is predictable, it can be forged.
Privilege escalation directions: horizontal (swap a user ID to get someone else's data), vertical (a normal user calling admin endpoints).

Prioritize Mutation Endpoints

Privilege escalation on read-only endpoints has limited impact; prioritize testingendpoints that change state or move money: placing orders, changing addresses, refunds, redemption/verification, adding points, changing permissions. Once such endpoints trust client parameters, the impact can be directly demonstrated.

Parameter Enumeration

ID-type parameters (orderId、userId、couponId、storeId) one by one with adjacent or enumerable values. Note the distinction:

Auto-increment IDs: directly iterate ±1
Snowflake/timestamp IDs: need to collect real samples from other interfaces or responses
Encoded IDs: base64/hex decode to see whether it is a plaintext ID

Phase 4: Authorization, Payment and Cloud Development

Payment and Business Logic

Mini program payments involve merchant IDs, order numbers, and signatures; the attack surface centers on "whether the client can influence the amount or order status":

When submitting an order, modify the price, quantity, or coupon ID, and verify whether the server recalculates
Whether payment callbacks can be forged (callback address, signature verification)
Whether order status is client-controllable (e.g., the status field)
Zero-yuan orders, negative amounts, over-issued coupons

Do not make real payments. Verify the logic with a minimal amount or a test merchant ID, and stop immediately once the issue is confirmed.

Cloud Development

For mini programs using WeChat Cloud Development (CloudBase), the frontend carries the env environment ID. Misconfigured permissions in a cloud development environment can lead to direct database read/write:

If the frontend shows wx.cloud.init / cloud.database() → cloud development is present
Extract env and then check the read/write permissions of the database collections ("all users can read" is a common misconfiguration)
If cloud functions do not verify the caller's identity, they can be called directly

Open Data and Third Parties

Mini programs often integrate third-party keys for maps, OCR, SMS, push, and so on. When these keys are hardcoded in the frontend:

First determine whether it belongs topublic-type keys(those that are meant to be exposed in the frontend by design, such as official WeChat keys)
Only those that are clearlyserver-side-only credentials(AppSecret, cloud keys, SMS keys) count as issues, and their impact must be verified (whether they can actually be called, whether there is a quota)
Do not treat "plaintext configuration present in the frontend" directly as a vulnerability. A single key string does not constitute a Finding; you must prove it is exploitable or has leaked sensitive information.

Relationship with Other Skills

android-app-pentesting: When the target also provides an Android installation package, or the mini program's underlying layer uses native hardening, use that skill for static/dynamic analysis on the APK side.
ios-pentesting: The same applies to the iOS client side.

Finding Criteria

Before submitting, ask yourself one by one:

Has it been provenactually exploitable, rather than merely discovering suspicious code?
Does the server really not re-check (rather than the frontend blocking it and the server also blocking it)?
Does it belong totargets and data within the authorized scope?
Does it avoid real financial loss and pushing test content to real users?
Has the same root cause been split into multiple Findings to pad the count?

Content that must not be submitted as a Finding:

Mere plaintext frontend configuration, presence of hardening, version numbers
Only successful unpacking or only obtaining an interface list, with no demonstrable impact
Predictability of third-party public keys (such as official WeChat SDK keys)
Unable to reproduce, or dependent on data outside the authorized scope

Common Mistakes

Mistake	Consequence	Correct Approach
Knowing only the AppID and searching for the package locally `find` Find a bag	Wastes a lot of time and leads to the mistaken judgment that there is "no attack surface"	First ask the operator for the artifacts; if artifacts are missing, stop and explain
Treating unpacking as the end goal	Reporting completion as soon as the source code is obtained	Unpacking is only the starting point; you must proceed to Phase 2/3
Trusting front-end permission checks	Missing the most important privilege-escalation surface	Treat all front-end validation as untrusted and test the server side
Reporting that "the front end has a role field"	Low-value, unverifiable Finding	Change the value, send the request, and prove privilege escalation using response differences
Testing only read-only interfaces	The impact cannot be clearly explained	Prioritize change-type interfaces and interfaces that move money
Attempting to crack encrypted packages	Out of scope and yields no output	Explain that the operator needs to provide an unpacking environment