Secrets
Environment files, provider tokens, database URLs, private keys, and public client variables.
Built with Codex, Claude, Cursor, or another coding agent
Vibe coding security scanner before users find the gaps.
A working AI-built app can still commit a live credential, trust the browser with an admin key, skip tenant isolation, or give a deployment workflow more access than it needs. Scan the repository and the public app as two separate attack surfaces.
Five boundaries to verify
The code can pass tests and still cross the wrong boundary.
Research on AI-generated code has found that functional success does not guarantee security. The useful response is a repeatable review at the places where authority changes hands.
Where authority changes hands
4 · GitHub / CI → app release
Review workflow permissions, untrusted PR code and deployment secrets.
Five boundaries: 1 Secrets, 2 Authorization, 3 Data access, 4 CI and releases, 5 Public app. Browser requests reach the public app edge, server routes, and database; CI publishes the release. Verify each boundary independently.
Authorization
Server routes and database rules that must separate users, roles, and tenants after login.
Data access
Supabase RLS, service-role placement, exposed tables, storage policies, and administrative clients.
CI and releases
GitHub Actions permissions, untrusted pull requests, mutable actions, and deployment secrets.
Public app
TLS, headers, cookies, exposed files, source maps, redirects, CORS, and browser-facing behavior.
A safer shipping loop
Run the checks where the mistake is introduced.
A production scan cannot see a private workflow file. A repository scan cannot prove that a CDN serves the right security headers. Use both.
- STEP 01
Before the first deployment
Scan the repository. Rotate any committed secret before doing anything else.
- STEP 02
Before every merge
Review workflow permissions, database migrations, and new server authorization paths.
- STEP 03
After production deploys
Scan the live URL for TLS, headers, cookies, exposed files, source maps, and redirects.
- STEP 04
After a security fix
Run a clean scan again. A deleted finding is evidence that the fix reached the public surface.
By tool
What to check for each AI coding tool.
The same mistakes show up across tools, but each stack has a usual weak spot. Scan the repository with the GitHub repo scanner and the live app with the free website vulnerability scanner, then work through the vibe coding security checklist for what no scanner can prove.
Lovable and Bolt with Supabase
Tables created without row level security, the service-role key reachable from client code, storage buckets left public, and edge functions that trust a user ID sent from the browser.
Run a Lovable security scanCursor
API routes that read or update a record by ID without checking it belongs to the signed-in user, admin pages protected only in the UI, and secrets pasted into config files during debugging.
Claude Code and Codex
Broad GitHub Actions permissions, unpinned actions, agent and MCP configuration that allows destructive commands, and webhook handlers that skip signature verification or idempotency.
Any Next.js or React app
Server-only keys exposed through NEXT_PUBLIC variables, public source maps, missing security headers, permissive CORS and paid features enforced only on the client.
Practical security guides
Fix the risky parts first.
Committed .env or API key
Rotate it, remove it from history, and stop the next leak before push.
Read the guideAI-generated GitHub Actions
Reduce token permissions and keep untrusted pull request code away from secrets.
Read the guideSupabase and tenant data
Verify RLS, key placement, policies, storage, and server-side admin access.
Read the guideVibe coding security FAQ
What the scanners can and cannot prove.
Is vibe coding insecure?
AI-assisted code is not automatically insecure. The risk appears when generated code is accepted without reviewing secrets, authorization, database access, workflows, dependencies, and production behavior. Treat generated code as unreviewed code and verify its security boundaries before release.
Can a website scanner find a committed .env file in GitHub?
Only if the file is also publicly deployed. The ScanMySaaS GitHub repo scanner reads security-relevant files from one pinned commit of your repository and flags committed .env files, private keys and API keys with the file and line. Keep GitHub secret scanning and push protection enabled as well, and rotate any credential that was ever committed.
Does the public repository scanner execute code?
No. ScanMySaaS reads a bounded set of security-relevant text files through the GitHub API. It does not clone the repository, install dependencies, run builds or execute repository code.
How should private repositories be scanned?
Through a GitHub App limited to the repositories you choose, with read-only contents and metadata permissions. ScanMySaaS works this way on Starter and Pro: files are read in memory and discarded, the report is saved privately to your account, and an AI review checks the riskiest files for missing authorization and business-logic gaps.
Research and primary guidance