Vibe coding security checklist: keys, database, OTP, webhooks and AI agents (2026)

Editorial team · updated 23 September 2026 · facts checked 23 September 2026

Vibe coding security comes down to eight checks: keep secret keys out of browser code, turn on row-level security for every table, cap anything that sends SMS or email, verify webhook signatures, set spend limits, audit dependencies, give AI agents narrow tokens, and keep keys and phone numbers out of logs. AI builders scan for some of this, not all.

We read every source linked below on 23 September 2026. The editorial team did not build an app, attack one or run the code; each item says which official page it comes from.

The checklist at a glance

• No secret key in any variable the bundler ships (VITE_, NEXT_PUBLIC_), in chat history or in the repository
• Every provider key is the narrowest one the provider offers (send-only where it exists)
• Row-level security on every table the browser can reach, with grants you have reviewed
• Every endpoint that sends a message checks who is calling and how often
• OTP sends limited per phone number, per IP and per project; CAPTCHA in front of them
• SMS geo permissions trimmed to the countries you serve; pumping protection on
• Spend limits or billing alerts at every provider
• Webhook signatures checked on the raw body; duplicates dropped by event ID
• Every package the AI added exists, is the one you meant and has no known critical CVE
• AI agents and MCP servers get their own scoped, revocable credentials, never your admin key
• Logs carry message IDs and statuses, not keys, OTP codes, phone numbers or message bodies
• The builder's own security scan has run on the version you publish

Where an item matches a category in the OWASP Top 10:2025 or the OWASP API Security Top 10 2023, the current editions when we checked, the section names it. OWASP's Secure Coding with AI Cheat Sheet covers the risks that come from the AI tool itself.

What the AI builders check for you, and what they don't

All six document some check. They differ in what triggers it, what it reads and whether it can stop a release.

Sources: Lovable, Bolt, Replit, v0 and Vercel's blog, Cursor's Bugbot, Security Agents and agent security pages, Claude Code. In Cursor and Claude Code the agent also asks before terminal commands by default; Cursor asks again for each MCP tool call. Lovable's own overview says its scans "do not replace a thorough security review", and its dependency audit turns only critical vulnerabilities into findings.

1. Keys and secrets: an API key exposed in the frontend

Why. A key in browser code belongs to anyone who opens developer tools. An SMS or WhatsApp key sends paid messages from your account; an email key sends mail from your verified domain.

How. Two prefixes decide what ships. Vite states that VITE_* variables "should not contain sensitive information such as API keys" (Vite), and Next.js inlines NEXT_PUBLIC_ variables into the JavaScript bundle at build time (Next.js). Supabase's own .env template marks the server block "Never prefix these, or your bundler will ship the key." Provider keys go into the platform's secret store and are read by a server function.

One Lovable detail: Lovable tells you not to gitignore .env, because it commits that file to hold the public VITE_ values, and it rejects VITE_ names in Secrets. So in a Lovable project, a key typed into .env ends up in your Git history.

Use the narrowest key. Twilio's restricted API keys can be limited to Messaging; Resend keys can be sending-only for one domain; Mailgun has Domain Sending Keys; SendGrid has Custom Access keys such as mail.send; Amazon SES takes IAM policies down to ses:SendEmail. Telnyx API keys and Postmark server tokens have no per-action permissions. The table in item 7 lists more.

Know the Supabase keys. The publishable key (sb_publishable_…, legacy anon) is meant to ship; the secret key (sb_secret_…, legacy service_role) bypasses every RLS policy. Supabase says legacy keys are deprecated "by the end of 2026" and adds a warning vibe coders need: if an AI assistant tells you to copy a long key starting with eyJ, it was written for the legacy keys (Supabase).

If a key leaks. OWASP's Secrets Management Cheat Sheet calls for "immediate revocation" of exposed keys. Supabase's rotation steps add an order: "Don't rush. Fix the root cause of the leak" first, so the replacement doesn't leak the same way, and note that deleting a secret key cannot be undone. Then check the provider's bill and message logs for sends you didn't make.

