Security audit

腾讯营销 datanexus sdk 接入助手

Security checks for vulnerabilities and agentic risk

Overview

This SDK assistant is mostly aligned with its purpose, but it deserves careful review because it can add tracking code and may persist secrets in generated code or plan files.

Install only if you are prepared to review every generated change before applying it. Do not provide production secrets unless you accept that they may appear in generated snippets, plan files, command arguments, IDE logs, or diffs. Before shipping an integration, verify consent gating, privacy disclosures, requested permissions, URL sanitization, identifier handling, and whether auto-tracking is allowed for your app and users.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (27)

Lp3

Medium

Category: MCP Least Privilege
Confidence: 90% confidence
Finding: The skill documents capabilities to read project files, modify code, run local scripts, and call external services, but it declares no permissions boundary or user-visible capability manifest. In a security-sensitive integration assistant, this creates a real risk of unexpected file modification, repository scanning, and outbound data transmission without clear consent or enforcement, especially because the workflow includes automated code edits and network-backed validation steps.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 94% confidence
Finding: The skill's stated purpose focuses on SDK guidance and integration help, but the detected behavior includes querying an external API with an access token and validating remote configuration details that are not clearly disclosed. This mismatch is dangerous because users may provide sensitive credentials or project context expecting local assistance, while the skill may transmit data to a third party without sufficiently informed consent.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The module docstring explicitly states the script does not perform file writes, but the CLI supports `--output` and writes the generated plan JSON to disk. Because the plan embeds sensitive integration material such as `secret_key`, this mismatch can cause operators or upstream agents to treat the tool as non-persistent and inadvertently store credentials in files, logs, or workspaces.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The document instructs implementers to report multiple user lifecycle and monetization events (e.g. startup, registration, login, purchase) and even recommends broad/frequent reporting, but it provides no privacy, consent, minimization, retention, or compliance guidance. In an SDK integration skill, this omission is security- and privacy-relevant because it can directly lead developers to collect and transmit behavioral data without lawful basis, proper notice, or platform-specific compliance controls.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The document explicitly instructs integrators to call `GDTAction.start()` to begin personal information collection, but it does not require any privacy notice, consent flow, or jurisdiction-specific compliance checks before collection begins. In a production Android integration guide, this omission can lead developers to implement automatic collection at app startup without lawful user authorization, creating significant privacy, regulatory, and app-store compliance risk.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The guide recommends sensitive permissions such as `READ_PHONE_STATE` and storage access for attribution optimization, but it frames them as technical options without clearly warning about privacy implications, restricted-platform policies, and user disclosure obligations. This can encourage over-collection of device identifiers and unnecessary permission requests, increasing the risk of noncompliant tracking and user privacy harm.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The FAQ instructs developers to report `open_url` values from URL Scheme and Universal Links directly in analytics events. Deep-link URLs commonly contain sensitive data such as auth tokens, email addresses, campaign parameters, invite codes, or internal routing state, so sending the full URL can leak user data into telemetry systems and downstream logs. In an SDK integration guide, this is more dangerous because developers may copy the example verbatim into production apps at scale.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The documentation actively instructs developers to collect and report a broad set of user behavior events, including registration, login, purchases, sharing, and custom event parameters, but provides no privacy, consent, minimization, or transmission-security guidance. In an SDK integration assistant, this omission is security-relevant because it can lead downstream developers to implement telemetry that violates platform policy, user expectations, or legal requirements and may expose sensitive behavioral data through over-collection.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The CAID interface is documented as a simple retrieval API without any warning that it returns a sensitive device/account-linked identifier requiring careful handling. In this skill context, that is more dangerous because the document is an integration reference for developers, so omission of restrictions can normalize unsafe storage, logging, sharing, or use of the identifier for tracking beyond compliant purposes.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The document instructs implementers to report registration, login, purchase, and related behavioral events to an advertising/attribution SDK, but it does not mention consent, privacy notice, lawful basis, or platform-specific disclosure requirements. In an SDK integration assistant, this omission is security- and privacy-relevant because developers may copy the guidance directly and deploy tracking of sensitive user behavior without adequate user awareness or compliance controls.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The document instructs integrators to use SDK features that automatically collect lifecycle events and include URL wake-up links, but it does not warn about privacy implications, consent requirements, or data minimization. In the context of a production SDK integration guide, this omission can lead developers to deploy tracking behavior without appropriate notice or lawful basis, creating privacy, compliance, and reputational risk.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The guide tells developers to obtain and use a secretKey for SDK initialization but does not identify it as a sensitive credential or provide handling requirements. In an SDK integration context, this increases the chance that developers hardcode, commit, log, or otherwise expose the key, which can enable unauthorized use of the data source, spoofed event submission, or abuse of backend trust relationships.

