Security audit

建站骨架 (EdgeOne Pages)

Security checks across malware telemetry and agentic risk

Overview

This is a coherent website-building skill, but its deployable auth, payment, admin, and analytics scaffolding has unsafe or under-disclosed behavior that should be reviewed before use.

Install only in a test or review environment until the generated code is hardened. Before using it for a real shop, admin system, or AI service, require real payment signature verification, fail-closed auth middleware, no plaintext password fallback, no token return in JSON for HttpOnly-cookie auth, corrected secret declarations, privacy controls for analytics and AI data, and manual review of migrations, cron jobs, and deployment commands.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (35)

Description-Behavior Mismatch

Medium

Confidence: 95% confidence
Finding: The manifest lists only a subset of secrets, while later sections require additional payment keys, certificates, private keys, and service endpoints. Undeclared secret dependencies undermine review and can lead operators to inject sensitive credentials ad hoc or reuse broader credentials than necessary.

Intent-Code Divergence

Medium

Confidence: 88% confidence
Finding: The document states Edge Functions are 'no secrets', but the same file assigns JWT signing/verification and database-related access patterns to Edge components. This contradiction can cause architects to place sensitive logic in a less appropriate runtime under the false assumption that no secret exposure exists there.

Intent-Code Divergence

High

Confidence: 97% confidence
Finding: The stated boundary says bcrypt and database-backed registration/login belong in Cloud, but the documented Edge login code performs database lookup and bcrypt comparison in Edge. Security boundaries that are documented one way and implemented another are dangerous because reviewers and deployers may apply the wrong controls, exposing credentials or breaking isolation assumptions.

Intent-Code Divergence

Medium

Confidence: 84% confidence
Finding: The retention policy says audit logs live in KV with TTL, while schema and workflow sections describe admin/audit logs in D1. Inconsistent logging and retention documentation can lead to compliance failures, unexpected long-term storage of sensitive events, or premature deletion of records relied on for forensics.

Intent-Code Divergence

High

Confidence: 99% confidence
Finding: The upload helper claims to support multipart/form-data, but request() always applies JSON.stringify to any truthy body and sets Content-Type to application/json. When passed FormData, the payload will be corrupted and the browser will not generate the multipart boundary, causing uploads to fail or behave unpredictably; in a website-building skill that may handle admin/media uploads, this can break security-relevant workflows such as content moderation or document submission.

Intent-Code Divergence

Medium

Confidence: 90% confidence
Finding: The code and documentation create a misleading security model: it claims authentication relies on HttpOnly cookies, yet authenticated user/session-related state is also persisted in localStorage. While no token is stored here, localStorage is readable by any injected script, so cached identity/session data can be exposed or manipulated during XSS and can cause the UI to treat a stale or attacker-influenced local state as authenticated.

Intent-Code Divergence

Medium

Confidence: 96% confidence
Finding: The database call result is used as if it were a resolved order object, but `queryOne(...)` is not awaited. If `queryOne` is asynchronous, `order` will be a Promise, causing the existence check to behave incorrectly and the response to read properties from an unresolved object, which can break authorization-linked order lookup and return incorrect data or server errors. In a payment-order query endpoint, this undermines reliable tenant-scoped access control and order status reporting.

Intent-Code Divergence

Medium

Confidence: 92% confidence
Finding: The helper writes incorrect values into the audit log row: the SQL lists columns `(tenant_id, order_id, from_status, to_status, operator, reason)` but the VALUES clause hardcodes `NULL` for `to_status` and then binds the status transition values into later fields, so the log can record the wrong operator/reason and lose the actual destination status. In an order-processing cron job, corrupted audit logs weaken incident response, dispute handling, and forensic review of automated state changes across tenants.

Intent-Code Divergence

Medium

Confidence: 92% confidence
Finding: The seed file inserts demo admin and user accounts while comments disclose likely default plaintext passwords, but the stored hashes are placeholders. In a website scaffolding skill that may be imported and deployed quickly, this contradiction can lead operators to ship predictable credentials or misunderstand that the accounts are unusable until replaced, increasing the chance of insecure production setup.

Intent-Code Divergence

Medium

Confidence: 99% confidence
Finding: The middleware claims to enforce JWT validation, but in reality it unconditionally calls context.next() for both public and non-public paths, so no authentication gate exists at this layer. In a website scaffold that includes e-commerce, admin backends, and AI apps, this can expose protected APIs or administrative routes if downstream handlers assume middleware already authenticated the request.

Intent-Code Divergence

Medium

Confidence: 99% confidence
Finding: The code directly compares the supplied password to a database field named password_hash, and the comment explicitly states this may be plaintext 'for demonstration'. If deployed as written, it enables insecure password storage or verification semantics, making credential compromise far more likely if the database is exposed and bypassing standard password hashing protections. In a website-building skill that may generate production-ready auth flows, this is especially dangerous because insecure demo logic can be copied into real deployments.

Context-Inappropriate Capability

High

Confidence: 97% confidence
Finding: The logout handler accepts a sessionId from the request body and will attempt to delete the corresponding KV-backed session even when no authenticated user is present. If a caller can guess or obtain another user's sessionId, they may force-log out arbitrary sessions across the default tenant, creating an authorization bypass and denial-of-service condition against authenticated users.