Let GitHub catch the next one. Push protection for users is on by default and stops pushes of recognized secrets to public repositories. GitHub's supported patterns list covered push protection for AWS, Brevo (as Sendinblue), Facebook access tokens, Mailgun, MessageBird, Plivo, Resend, SendGrid, Supabase secret keys, Telnyx and Twilio API keys on 23 September 2026. It listed no pattern for ClickSend, Infobip, Mailjet, Postmark, Sinch, SMTP2GO, Textmagic or Vonage keys, so push protection won't recognize those by default. A block can be bypassed by giving a reason; treat it as a stop, not a prompt.

2. Database access: Supabase RLS and grants

Why. A vibe-coded frontend talks to the database directly with the publishable key. Supabase is blunt: "Row Level Security decides what this client can reach, so enable it on every table before you deploy." Missing policies fall under OWASP's A01:2025 Broken Access Control, whose third attack scenario is an app that puts "all of their access control in their front-end".

This is not hypothetical for AI-built apps. CVE-2025-48757, published 30 May 2025, describes insufficient RLS policies in sites generated by Lovable through 15 April 2025 that let unauthenticated attackers read or write tables. The researcher reported it to Lovable on 21 March 2025 (disclosure). Lovable disputes the CVE, saying each customer is responsible for protecting their application's data. Either way, the fix sits with whoever publishes the app.

How. From Supabase's RLS guide:

• Enable RLS on every table in an exposed schema. With RLS on and no policies, the publishable key reads nothing.
• Review grants too. On existing projects a new public table grants select, insert, update and delete to anon and authenticated, and "adding policies doesn't take those grants back."
• Views bypass RLS by default. Set security_invoker = true (Postgres 15+) or keep views out of exposed schemas.
• Don't base policies on user_metadata; signed-in users can edit it.
• Write auth.uid() IS NOT NULL AND auth.uid() = user_id so signed-out requests fail explicitly.

Supabase's database advisors flag "rls disabled in public", policies that reference user metadata and security definer views; Lovable's database review and Bolt's database check flag missing and always-true policies. To check by hand, this query lists public tables with RLS off:

Illustrative code, written from the official documentation and not run by the editorial team.

-- Supabase SQL editor: tables in the public schema without row-level security
select c.relname as table_name
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r' and not c.relrowsecurity;

Then sign in as a second test user and try to read the first user's rows. A scanner can flag a missing or always-true policy; it cannot know that one customer must not see another's orders.

3. Auth and OTP abuse

Why. A "send code" button calls a paid API and takes a phone number from a stranger. OWASP's MFA cheat sheet lists the cost among SMS's drawbacks: attackers can request "a large number of messages to exhaust funds". It adds that NIST treats SMS codes as a restricted authenticator because of SIM swap and number porting.

How.

• Limit sends per phone number, per IP and per project, and limit verification attempts per code. Supabase Auth's defaults (rate limits): one OTP request per user per 60 seconds, 30 SMS per hour for the whole project, and 30 requests per 5 minutes per IP on sign-in and verify endpoints. If requests pass through your own server, forward the user's IP in the Sb-Forwarded-For header (Supabase accepts it only with a secret key), or every user shares your server's limit.
• Put a CAPTCHA in front. Supabase supports hCaptcha and Cloudflare Turnstile on sign-in, sign-up and password reset (CAPTCHA); its phone sign-in page says to adjust rate limits and configure CAPTCHA "to keep SMS sending costs under control".
• Prefer a managed verification API. Twilio Verify, Vonage Verify, Plivo Verify, Sinch Verification, Telnyx Verify and AWS's OTP API generate, send, expire and check the codes, so your database never stores them; the OTP API rankings show which ones document fraud controls.
• Return the same response whether or not an account exists, so the endpoint doesn't confirm who your users are. Bolt's audit checks for exactly this.

4. Rate limits, spend caps and SMS pumping

Why. In SMS pumping, bots use your phone-number field to send texts to number ranges controlled by a carrier that shares the revenue with the fraudsters. Twilio's pumping page describes the scheme. OWASP's API4:2023 uses a forgot-password SMS flow at $0.05 per message as its first scenario and recommends spending limits, or billing alerts where limits aren't possible.

How. Provider controls, as documented on 23 September 2026:

