Cody + Supabase Security
Cody's codebase context makes it strong at understanding your Supabase schema — but that same context can surface credential patterns you don't want replicated.
Why Cody + Supabase?
Cody's deep codebase indexing helps it generate Supabase queries that fit your existing data model. Developers use it to write RLS policies, migrations, and TypeScript types from existing schemas.
Common Vulnerabilities
These are the security issues we find most often in Cody apps using Supabase.
Credential Patterns Repeated Across Files
Cody learns from your existing code. If one file has a hardcoded Supabase URL or key, Cody may suggest the same pattern in new files.
RLS Policies Not Generated With Table Schemas
When Cody generates CREATE TABLE migrations, it typically does not append ENABLE ROW LEVEL SECURITY or accompanying policies.
Insecure Query Patterns From Context
Cody suggests completions based on what it sees in your repo. Insecure query patterns in existing files will be propagated to new code.
Service Key Used in Shared Utilities
Shared utility files often contain both client and server logic. Cody may complete code that adds service_role key usage to utilities that are imported by frontend components.
What We Check for Cody + Supabase
Cross-File Credential Audit
Search the entire codebase for Supabase URLs and key patterns to find any files where credentials were hardcoded based on Cody suggestions.
Migration RLS Coverage
Review every migration file for ENABLE ROW LEVEL SECURITY and CREATE POLICY statements — they must accompany every CREATE TABLE.
Shared Utility Key Isolation
Trace imports of any file that references service_role key to ensure no import chain leads to a client-rendered component.
Anon Key Table Exposure
Query all tables using only the anon key to verify RLS policies block unauthorised access.
Quick Security Wins
Apply these fixes right now to improve your security.
Search repo for 'service_role' and replace any frontend file occurrences with anon key or environment variable referencesAdd a .env.example showing NEXT_PUBLIC_SUPABASE_ANON_KEY and SUPABASE_SERVICE_ROLE_KEY separately to guide Cody's suggestionsInclude RLS boilerplate in your code templates so Cody learns to include it in completionsEnable RLS on all existing tables via Supabase SQL Editor: ALTER TABLE tablename ENABLE ROW LEVEL SECURITY;Add a linting rule or pre-commit check that fails if service_role appears in any src/ directory fileThe Bottom Line
Cody is context-aware, which makes it powerful and risky — it mirrors your existing patterns. Establish secure patterns first, then Cody will propagate them correctly.
Secure Your Cody + Supabase App
Find Row Level Security misconfigurations, exposed credentials, and other vulnerabilities before attackers do.
Start Security ScanFrequently Asked Questions
Does Cody understand Supabase RLS syntax?
Yes, Cody can generate valid RLS policies when asked. The challenge is that it won't add them automatically to migrations unless your codebase already follows that pattern. Establish the pattern once manually, then Cody will replicate it.
How does Cody's codebase indexing affect security?
Cody indexes your entire repository as context. If your codebase contains insecure patterns — hardcoded keys, missing auth checks, broad queries — Cody will suggest those same patterns in new code. Fixing existing insecure code improves Cody's future suggestions.
Should I add Supabase credentials to Cody's context?
The anon key is public and safe in context. Never expose the service_role key to Cody or any AI context. Use variable references like process.env.SUPABASE_SERVICE_ROLE_KEY in code and keep the actual value only in your .env.local file.
How do I prevent Cody from propagating insecure Supabase patterns?
Fix insecure patterns at their source first. Add explicit comments like '// SECURITY: service_role key - server-side only' near sensitive code. Cody reads comments and uses them to inform suggestions. A secure pattern with clear documentation trains Cody to follow it.