Drizzle ORM Complete Documentation

• Outcome: Pass
• Latest audit: May 28, 2026 at 8:46 AM UTC
• Version:
  0.1.0

Overview

This is a documentation-only Drizzle ORM skill with some risky example snippets, but no hidden execution, persistence, or data collection was found.

Install if you want local Drizzle ORM documentation available to your agent. Before running or copying snippets, verify the target is a development database, protect secrets with environment variables or a secret manager, keep Studio/proxy services on localhost unless secured, review migrations before applying them, and avoid raw SQL with user-controlled input.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• 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

Findings (32)

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: This example builds a SQL statement for `set local nile.tenant_id` using `sql.raw(tenantId)` even though the tenant value may come from request data. That defeats query parameterization and can allow SQL injection into a security-sensitive session/transaction setting that controls tenant isolation, creating a risk of cross-tenant data access or broader query manipulation.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The AsyncLocalStorage example again inserts request-derived tenant context into SQL via `sql.raw(tenantId)`. Because this code is specifically presented for web middleware and per-request tenancy, it encourages a pattern where attacker-controlled path data can reach raw SQL in the mechanism enforcing tenant scoping, undermining isolation guarantees.

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: This section appears to reverse or contradict earlier guidance about where v1 versus v2 relation imports should come from. In a migration guide, incorrect import paths can cause users to wire up the wrong API surface, accidentally keep legacy behavior, or introduce build/runtime failures that undermine confidence in database access logic.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The documentation appears to invert the meaning of `db.query` and `db._query` relative to the rest of the file. Users following the wrong accessor guidance during migration may execute the wrong query API, leading to broken filtering semantics, subtle logic errors, or failed production deploys in code that handles database reads.

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The README states the skill 'triggers automatically' for broad topics like database schemas, queries, migrations, and cloud database integrations. Because these are common topics, the skill may activate in many unrelated database contexts and inject large volumes of documentation or influence agent behavior when not specifically requested. In a documentation skill this is not code-execution dangerous by itself, but it can cause unintended routing, prompt-context pollution, and reduced reliability of security-sensitive or task-specific workflows.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The example posts raw SQL text and parameters to `http://localhost:3000/query` without any warning that plaintext HTTP can expose queries, schema details, secrets, and user data in transit if adapted beyond local development. Because this is documentation for building a proxy layer, readers may copy the pattern into real deployments, making the omission security-relevant even though the sample is instructional.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The batch proxy example also sends SQL statements and parameters over plain HTTP with no warning about confidentiality or integrity risks. Batch mode can amplify exposure because multiple queries and result sets may be transmitted in a single request, increasing potential leakage if traffic is intercepted or the endpoint is misused.

Missing User Warnings

Low

• Confidence: 84% confidence
• Finding: The example logs tenant IDs derived from request paths and transaction context. Tenant identifiers may be sensitive in multi-tenant systems because logs are often broadly accessible and can expose customer metadata, internal identifiers, or aid reconnaissance; the risk is increased here because the skill is specifically about multi-tenant database access.

Missing User Warnings

Low

