Web 开发 · CloudBase Web Development

• Outcome: Review
• Latest audit: Sep 30, 2026 · 2:03 PM UTC
• Version: 1.27.58

Overview

The skill is mostly coherent web-development guidance, but its authentication examples could lead agents to generate protected routes that accept unverified tokens.

Review this skill carefully before installing if you expect it to generate authentication code. The package does not appear to execute hidden code, but its auth examples should be corrected to use authoritative server-side token or session verification and secure cookie/session handling before being trusted for production work.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: frameworks.md:65

Finding

Next.js protected-route template accepts an unverified authentication cookie

Content

View full analysis

Vulnerability Details

File Location: frameworks.md, lines 65–70
Vulnerability Type: Authentication bypass through missing token verification
Risk Level: High

Vulnerable code:

ts

const token = request.cookies.get("cloudbase_token")?.value
if (!token) {
  return NextResponse.json({ error: "Unauthorized" }, { status: 401 })
}
// Verify token with Node SDK or forward to your backend
return NextResponse.json({ data: "protected resource" })

Technical Analysis

The documented Next.js route checks only whether the cloudbase_token cookie contains a non-empty value. Although a comment says to verify the token, the shown execution path performs no cryptographic signature, issuer, audience, expiration, session, or revocation validation before returning protected data.

Because HTTP cookies are controlled by the requesting client, the existence check cannot establish an authenticated identity. A coding agent following this template could generate a purportedly protected API route in which arbitrary remote clients are treated as authenticated.

The trust boundary is crossed when an attacker-controlled cookie is accepted by server-side authorization logic without authoritative verification.

Attack Path

1. A developer or coding agent implements a protected Next.js route using the documented template.
2. A remote attacker sends a request to that route with any non-empty cookie, for example cloudbase_token=invalid.
3. The route passes the presence check because the cookie exists.
4. No token-verification operation is performed.
5. The route returns the protected response to the unauthenticated attacker.

Impact Assessment

An attacker can bypass authentication for endpoints implemented using this pattern. The resulting privileges depend on the operations placed behind the route and may include unauthorized access to application data or invocation of authenticated state-changing actions ...[truncated 107 chars]

Remediation

View remediation

Remediation Suggestions

• Replace the cookie-presence check with an authoritative server-side token or session verification operation.
• Validate the token signature, issuer, audience, expiration, and required scopes or claims.
• Check session revocation where the authentication platform supports it.
• Derive the request identity exclusively from verified claims rather than from the raw token.
• Fail closed when verification is unavailable, returns an error, or produces an invalid result.
• Replace the current example with a complete secure implementation; do not represent a verification comment as an implemented security control.
• Add tests proving that missing, malformed, forged, expired, and incorrectly issued tokens receive an unauthorized response.

T09 · Insecure Skill Coding Practices

Error

• Location: frameworks.md:136

Finding

NestJS authentication guard authorizes arbitrary bearer-token values

Content

View full analysis

Vulnerability Details

File Location: frameworks.md, lines 136–145
Vulnerability Type: Authentication bypass through unconditional authorization
Risk Level: High

Vulnerable code:

ts

const token = request.headers.authorization?.replace("Bearer ", "")
if (!token) return false

try {
  // Verify the session via Node SDK
  // Note: Node SDK does not have a direct "verify token" method —
  // forward the token to a cloud function or use the HTTP API for validation
  request.user = { token }
  return true
} catch {
  return false
}

Technical Analysis

The documented NestJS guard extracts an attacker-controlled Authorization header and accepts every non-empty result. The try block contains no verification operation capable of throwing or rejecting an invalid token. It assigns the unverified token to request.user and unconditionally returns true.

The use of replace("Bearer ", "") also does not strictly enforce the Bearer authentication scheme. Nevertheless, the primary security failure is that no token or session verification occurs at all.

This promotes untrusted network input to an authenticated request identity and crosses the application’s authentication boundary without proving the requester’s identity.

Attack Path

1. A NestJS application adopts the documented CloudBaseAuthGuard.
2. A remote attacker requests an endpoint protected by that guard.
3. The attacker supplies any non-empty Authorization value, such as Bearer forged-token.
4. The guard stores the forged value in request.user.
5. Since no verification operation runs, execution reaches return true.
6. NestJS grants access to the protected endpoint as though authentication had succeeded.

Impact Assessment

This permits complete authentication bypass for endpoints protected by the documented guard. Depending on those endpoints, an unauthenticated attacker could read protected records, ...[truncated 296 chars]

Remediation

View remediation

Remediation Suggestions

• Strictly parse the Authorization header and reject values that do not use the expected Bearer scheme.
• Send the token to an authoritative CloudBase backend or documented verification endpoint before authorizing the request.
• Validate signature or session authenticity, issuer, audience, expiration, revocation status, and required authorization claims.
• Populate request.user only with identity and authorization claims returned by successful verification; never store an unverified token as the user identity.
• Return false or throw an unauthorized exception for malformed tokens, verification failures, timeouts, or unavailable verification services.
• Replace the placeholder guard with a complete, fail-closed example.
• Add tests confirming rejection of arbitrary strings, malformed headers, forged tokens, expired tokens, and tokens issued for another environment or audience.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Intent-Code Divergence

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

This is a true vulnerability. The NestJS AuthGuard example claims to verify tokens, but the implementation only checks for the presence of a Bearer token, stores it on request.user, and returns true without any cryptographic or backend validation. In a web-development skill, this is especially dangerous because readers are likely to copy the guard into production code, resulting in complete authentication bypass for any protected endpoint.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

This is a real security weakness in the guidance. The React/Next.js example writes an access token into document.cookie from client-side JavaScript, which means it cannot be marked HttpOnly and may be exposed to XSS, browser extensions, or other client-side script access. In the context of a web-development skill, this is more dangerous because it presents the pattern as a recommended auth flow for API route protection, encouraging insecure token handling by default.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.