Supabase DDoS protection via Cloudflare
Supabase protects against Distributed Denial of Service (DDoS) attacks at the edge through Cloudflare.
platform
492 notes in this subject, read out of this brain and free to use. This is page 8 of 9.
Supabase fail2ban abuse prevention
At the infrastructure layer, fail2ban blocks IP addresses after repeated log-detected abuse, such as failed authentication attempts.
Data residency with region selection
Each Supabase project is deployed to a single primary region. The project's primary Postgres database, Auth service, and Storage objects are hosted in that region. Choosing a specific region within the EU pins these services to that exact AWS region.
Data Processing Agreement (DPA)
Supabase provides a Data Processing Agreement (DPA) for applications that need a formal data processing contract under GDPR. The DPA can be requested or viewed at the legal section.
Region selection alone does not ensure GDPR compliance
Choosing a region is a data-location control and does not make an application GDPR compliant on its own. Backups, logs, data exported to external systems, Edge Function execution, and sub-processors can affect data residency and international transfer analysis.
EU region selection for GDPR
If compliance requirements call for data to stay within the EU specifically, choose a specific EU region rather than the general Europe grouping. The general Europe region grouping includes London (UK) and Zurich (Switzerland), which have GDPR-adequacy data protection regimes but are not EU member states.
GDPR compliance is shared responsibility
Building GDPR-compliant applications on Supabase is a shared responsibility. Supabase secures the underlying infrastructure, while the application owner is responsible for data processing activities, consent flows, and access controls.
Queue types in Supabase Queues
Supabase Queues offers two types: Basic Queue, which is durable and stores Messages in a logged table, and Unlogged Queue, which is transient, stores Messages in an unlogged table for better performance but may result in loss of Queue Messages.
Supabase Queues pull-based architecture
Supabase Queues is a pull-based Message Queue where consumers actively fetch Messages when they're ready to process them. Messages are processed in First-In-First-Out (FIFO) order without priority levels.
Queues not exposed to client-side by default
Queues are not exposed over the Supabase Data API by default and are only accessible via Postgres clients.
Exposing Queues via PostgREST
To expose Queues to client-side consumers via the Data API, navigate to Queues > Settings in the Dashboard and enable 'Expose Queues via PostgREST'. This creates and exposes a pgmq_public schema containing database function wrappers to a subset of pgmq database functions, preventing direct access to the pgmq schema.
Queue naming restrictions
Queue names can only be lowercase, and hyphens and underscores are permitted.
Audit Log Drains configuration
Audit Log Drains can be configured under the organization's audit log drains section at /dashboard/org/_/audit-log-drains to stream logs to external destinations. Setup instructions and supported destinations are documented in the Log Drains guide.
Where to access Platform Audit Logs
Platform Audit Logs can be accessed in the organization's audit logs dashboard section at /dashboard/org/_/audit, where each log entry can be clicked to view additional details.
Account Audit Logs
Each Supabase user account has access to Account Audit logs at /dashboard/account/audit which displays logs for only the associated user account.
Platform Audit Logs limitations
There is currently no way to export the logs via dashboard. Retention periods depend on your plan.
Platform Audit Logs availability
Platform Audit Logs are only available on the Team and Enterprise plans.
What gets logged in Platform Audit Logs
Any Platform API or dashboard actions performed by organization members are logged automatically for auditing and security purposes. This includes actions such as creating a new project, inviting members, modifying an edge function, or changing project settings.
Platform Audit Logs details captured
For each audit log entry, the system captures: timestamp of action, actor who performed the action (IP address, email, token type), action performed (name, metadata such as route and response status), and action target (Project, organization, Edge Function, etc.).
Network restrictions in Supabase projects
Each Supabase project comes with configurable restrictions on IP ranges allowed to connect to Postgres and its pooler. These restrictions are enforced before traffic reaches the database. A connection still requires authentication with valid database credentials even if not restricted by IP.
Enforce MFA on Supabase organizations
Organization owners can enforce multi-factor authentication (MFA) for all team members in Supabase. This security control is configured in the organization security settings.
Security controls available in Supabase organizations
The Supabase hosted platform provides secure-by-default configuration. Additional security controls are available under the security tab for organizations. Available controls include: enforce multi-factor authentication (MFA) for all team members, single sign-on (SSO) for organizations, Postgres SSL enforcement, network restrictions on IP ranges allowed to connect to Postgres and its pooler, and PrivateLink for private network connectivity.
Supply chain monitoring: Dependabot and GitHub Advisory Database
Enable Dependabot alerts on every repository with a lockfile (free for public and private repos). It checks the lockfile against the GitHub Advisory Database and alerts when a transitive becomes a known-vulnerable version. Subscribe to the GitHub Advisory Database RSS feed (filter by npm ecosystem) for ambient awareness of new advisories. Run npm audit / pnpm audit on schedule as a non-blocking CI job to treat it as a notifier, not a gate (audit is noisy; a blocking gate trains people to ignore it).
packageManager field pinning with sha512 hash
Pin the package manager itself in package.json with the packageManager field and a sha512 hash to prevent drift between local dev and CI. Example: "packageManager": "pnpm@10.0.0+sha512.<hash>". Corepack (bundled with modern Node) and pnpm/action-setup@v6+ both read this field automatically. A compromised npm mirror serving a tampered pnpm binary fails the hash check instead of running.
yarn approvedGitRepositories for git source control
Use approvedGitRepositories array in .yarnrc.yml to allowlist specific git sources. Any git reference not matching the list is rejected. Example: approvedGitRepositories: ['https://github.com/yarnpkg/*', 'ssh://git@github.com/yarnpkg/*'].
npm allow-git, allow-remote, allow-file, allow-directory settings
In .npmrc, set allow-git, allow-remote, allow-file, and allow-directory each to 'all' (default), 'none', or 'root'. 'root' means allow that kind of reference only if declared in your own package.json, never as a transitive dependency. Example: allow-git=root, allow-remote=root, allow-file=root, allow-directory=root. This enforces the trust boundary you want: direct references are trusted, transitive are not.
pnpm blockExoticSubdeps setting
Set blockExoticSubdeps: true in pnpm-workspace.yaml to refuse transitive dependencies that resolve to non-registry sources (e.g., github:, git+, file: refs). These bypass npm registry signing, provenance, and quarantine guarantees entirely.
npm and bun lifecycle script control
npm and bun should install with --ignore-scripts flag by default, then explicitly enable scripts only for packages that truly need them. This is the safest approach. preinstall, postinstall, and prepare scripts are the single most common code-execution entry point in a compromised dependency.
pnpm allowBuilds lifecycle script control
Declare an allowlist in pnpm-workspace.yaml to control which packages may run preinstall, postinstall, and prepare lifecycle scripts. Example: allowBuilds: { esbuild: false, simple-git-hooks: true }. The goal is default-deny; add packages only when their build genuinely needs to run. @supabase core packages run no install/postinstall scripts and can safely remain on the deny list.
npm audit signatures for provenance verification
Run npm audit signatures after installing @supabase/supabase-js, @supabase/auth-js, @supabase/postgrest-js, @supabase/realtime-js, @supabase/storage-js, and @supabase/functions-js to verify sigstore provenance attestations. These attestations cryptographically tie each published tarball to the workflow run, commit, and repository it was built from. A valid Supabase attestation always resolves to a repository under the supabase GitHub organisation. If npm audit signatures reports a verified attestation pointing anywhere else for an @supabase/* package, treat it as a red flag. A failure is a strong signal that the registry mirror is tampered with or the tarball was modified after publish. Use a recent npm CLI version (bundled Node.js version can lag); install latest with npm install -g npm@latest.
npm security: commit lockfile and install frozen
In CI environments, use npm ci (npm), pnpm install --frozen-lockfile (pnpm), yarn install --immutable (yarn), or bun install --frozen-lockfile (bun) to install from a committed lockfile. These commands fail if package.json and the lockfile disagree. This is the foundational defense against supply-chain attacks via npm installs.
npm security: minimum release age quarantine
Set a minimum release age gate to prevent installation of newly-published package versions. This is the single highest-leverage defense, as most npm compromises are detected and remediated within hours. pnpm v11 defaults to 1440 minutes (1 day) and can be configured higher in pnpm-workspace.yaml with minimumReleaseAge (in minutes). npm uses min-release-age config (in days). yarn uses npmMinimalAgeGate in .yarnrc.yml (format like '7d'). bun uses --minimum-release-age flag (in seconds) or bunfig.toml setting. Typical recommended value is 7 days (10080 minutes for pnpm, 7 for npm, '7d' for yarn, 604800 seconds for bun).
pnpm minimumReleaseAge configuration
In pnpm-workspace.yaml at repo root, set minimumReleaseAge in minutes (default 1440 = 1 day in pnpm v11). Example: minimumReleaseAge: 10080 (7 days). Use minimumReleaseAgeExclude array to bypass for specific packages, e.g., @your-org/* for internal packages. Set to 0 only if explicitly opting out.
pnpm trustPolicy setting for provenance verification
Configure trustPolicy: no-downgrade in pnpm-workspace.yaml to refuse installing a version whose trust level (trusted publisher → provenance → none) has dropped relative to previous releases of the same package. This catches cases where an attacker can publish but cannot replicate the original maintainer's OIDC binding. Optional trustPolicyExclude array lists specific packages to opt out. Optional trustPolicyIgnoreAfter (e.g., '180d') ignores checks for packages older than that duration.
yarn berry v4+ minimum age and script settings
In .yarnrc.yml, set npmMinimalAgeGate: '7d' to quarantine new versions. Use npmPreapprovedPackages array to opt specific packages out of all gates, e.g., @your-org/*. yarn defaults enableScripts: false (postinstall scripts from third-party packages do not run; workspaces still run their own). enableHardenedMode: true makes yarn re-query remote registries to confirm lockfile content matches current registry state (auto-on for GitHub PRs from public repos; worth turning on for slower but safer installs).
npm min-release-age configuration
Set min-release-age config in .npmrc (relative, in days) or use before config for absolute date. Example: min-release-age=7. Can also pass per-command: npm install --min-release-age=7. If min-release-age is unavailable in older npm versions, fall back to a private mirror or a CI gate that calls npm view <pkg>@<version> time.<version> and rejects installs newer than N days.
bun minimum release age configuration
Use --minimum-release-age flag (in seconds) per-command, or set once in bunfig.toml under [install] section as minimumReleaseAge (in seconds). Example: minimumReleaseAge = 604800 (7 days). Use minimumReleaseAgeExcludes array for trusted packages like @types/node or typescript. Bun's age gate only affects new resolutions; existing entries in bun.lock remain unchanged. Bun runs a stability check: if multiple versions published close together outside the gate, it skips those likely-unstable versions and picks an older one. Exact-version requests (pkg@1.1.1) respect the gate but bypass the stability extension.
npm overrides for transitive dependency pinning
Use the overrides field in package.json (npm and pnpm) or resolutions field (yarn) to force a known-good version of a transitive dependency. Example (npm/pnpm): "overrides": { "some-dep": "1.2.3" }. Example (yarn): "resolutions": { "some-dep": "1.2.3" }. This is the lever to reach when a CVE is discovered in a transitive dependency you do not directly depend on.
npx / pnpm dlx / bunx supply chain risk mitigation
Commands like npx, pnpm dlx, and bunx fetch and run packages outside the project's lockfile and outside the minimum-age gate. npx pkg@latest directly fetches against the registry; a fresh malicious version will be installed. Mitigations: (1) pin the version explicitly (npx pkg@1.2.3 instead of npx pkg@latest), or (2) move the tool into devDependencies so it is covered by the lockfile and all supply-chain protections, then invoke it through npm exec / pnpm exec / yarn run. Treat any ad-hoc registry fetch the same as curl … | bash.
Report Supabase security vulnerabilities
To report a vulnerability in Supabase itself, see the Supabase security policy at https://github.com/supabase/supabase-js/security. This differs from the npm install hardening guide, which covers defending against supply-chain attacks on your machines and in CI.
Response plan if compromised npm version installed
If a compromised version is suspected: (1) Treat the install host as potentially compromised; anything readable by the user who ran install (env vars, files, secrets in memory) should be assumed stolen. (2) Rotate credentials reachable from that host: cloud provider keys (AWS, GCP, Azure), Kubernetes/Vault tokens, GitHub tokens, npm tokens, SSH keys, and any Supabase service-role or anon keys that touched the host. (3) Wipe node_modules and package manager cache (npm cache clean --force, pnpm store prune, yarn cache clean). (4) Pin to a known-good version in package.json and reinstall against fresh cache. (5) Check npm audit and GitHub Advisory Database for the package. (6) Report it: file a GitHub Security Advisory on the upstream repo, and email security@npmjs.com if the version can still be installed.
Supabase OIDC trusted publishing and provenance attestations
Supabase publishes @supabase packages using OIDC trusted publishing (no long-lived NPM_TOKEN secrets; each publish authenticated via short-lived OIDC token bound to the release workflow). Every release ships with a sigstore attestation tying the tarball to its source commit and workflow run. Verify with npm audit signatures. Fixed-version monorepo releases: all packages release together with identical versions, so pinning one pins all. Multi-step release approval via GitHub environments: stable publishes from master run inside a protected GitHub environment requiring explicit maintainer approval before the publish job accesses npm OIDC credentials.
Supabase npm packages without postinstall scripts
@supabase core packages (@supabase/supabase-js, @supabase/auth-js, @supabase/postgrest-js, @supabase/realtime-js, @supabase/storage-js, @supabase/functions-js) run no install or postinstall scripts. You can safely install them with --ignore-scripts.
Third-party supply chain scanners: Socket, Snyk, Aikido
Third-party scanners like Socket, Snyk, and Aikido often spot compromises faster than the GitHub Security Advisory feed. No specific endorsement; if your org has a license, plug it in. Evaluate based on detection time on past incidents, not feature lists.
CI lockfile hygiene best practices
Run --frozen-lockfile / npm ci in every CI job. Never let CI silently regenerate the lockfile. Review lockfile diffs in PRs like code diffs; unexpected new transitive dependencies or version jumps deserve scrutiny. Configure Dependabot or Renovate to batch updates and respect the same min-age set locally. Run npm audit signatures as a non-blocking CI step to catch tampered tarballs early.
npm depcheck for removing unused dependencies
Periodically run npx depcheck (or equivalent for your stack) to identify and remove dependencies that are not imported anywhere. Every dependency you do not need is attack surface. Also review direct dependencies when CVEs land: tiny utilities become transitive footguns and are exploited frequently.
Restart local Supabase after auth configuration changes
After updating auth provider configuration in supabase/config.toml, you need to run 'supabase stop' and 'supabase start' again for the changes to take effect.
Local development limitations
The local development environment is not as feature-complete as the Supabase Platform. You cannot update project settings in the Dashboard and must use the local config file instead. The CLI version determines the local version of Studio, so keep the Supabase CLI up to date for new features and bug fixes.
Start Laravel development server
Run php artisan serve to start the development server. Access the application at http://127.0.0.1:8000, with registration available at http://127.0.0.1:8000/register and login at http://127.0.0.1:8000/login.
Laravel project creation with Composer
Create a new Laravel project using the command: composer create-project laravel/laravel example-app. Ensure PHP and Composer versions are up to date before running this command.
IPv4 ingress is static, outbound is not
IPv4 addresses are guaranteed to be static for ingress traffic. If your database is making outbound connections, the outbound IP address is not static and cannot be guaranteed.
When to use IPv4 add-on
Use the IPv4 add-on when using the direct connection string in an IPv6-incompatible network instead of Supavisor or client libraries, or when you need a dedicated IP address for your direct connection string.
IPv4 add-on toggle causes short downtime
Direct database connections can experience a short amount of downtime when toggling the IPv4 add-on due to DNS reconfiguration and propagation. This downtime is generally less than a minute.
Read replicas with IPv4 add-on cost
When using the IPv4 add-on, each database including read replicas receives an IPv4 address. Each replica adds to the total IPv4 cost.
IPv4 address changes with project pause or add-on toggle
While the IPv4 address generally remains the same, actions like pausing/unpausing the project or enabling/disabling the add-on can lead to a new IPv4 address.
Supabase default uses IPv6
By default, Supabase Postgres uses IPv6 addresses.
Direct connection string uses IPv6 by default
The direct connection string format postgresql://postgres:[YO••••••D]@db.<PROJECT_REF>.supabase.co:5432/postgres uses IPv6 unless the IPv4 Add-On is enabled.
Supavisor session mode always uses IPv4
Supavisor in session mode uses port 5432 and always uses an IPv4 address. Connection string format is postgresql://postgres.<PROJECT_REF>:[YO••••••D]@aws-0-us-east-1.pooler.supabase.com:5432/postgres
IPv4 add-on enables dedicated IPv4 address for database
The Supabase IPv4 add-on provides a dedicated IPv4 address for your Postgres database connection. It can be configured in the Add-ons Settings.
Find database IP address with nslookup
Use the command nslookup db.<PROJECT_REF>.supabase.co to find your database's IP address.