• Twilio: SMS Pumping Protection for Programmable Messaging is off until you enable it in the Console; no additional cost for the US and Canada, priced per country elsewhere ($0.025 per message on its Brazil and Mexico pages). Verify's Fraud Guard is on by default and covers the SMS channel only. New accounts can text only their home country until you enable more in SMS Geo Permissions, which "can not be changed programmatically via the API", so an agent holding your key cannot widen them.
• AWS End User Messaging: SMS Protect lets you allow, block, monitor or filter per country; monitor and filter cost extra.
• Plivo: Fraud Shield in Verify, plus Geo Permissions with hourly caps per country and a block-and-alert mode.
• Vonage: the Verify anti-fraud system blocks traffic to a network, first temporarily and then permanently, when it detects fraud; Fraud Defender covers SMS pumping at account level.
• Telnyx: Verify profiles take destination allowlists and daily spend limits; its fraud guide calls restricting countries "the single most effective defense against SMS pumping" and leaves per-IP and per-phone limits to your server.
• Sinch: the docs describe customer-side controls (a callback that approves each verification); no built-in pumping protection is documented.

Two checks cost nothing. Twilio suggests watching the OTP conversion rate (codes verified divided by codes sent) and alerting when it drops in an unexpected country. Telnyx calls 60–80 % healthy and below 20 % a possible attack. And set a usage alert or spend cap at every provider, email included, the day you add the key.

5. Webhooks: verify the signature, then deduplicate

Why. Delivery, bounce and inbound-message webhooks arrive at a public URL. Without a check, anyone can post a fake "delivered" or "unsubscribe" event, or an inbound message.

How. Read the raw body before any JSON parser touches it, compute the signature with the provider's secret, compare in constant time, reject old timestamps where the scheme signs one, and store the event ID so retries don't run twice (the sending side of the same problem is an idempotency key). Illustrative Node.js and Python code for Twilio and Telnyx is in the SMS API tutorial; Meta's X-Hub-Signature-256 check is in the WhatsApp Business API guide. If the provider signs nothing, put a long random token in the URL or use Basic auth, allowlist its published IP ranges, and treat the event as a hint: read the message status back from the API before acting.

Of the 27 providers in our dataset on 23 September 2026, 14 sign webhooks and 13 don't:

Postmark says it "does not currently support HMAC webhook signature verification" (Postmark); Brevo offers IP allowlisting, credentials in the URL or a bearer token. Whether a provider signs its webhooks is on its provider card.

6. Dependencies and packages the AI added

Why. AI tools name packages that don't exist, and attackers register those names. A USENIX Security 2025 paper (arXiv 2406.10279) tested 16 models on 576,000 code samples: at least 5.2 % of suggested packages from commercial models and 21.7 % from open-source models were hallucinated, 205,474 unique names in all. OWASP's A03:2025 now covers the whole software supply chain.

