Supabase Complete Documentation

Security checks across malware telemetry and agentic risk

Overview

This is a static Supabase documentation skill, not malware, but several examples could lead to insecure setups if copied without careful review.

Install only if you want a broad Supabase docs reference and your agent will treat snippets as examples, not commands to run automatically. Before applying any guidance from it, especially around service-role keys, RLS policies, OAuth redirects, logging, database roles, credentials, or AI provider integrations, verify the snippet against current Supabase docs and your own security requirements.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (152)

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: This is a real security-relevant documentation flaw: the example table defines `last_failed_at`, but the function writes to `last_refreshed_at`, which does not exist in the schema. Users who copy this example will get a broken hook or will silently fail to record failed attempts, defeating the intended MFA rate limiting and allowing repeated brute-force verification attempts. In an authentication hook example, incorrect security logic is especially dangerous because readers are likely to deploy it as-is to protect MFA flows.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: The migration example is security-relevant documentation, and it claims to set up both row-level and column-level protections but only shows a revoke on one column privilege. A reader following it may believe column restrictions are fully configured when they are not, leaving broader update access or a broken/partial privilege model depending on prior grants.

Intent-Code Divergence

Low

Confidence: 89% confidence
Finding: The label 'Add column-level security' overstates what the SQL actually does, since the snippet only revokes one column privilege and does not demonstrate the complete privilege configuration described earlier. Misleading security guidance can cause operators to deploy incomplete controls while assuming sensitive columns are protected.

Intent-Code Divergence

Medium

Confidence: 96% confidence
Finding: This documentation is incorrect: with PostgreSQL `DISTINCT ON (team)`, the `ORDER BY` must begin with `team` and then sort the desired winner row first, but the shown query orders by `id, points desc, team`, which causes selection based primarily on the lowest `id` rather than the maximum `points` per team. Users who copy this query may get silently wrong results in application logic, analytics, or access-control-related SQL workflows, making the issue security-relevant because it can drive unsafe decisions from bad data.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The example comments say the function is using the public anon key, but the code actually initializes the client with SUPABASE_SERVICE_ROLE_KEY, which has elevated privileges and bypasses normal client-side access controls. This kind of misleading documentation can cause developers to expose or misuse a highly privileged key in request-handling code, increasing the blast radius if the function is abused or later modified insecurely.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: This documentation recommends converting all request headers to JSON and logging them, and the included example output explicitly contains sensitive values such as an Authorization bearer token and internal-looking forwarded headers. In a logging guide, readers are likely to copy this pattern directly into production debugging code, which can leak credentials into logs, dashboards, terminals, or downstream log processors.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The tutorial explicitly discusses storing a publishable key and URL, but the Gradle example also loads a generic SECRET into BuildConfig. On Android, BuildConfig values are compiled into the client app and can be extracted from the APK, so encouraging any secret to be embedded client-side can lead to credential exposure and backend compromise if a service-role or other privileged secret is used.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The documented schema defines `public.rooms_users(room_topic)` and `public.rooms(topic)`, but the broadcast example queries `rooms_users` with `and topic = (select realtime.topic())`, which does not match the declared schema. If users copy this policy as written, authorization may fail outright or be rewritten ad hoc, causing developers to deploy incorrect channel access controls that do not reflect the intended membership check.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The presence write example uses `and name = (select realtime.topic())`, but the documented relationship table does not define a `name` column and earlier examples use topic-based matching. This mismatch can cause policy creation failures or lead developers to substitute the wrong field, weakening or breaking presence authorization and potentially allowing unintended publish behavior if a broader fallback policy is used.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The combined broadcast/presence write policy repeats the incorrect `name` field instead of the schema's topic reference, so the example does not enforce the intended topic-based authorization model. In an authorization guide, such inconsistencies are especially risky because readers are likely to paste these policies into production, resulting in broken access control or improvised fixes that may over-permit channel writes.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The document claims that `select pg_notification_queue_usage();` refreshes the Postgres notification queue and prompts PostgREST to reload its schema cache, but that SQL function only reports queue usage and does not perform a refresh. Misstating the behavior of a troubleshooting command can mislead operators into believing a remediation occurred when it did not, delaying correct recovery and potentially prolonging API/schema inconsistencies.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The document claims a dedicated Prisma role is safer because it can access only the needed objects, but the provided SQL creates a role with `bypassrls`, `createdb`, broad schema privileges, and `all` privileges on all tables, routines, and sequences in `public`. This materially contradicts least-privilege guidance and could lead users to deploy an application or migration role that can bypass row-level security, create databases, and fully control schema objects, expanding blast radius if credentials are leaked or Prisma is compromised.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The examples instruct users to place a raw PostgreSQL connection string directly into MCP server configuration without warning that the string commonly embeds usernames, passwords, host details, and other sensitive database credentials. In documentation context, this can lead users to hardcode secrets into config files, logs, screenshots, version control, or shared workstation settings, increasing the likelihood of credential exposure and downstream database compromise.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: Several framework snippets redirect to a `next` query parameter after OAuth code exchange without consistently validating that it is a safe relative path. In Astro and Remix, `redirect(next)` will accept attacker-controlled values and can enable open redirects or phishing flows; the Express example forces a leading slash but still lacks an explicit warning and uses a raw user-controlled path segment. Because this is authentication callback documentation, developers are likely to copy it directly into production, increasing the chance of insecure post-login redirects.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The documentation explicitly instructs users to create an RLS policy granting SELECT access to the anon role with `using (true)`, which makes the table publicly readable to anyone with access to the API. In a quickstart context this may be intentional for demo data, but without a clear warning that this exposes data publicly and should not be used for sensitive tables, it can lead users to replicate unsafe access patterns in production.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The guide instructs users to send document content to OpenAI for embedding generation but does not prominently warn that row content may contain sensitive, regulated, or proprietary data that will leave the database boundary. In documentation used as an implementation template, this omission can lead developers to deploy a data flow that unintentionally exports private content to a third-party provider without appropriate consent, data classification, or compliance review.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The documentation includes an SQL example with inline database credentials, including a literal password value, without clearly warning readers that this is placeholder data and must not be copied into production or committed to source control. In documentation aimed at operational scaling and database connectivity, this can normalize unsafe secret-handling practices and lead users to hardcode real credentials in scripts, migrations, or repos.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The guide instructs users to export highly sensitive credentials, including an OpenAI API key and a Supabase service-role key, but does not warn that these secrets grant broad access and must never be committed, logged, shared, or exposed client-side. In documentation, omission of basic secret-handling guidance can lead to credential leakage and downstream compromise of data, billing, or administrative capabilities.