• Confidence: 90% confidence
• Finding: The documentation shows multiple database credential examples directly inside configuration objects, including URLs, usernames, passwords, tokens, and ARNs, without warning readers not to hardcode real secrets. In a documentation skill, users may copy these patterns verbatim into source-controlled config files, increasing the chance of accidental credential exposure.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The documentation normalizes passing database credentials directly in config files and CLI arguments, including URLs with embedded usernames/passwords and examples of API tokens. In a documentation skill, this is dangerous because users may copy these patterns into shell history, source control, CI logs, or shared config files, leading to accidental credential exposure.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The documentation explicitly promotes `drizzle-kit push` as applying generated schema changes directly to a live database, but the nearby warning language is weak and does not clearly call out irreversible or destructive outcomes such as dropped columns, dropped tables, or unintended production data loss. In documentation for a tool that can mutate production databases, omission of strong safety guidance materially increases the chance of unsafe operator behavior.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The documentation explicitly shows binding Drizzle Studio to 0.0.0.0, which exposes the service on all network interfaces, but does not warn that this makes the local database browser reachable from other machines if network paths exist. In the context of a tool that connects to real databases and provides a browsing UI, this can lead to unintended remote access and database metadata or data exposure during development.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The verbose flag is documented as logging every SQL statement without warning that logs may contain sensitive queries, literal values, schema details, or personal data depending on application behavior and driver configuration. In development and CI environments, such logs are often collected or shared, increasing the risk of unintended disclosure.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The example app unconditionally executes `await db.delete(usersTable);` during startup after migrations succeed, which wipes all rows from the table every time the effect runs. In a getting-started guide, readers often copy code verbatim, so this can cause unintended data loss in development or any environment where the snippet is reused without modification.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The example app unconditionally executes `await db.delete(usersTable);` before inserting sample data, which destroys all rows in the table every time the effect runs after migrations succeed. In a getting-started guide, readers may copy this code into real apps, causing accidental data loss without any warning, guardrail, or indication that this is demo-only behavior.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The documentation tells users to place a live database connection string containing credentials into a `.env` file, but it does not warn them to keep that file out of version control or otherwise protect it. In a getting-started guide, this omission can lead users to accidentally commit database secrets, exposing unauthorized access to the PlanetScale Postgres instance.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The documentation instructs users to store a live DATABASE_URL containing credentials in a .env file, but it does not warn them to keep that file out of source control or otherwise protect it. In onboarding/get-started docs, this omission can lead users to accidentally commit secrets, exposing database access and enabling unauthorized access or data compromise.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The documentation tells users to store a live Turso auth token in a `.env` file but does not warn that the token is sensitive, should not be committed, and should be protected via `.gitignore` or a secret manager. In tutorial contexts, users often copy instructions verbatim, so omission of secret-handling guidance materially increases the risk of accidental credential exposure and subsequent unauthorized database access.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The example code performs insert, update, and delete operations against a real Vercel Postgres connection without an explicit warning that it will modify live data if run as-is. In documentation for getting started with an existing project, users may copy-paste directly into connected environments, so this can unintentionally alter or remove real records.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The follow-up example again inserts, updates, and deletes records on the configured database, but does not clearly warn that executing it will mutate actual data. Because this appears in setup documentation for an existing project, the surrounding context increases the chance that users run it against production-like environments.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The guide includes a concrete root password (`mypassword`) and then reuses it in the sample connection string without clearly warning readers that the credential is only an example and must be changed. In documentation, users often copy commands verbatim, so this encourages weak/default credential reuse on an exposed MySQL service, increasing the risk of unauthorized local or network access.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The guide sends input text to OpenAI's embeddings API, which transmits user-provided content to a third-party service. In documentation context this is not inherently malicious, but omitting any warning about external data transfer, privacy, retention, or consent can lead developers to embed sensitive or regulated data and unintentionally exfiltrate it outside their trust boundary.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: This documentation explicitly demonstrates `sql.raw()` producing unparameterized SQL and contrasts it with the safe parameterized form, but it does not include a clear warning that interpolating untrusted input into `sql.raw()` can lead to SQL injection. In a documentation skill, example code is often copied directly into production code, so showing raw SQL emission without an adjacent safety caveat can normalize unsafe usage and increase misuse risk.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The tutorial defines a public `/user` edge route that performs `db.select().from(usersTable)` and returns the full result set as JSON, with no authentication, authorization, filtering, or warning that this exposes database records to anyone who can reach the deployed site. In tutorial context this is likely meant as a minimal example, but readers may copy it into real deployments, turning it into an unintended public data disclosure endpoint.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The example creates a publicly reachable `/user` endpoint that performs `db.select().from(usersTable)` and returns all rows as JSON without authentication, authorization, filtering, or any privacy warning. In a real deployment, adapting this sample to production could expose user records, including emails and other personal data, to anyone who can access the route.

VirusTotal

66/66 vendors flagged this skill as clean.