How to connect Defencecore to Supabase for security monitoring
Defencecore connects to Supabase through OAuth, discovers the projects the authorization can read, and lets you select the project to monitor. This walkthrough explains the permission boundary, the two-minute setup, how to verify log activity safely, and which Supabase settings affect what a monitor can see.
Connect Defencecore by signing in, choosing Connect Supabase, reviewing the read-only permissions on Supabase's authorization screen, and approving the connection. Return to Projects in Defencecore and choose Monitor this for the Supabase project you want covered.
Defencecore reads supported Supabase log data through the Management API and evaluates implemented detection rules. Defencecore does not need a database password, personal access token, service_role key, or write access, and it cannot change the connected project.
Before you connect
- Use a Supabase Cloud project. The integration reads logs exposed through Supabase's Management API.
- Use a Supabase account allowed to authorize the project. You must be able to see the intended organization and project during authorization.
- Start with staging if you are evaluating. Confirm the permission boundary and activity flow before selecting a production project.
- Never paste a production secret into the setup. The OAuth flow does not require a database password, personal access token, anon key, publishable key, or service_role key.
What the read-only connection does
Supabase OAuth scopes restrict which Management API operations an integration can call. Defencecore uses the authorization to discover project metadata and read supported project logs. Supabase documents the unified log endpoint as requiring analytics:read; project discovery also requires read access to project metadata. Always treat the authorization screen as the source of truth and inspect every permission before approval.
| Permission boundary | Why it is needed | What it does not allow |
|---|---|---|
| Project metadata, read-only | Discover the Supabase projects available to the authorization and identify the selected project. | Create, update, pause, restore, or delete a project. |
| Analytics and logs, read-only | Read supported log events that Supabase has recorded for the monitored project. | Create log drains, change logging settings, or modify application data. |
| No secret-key access | Defencecore does not need application secrets to monitor Supabase logs. | Retrieve or rotate API keys and project secrets. |
You can compare the authorization screen with Supabase's official OAuth scope documentation and the project logs API reference.
Step 1: connect your Supabase account
- Sign in to Defencecore and open the dashboard.
- Select Connect Supabase. Defencecore sends you to Supabase; credentials stay on Supabase's sign-in page.
- Confirm that the Supabase organization and projects shown are the ones you intend to authorize.
- Review the requested permissions. They should be read-only and limited to the metadata and logs needed for monitoring.
- Approve the connection. If the screen requests a write permission or access you do not expect, stop and contact Defencecore before continuing.
Step 2: choose the project to monitor
After Supabase returns you to Defencecore, open Projects. The page lists the projects discovered through the authorization; discovery alone does not place every project under monitoring. Select Monitor this beside the project you want covered. The current plan includes one monitored project, and you can stop monitoring it before switching the slot to another project.
Step 3: verify activity safely
- Confirm that the selected project is labeled Monitored on the Projects page.
- Use the staging application normally: sign in successfully, open a page that calls the Data API, or invoke a test Edge Function.
- Open Activity in Defencecore and check for recent records from the selected project and expected log sources.
- Allow for collection delay and the possibility that a quiet project produced no new event in the selected period.
Normal activity verifies the data path without creating a security incident. Do not disable RLS, expose a secret, or repeatedly attack a production login just to test the monitor. An incident opens only when available log data matches an implemented detection rule; seeing ordinary events in Activity is the safer connection check.
Optional Supabase logging settings
Supabase exposes separate API, Postgres, Auth, Storage, Realtime, and Edge Function log sources. The exact evidence available depends on the service and your Supabase configuration. The official Supabase logging guide is the source of truth for what each stream records.
- Database connections: Supabase says connection logging is off by default for new projects. If connection visibility is part of your threat model, review Postgres connection logging and enable Log connections in Database Settings after considering volume.
- Database statement auditing: ordinary Postgres logs are not a complete row-level audit trail. Supabase documents pgAudit for selected statement classes and roles. Configure it narrowly in staging first; broad auditing can create noise and cost.
- Retention: Supabase log retention depends on the project plan. A monitoring system cannot query records that are no longer available from the source, so incident evidence should be reviewed promptly.
What to expect after setup
| Defencecore does | Defencecore does not |
|---|---|
| Read supported events Supabase recorded for the selected project. | Record events that Supabase never logged. |
| Apply implemented Supabase-specific detection rules. | Guarantee that every possible attack has a detection rule. |
| Open incidents with matching evidence and a first response action. | Decide conclusively that activity was malicious or illegal. |
| Monitor runtime activity continuously. | Replace RLS, Security Advisor, secure application code, backups, or human investigation. |
| Stay outside the production write path. | Block users or change the project automatically. |
How to stop monitoring
Open Projects in Defencecore and select Stop monitoring. That stops future worker runs for the project; previously collected logs and incidents remain available according to Defencecore's retention terms. To remove the account authorization itself, revoke the OAuth authorization from Supabase or ask Defencecore support to disconnect it.
Next, learn how Defencecore differs from the native Supabase Security Advisor and review the broader Supabase log monitoring workflow.
Frequently asked questions
- Does Defencecore need my Supabase database password?
- No. The monitoring connection uses Supabase OAuth. Do not give Defencecore a database password, personal access token, service_role key, or application secret. Review the permissions on Supabase's authorization screen before approving them.
- Can Defencecore change my Supabase project?
- No. The monitoring integration is read-only. It reads permitted project metadata and supported log data, applies implemented detection rules, and presents matching evidence. It does not change RLS policies, rotate keys, block users, or remediate production automatically.
- Does Defencecore replace Supabase Security Advisor?
- No. Supabase Security Advisor finds supported database configuration problems, while Defencecore monitors supported runtime logs for implemented attack and suspicious-activity patterns. Use Security Advisor for posture and Defencecore for continuous runtime monitoring.
- Why do I not see database connection events?
- Supabase disables Postgres connection logging by default on new projects. Enable Log connections in the Supabase Database Settings only if the additional visibility is useful, then assess the extra log volume. Defencecore cannot detect an event that Supabase did not record.
- How can I verify the Supabase integration is working?
- Confirm that the selected project says Monitored in Defencecore, then open Activity and look for recent events from the project. Use ordinary staging application traffic for the check. Do not weaken RLS or generate attacks against production merely to trigger an incident.