Intent-Code Divergence

High

Confidence: 99% confidence
Finding: The function is documented and named as payment verification, but it treats any JSON-parsable request body as valid and returns the attacker-controlled order ID. In a payment callback flow, this allows unauthenticated callers to forge successful payment notifications and potentially mark unpaid orders as paid, causing direct financial loss and order state corruption.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: Although the comment says this is a placeholder, the exported API still presents itself as a usable verification helper and returns valid=true for arbitrary JSON. In a scaffolding skill that generates deployable full-stack sites, placeholder security logic is especially dangerous because downstream code is likely to rely on it in production-like deployments.

Intent-Code Divergence

Medium

Confidence: 93% confidence
Finding: The document shows what appears to be a real personal name and account identifier in a generic `whoami` example. Even if illustrative, publishing identifiable account output can leak internal identity information, encourage copy-paste of real tenant details, and signals weak sanitization practices in deployment docs.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The Edge middleware creates a cloned Request, sets X-User-Id and X-User-Role on it, but then calls context.next() without forwarding the modified request. As a result, downstream handlers may assume authenticated user context is present when it is not, leading to broken authorization logic, fallback-to-insecure behavior, or accidental exposure/modification of data if handlers trust these headers.

Intent-Code Divergence

Medium

Confidence: 90% confidence
Finding: The document defines a strict KV isolation rule requiring keys to be tenant-prefixed, but the payment callback example uses a global key pattern like `order_tenant:{out_trade_no}`. This inconsistency can weaken the isolation model by encouraging developers to store or resolve tenant metadata outside the documented namespace scheme, increasing the risk of cross-tenant lookup confusion, collisions, or unauthorized association of orders to tenants.

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: This is a real security issue because the sample verification function cannot work as written: it accepts only rawBody and mchSecret, but tries to read headers from an undefined request object. In a payment callback flow, broken signature verification often leads developers to either disable verification or implement it incorrectly, which can allow forged payment notifications and unauthorized order state changes.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: `getShardSessionKey()` hashes the tenant into the shard selection but does not include the tenant in the returned KV key, producing keys like `session_shard:<n>:<sessionId>`. This breaks the file’s stated tenant-isolation scheme and can cause cross-tenant key collisions or unintended session overwrite/read if different tenants use the same session ID and land on the same shard. In a website-generation/full-stack skill that supports multi-tenant auth and sessions, this weakens isolation for a security-critical data path.

Vague Triggers

Medium

Confidence: 92% confidence
Finding: The example trigger phrases are extremely broad (e.g. '建站', '做个网站', '创建网站') and overlap heavily with normal user requests, which can cause the skill to activate unintentionally in unrelated contexts. In an agent ecosystem, overbroad triggers expand the skill’s execution surface and may route generic requests into a high-privilege website-generation/deployment workflow without clear user intent.

Vague Triggers

Medium

Confidence: 90% confidence
Finding: The trigger list includes broad everyday phrases such as '建站', '做个网站', and '生成网站', making accidental activation likely. Because this skill can generate code, access secrets, run deployments, and perform database actions, unintended invocation materially increases risk.

Missing User Warnings

Medium

Confidence: 83% confidence
Finding: Writing user profile data to localStorage persists authenticated state data in a browser-accessible store that survives reloads and is exposed to JavaScript. In a website-building/full-stack skill context, generated apps may handle PII such as email, names, roles, or account metadata, so XSS or shared-device access can leak sensitive user information.

Missing User Warnings

Medium

Confidence: 82% confidence
Finding: Updating cached user data in localStorage during session checks continually refreshes potentially sensitive account information in a browser-readable store. This increases the window for disclosure through XSS, browser extensions, or other local access and can normalize reliance on client-side cached identity data instead of authoritative server validation.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: This analytics helper sends persistent identifiers (userId, sessionId/anonymous ID) together with URL path, referrer, language, screen width, and event-specific business data to a backend endpoint automatically. In a website-building skill that may generate e-commerce, auth, and AI customer-service sites, this creates privacy and compliance risk because tracking can occur without any consent gate, disclosure mechanism, data minimization, or restrictions on what callers pass in properties.

Missing User Warnings

Medium

Confidence: 82% confidence
Finding: The stats example returns recent order records including user email addresses to both 'admin' and 'manager' roles, even though broad operational statistics may not require direct access to customer PII. In a site-generation skill, this pattern can be copied verbatim into production scaffolding, causing unnecessary exposure of personal data to more users than needed and increasing privacy/compliance risk.

VirusTotal

VirusTotal findings are pending for this skill version.

View on VirusTotal

Static analysis

Detected: suspicious.dangerous_exec, suspicious.env_credential_access, suspicious.exposed_secret_literal

Shell command execution detected (child_process).

Critical

Code: suspicious.dangerous_exec
Location: scripts/migrate.js:168

Environment variable access combined with network send.

Critical

Code: suspicious.env_credential_access
Location: tests/integration/phase4a.test.js:14

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: client/src/pages/login.js:59

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: client/src/pages/register.js:66

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: tests/sharing/validators.test.js:330