Missing User Warnings

High

Confidence: 98% confidence
Finding: The guide shows `secret_key` being embedded directly in client-side 微信小游戏 code, which is distributed to end users and can be extracted from packaged assets or runtime memory. Exposing a long-lived secret in a game client can let attackers forge or tamper with telemetry, impersonate the app, abuse backend trust, or compromise any API flows that rely on that secret.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The document states that the SDK automatically collects multiple behavioral events and sends them to a remote DataNexus endpoint, but it does not clearly disclose the scope of data transmission, what identifiers may be included, or the privacy/compliance implications. In an SDK integration guide, this omission is security-relevant because developers may enable telemetry by default without implementing user notice, consent, minimization, or platform-specific compliance checks.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The document instructs implementers to report detailed ecommerce and ad-attribution events such as product views, cart additions, orders, purchases, and refunds, but provides no warning about privacy, user consent, lawful basis, data minimization, or vendor data sharing. In the context of an SDK integration assistant, this omission can directly lead developers to transmit behavioral and purchase data to a third-party provider without appropriate disclosure or compliance controls, creating privacy, regulatory, and trust risks.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The document instructs developers to enable auto-tracking and report events such as app lifecycle and purchase/registration actions, while also configuring persistent user identifiers like openid, unionid, and user_unique_id. It does not clearly disclose that these identifiers and behavior events are transmitted to a remote DataNexus endpoint, which creates a meaningful privacy, compliance, and consent risk for integrators who may deploy tracking without adequate notice or lawful basis.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The documentation shows initializing a client-side mini-program SDK with a `secret_key`, which encourages embedding a sensitive credential directly in distributed application code. In a WeChat mini-program, client code can be recovered or inspected, so exposing a secret allows unauthorized event submission, source impersonation, and abuse of the associated DataNexus account.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The document instructs integrators to collect and set persistent user and device identifiers such as OpenId, UnionId, business user IDs, CAID, and ANID, but it provides no privacy notice, consent, minimization, or compliance guidance. In an SDK integration context, this omission can lead developers to implement tracking in ways that violate platform rules or privacy laws, increasing the risk of unauthorized data collection and regulatory exposure.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The initialization examples require a `secret_key` but do not label it as a sensitive credential or warn against exposing it in client code, logs, repositories, or generated snippets. In this skill's context, which helps users auto-generate SDK integration code, that omission is especially dangerous because developers may hardcode the secret into mobile, mini-program, or game clients where it can be extracted and abused.

Missing User Warnings

Medium

Confidence: 87% confidence
Finding: The FAQ explicitly explains how to start data collection and confirm network reporting, but it omits any privacy notice, consent guidance, or warning that telemetry may transmit user/device data off-device. In an SDK integration assistant focused on automated instrumentation, this omission can lead developers to enable collection by default without implementing required disclosure and consent flows, creating compliance and privacy risk.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The FAQ recommends using OAID and mentions the APP_TRACKING_CONSENT permission, but it does not clearly warn that device identifiers are sensitive tracking data and may require informed consent, limited use, and jurisdiction-specific handling. Because this skill is an SDK integration guide, developers may treat the advice as implementation approval and collect persistent identifiers without proper consent or disclosure.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The document promotes automatic event collection and custom behavior reporting but provides no privacy, consent, or data-minimization guidance. In an SDK integration assistant, this omission can directly lead developers to deploy telemetry that collects user activity without adequate disclosure, lawful basis, or platform-specific compliance controls.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The initialization example requires secret_key and user identifiers but gives no warning about secure credential handling, client-side exposure, or identifier sensitivity. In SDK documentation, this is dangerous because developers may hardcode secrets in app code, leak them in repositories/logs, or misuse persistent identifiers in ways that enable account tracking or backend abuse.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The guide instructs developers to initialize the SDK, grant network-related permissions, and use automatic event collection, but it does not warn that these behaviors may trigger privacy-notice, consent, and data-protection obligations. In an SDK integration assistant, that omission is security-relevant because developers may ship telemetry collection without proper user disclosure or legal basis, creating privacy and compliance risk.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The document says to call start() immediately after init() and emphasizes that delay harms device ID fill rate and attribution success, but it does not warn that this can begin collection before the user has seen or accepted any privacy notice. In this SDK context, that makes the omission more dangerous because the guidance optimizes tracking reliability over user-visible consent controls.

Static analysis

No suspicious patterns detected.