Missing User Warnings

Medium

Confidence: 84% confidence
Finding: The document-upload step tells users to POST a file to the plugin without clearly warning that the file contents will be sent through the embedding pipeline and stored in the backing datastore. Users may unknowingly upload sensitive, regulated, or proprietary material, causing unintended disclosure to third-party AI services and persistence in storage systems.

Missing User Warnings

Medium

Confidence: 81% confidence
Finding: The documentation tells users to store highly sensitive credentials, including a Supabase service-role key and OpenAI API key, but does not clearly warn that these secrets grant privileged access and must never be exposed to client-side code, logs, or untrusted workflows. In a docs example, readers often copy-paste configurations directly, so the lack of handling guidance increases the chance of secret leakage or misuse.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The example uploads image contents to the Hugging Face Inference API, which is a third-party service, but the documentation does not warn users that uploaded images may leave the Supabase environment. This can create an inadvertent privacy and compliance issue if developers process sensitive, personal, or regulated images without informed consent, notice, or data-handling review.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The guide instructs users to send video content and text queries to Mixpeek, a third-party external service, without explicitly warning about data transfer, privacy, retention, or consent implications. In the AI/video-search context, users may process sensitive or copyrighted video data, so omission of a clear disclosure can lead to unintended exposure of regulated or confidential content.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The tutorial tells users to place a service-role key and OpenAI API key in environment variables for a build-time embeddings script, but it does not clearly warn that the script will transmit local documentation content to OpenAI. This creates a real data-handling risk because users may unknowingly send proprietary or sensitive content to a third party during builds.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The guide explicitly shows AWS access key, secret key, and session token fields being hardcoded into application code. Even though the values are placeholders, documentation patterns like this commonly lead users to paste real credentials into source files, which can then be leaked through git commits, logs, screenshots, or shared codebases. In a documentation skill for developers, this is more dangerous because readers are likely to copy the snippet verbatim into real projects.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The tutorial instructs users to paste a full Postgres connection string containing an embedded password directly into a Colab notebook. In a hosted notebook environment, secrets can be exposed through saved notebooks, shared links, output history, screenshots, or collaboration features, increasing the chance of credential leakage and unauthorized database access.

VirusTotal

62/62 vendors flagged this skill as clean.

View on VirusTotal