How. Check every new package on the registry before installing (downloads, maintainer, age; OWASP's AI cheat sheet suggests suspicion below 30 days old), run npm audit or pip audit, commit the lockfile and read lockfile changes in the diff. Lovable and Replit audit dependencies automatically; Lovable reports only critical findings.

MCP servers are dependencies too. In September 2025 an npm package named postmark-mcp, not published by Postmark, added a backdoor in version 1.0.16 that secretly BCC'd emails to an outside server, according to Postmark's statement. Install MCP servers only from the repository the provider's docs link to.

7. AI agents and MCP permissions

Why. An agent with your provider key can do anything that key can do, and it reads instructions from files, issues and web pages. OWASP names this LLM06:2025 Excessive Agency. OWASP's GenAI project announced a 2026 edition on 1 September 2026; its list page still showed the 2025 entries when we checked.

How.

• Give each MCP server its own credential, scoped to the task and easy to revoke. The MCP specification's security page forbids token passthrough and lists "wildcard or omnibus scopes (*, all, full-access)" as a common mistake. OWASP's MCP Security Cheat Sheet adds: never share tokens across servers.
• Keep approvals on. Cursor asks before terminal commands and each MCP tool call by default; Claude Code starts read-only in Manual mode. Cursor says its allowlist and .cursorignore are not security boundaries, and OWASP's AI cheat sheet notes that .gitignore does not stop an AI tool reading .env.
• Keep live keys out of the project folder while an agent works there; OWASP's AI cheat sheet warns that an open .env file may be sent to the model as context. Give the agent development keys, so its mistakes cost test credit.

What official MCP servers from communication providers can do, and what they take (from our dataset, checked 23 September 2026):

Twilio's and Plivo's official servers only search documentation (Twilio's covers SendGrid too), Mailjet's is read-only, and 360dialog's manages the account and sends only in narrow cases (your sandbox number, replies in its Inbox, numbers running Meta Business Agent), with no general send tool. AWS's general MCP server runs SES and End User Messaging calls with your IAM credentials, so an IAM policy limited to ses:SendEmail limits the agent too. Blip, Botmaker, Gupshup and Zenvia have only third-party or community servers, and Treble's only reads its docs. SMTP2GO's advice, "a dedicated, narrowly scoped" key for MCP, fits every row. MCP status, transport and auth for every provider are in the AI readiness dataset; OAuth versus API keys for agents, PKCE and token lifetimes are covered in OAuth for AI agents and MCP.

8. Logging and personal data

Why. Logs outlive the bug they were added for and are read by more people and tools than the database. OWASP's Logging Cheat Sheet lists access tokens, passwords, connection strings and "primary secrets" as things not to record, and phone numbers and email addresses as data needing special treatment. Its Top 10 names the other side of the problem, A09:2025 Security Logging and Alerting Failures: no record when something goes wrong.

How. Log the provider's message ID, status, error code and attempt number. Don't log keys (Supabase: not even one that "looks invalid"), OTP codes, message bodies or full phone numbers; mask or hash them. Keep error messages generic toward users, as Lovable's Deep scan and Bolt's audit check.

Worked scenario: phone sign-in on a Lovable app

A US-only app built in Lovable on its own Supabase project uses phone sign-in (Supabase Auth with Twilio as the SMS provider) and sends order updates by email through Resend. The walk-through uses the documented defaults.

1. Keys. The Twilio credentials live in Supabase Auth's SMS settings, and the Resend key in Edge Function secrets as a sending-only key for notify.example.com. Only VITE_SUPABASE_URL and the publishable key sit in the committed .env. The email path is in our Lovable and Supabase email tutorial.
2. Database. orders has RLS on, a select policy for authenticated using auth.uid() IS NOT NULL AND auth.uid() = user_id, and no grant to anon. A second test account sees an empty list.
3. Attack. A script requests codes for thousands of Mexican numbers from rotating IPs. Per-IP and per-user limits don't stop it, because every IP and every number is new. Supabase's project cap of 30 SMS an hour does, at 720 a day. If Mexico were enabled at Twilio, its list price of $0.1819 per segment (checked 23 September 2026) makes that about $131 a day, or $3,929 over 30 days if nobody looks.
4. What changes the numbers. Twilio Geo Permissions left at the home-country default reject every Mexican send with error 21408, so the cost stays at zero before Supabase's cap matters. CAPTCHA on the sign-in form slows the script, and SMS Pumping Protection covers US ranges at no extra cost once enabled.
5. The trade-off. The 30-an-hour cap also blocks real users: the 31st code requested in an hour gets a 429. Raise it only after geo permissions, CAPTCHA and a Twilio usage alert are in place. The Supabase email rate limit fix shows the same trade-off for auth email.
6. Webhook. Resend's delivery webhook goes to a second Edge Function with verify_jwt = false, checks svix-signature on the raw body and stores svix-id to drop retries.

Prompts to give your AI builder

These are plain-text prompts written from the sources above. We have not run them, and no prompt makes an app secure; review what the tool changes.

List every environment variable this app reads. Mark each as public (safe in the
browser) or secret. Move any secret read through a VITE_ or NEXT_PUBLIC_ variable,
or hardcoded in a file, into a server function that reads it from the secret store.
Then show me every file that still references a secret.

For every database table: is row-level security enabled, which policies exist, and
which roles have grants? Add owner-only policies where users should see only their
own rows, and remove grants to anon that the app does not need.

Find every endpoint or function that sends an email, SMS, WhatsApp message or OTP.
For each, require a signed-in user or a CAPTCHA, add a per-recipient and per-IP limit,
and send only to addresses or numbers stored on the user's record.

For each provider webhook handler: verify the signature on the raw request body
using the provider's documented method, reject requests that fail, and store the
event ID so a retried event is processed once.

Related guides

• Connect an AI agent to WhatsApp and SMS: webhooks, Meta's AI rules and human handoff
• One-time password (OTP): meaning and how it works
• Email MCP servers compared: which email APIs an AI agent can drive, and with what permissions
• MCP and agent skills dataset
• Send email from a Lovable app with Supabase, with the key kept in secrets
• Send a text message with an API in Node.js and Python: signed delivery webhooks and safe retries
• WhatsApp Business API guide, including X-Hub-Signature-256
• Best SMS APIs, ranked and OTP APIs, ranked
• The directory's REST API and MCP server, read-only, for agents that need the same data

About this guide

The PingMyUsers editorial team wrote this guide under the rules on the methodology page; the directory is operated by Sensaria AG in Switzerland. We did not create accounts, build or attack an app, send messages or run the code and prompts. Every fact comes from a public page in the sources list or from the directory's provider dataset, where each field carries its source link and check date. Providers appear alphabetically; none paid for placement or reviewed the text. Report an error to contact@sensaria.ch; corrections are dated and sourced.

Methodology

On 23 September 2026 we read the OWASP pages listed in the sources, Supabase's documentation on keys, RLS, secrets, Auth rate limits, CAPTCHA and phone sign-in, the security pages of the six AI tools, GitHub's secret scanning docs, the MCP specification's security best practices, and provider fraud, key and MCP pages. Webhook, key and MCP rows come from the provider dataset; we re-read the Postmark, Brevo, Resend, SMTP2GO and Telnyx pages that day. NIST's Secure Software Development Framework and CISA's Secure by Design address software producers and manufacturers, so items are not mapped to them. The CVE, the Postmark incident and the package study are cited from primary records.

Last updated

23 September 2026: first version, all facts checked that day. Supabase deprecates its legacy API keys by the end of 2026 and OWASP's 2026 LLM Top 10 is rolling out, so we re-check both in January 2027, then every six months.

Frequently asked questions

Is vibe coding secure?

It can be. Lovable, Bolt, Replit, v0 and Cursor offer scans or reviews for common mistakes, but the documented failures sit where scans are weakest: tables without row-level security, keys in browser variables, message endpoints anyone can call. Lovable's own docs say its scans do not replace a thorough security review.

How do I know if my API key is exposed in the frontend?

Open the deployed site, view the JavaScript files in developer tools and search for the key's prefix (re_ for Resend, sb_secret_ for Supabase) and for the provider's API host. A browser that calls the provider directly carries the key, and so does any variable prefixed VITE_ or NEXT_PUBLIC_. If you find one, revoke it at the provider, then move the call into a server function.

Is the Supabase anon key safe to expose?

Yes, the publishable key (legacy anon) is designed to ship in browser code, but only with row-level security on every table the API exposes. The secret key (legacy service_role) bypasses RLS and must never reach a browser. Supabase answers new secret keys sent from a browser with HTTP 401; the legacy service_role key has no such check.

Is Lovable secure?

Lovable runs a Quick scan on every publish, keeps Lovable Cloud secrets write-only and moves provider calls into Edge Functions. Its Deep scan runs only when you start it, and its docs say the scans "do not replace a thorough security review". CVE-2025-48757 (2025) concerned RLS in Lovable-generated apps; Lovable disputes it.

What is SMS pumping and how do I stop it?

Bots use your phone-number field to send texts to number ranges whose carrier shares the revenue with them. Limit OTP sends per number, IP and project, add a CAPTCHA, restrict SMS geo permissions to countries you serve, and turn on the provider's pumping protection.

Do I need to verify webhook signatures?

Yes, whenever the provider signs them: 14 of the 27 providers in our dataset did on 23 September 2026. For those that don't, use a secret URL token or Basic auth, allowlist their IP ranges and confirm the event through the API before acting on it.

Should I give my AI coding agent my provider API key?

Give it a separate key with the narrowest permissions the provider offers and revoke it when the task ends. Some official MCP servers take tokens with full account access, Brevo's among them.