Vibe Coding Security: What to Do If Your App Is Hacked

If your vibe-coded app may be under attack, stop the exposed operation, revoke compromised access, preserve evidence, and investigate before reopening it. Ask your hosting or security provider for help immediately if you cannot contain the damage.

Vibe coding security has two jobs: protecting the application you ship and limiting what the coding agent can access while building it. A working login screen proves neither.

This guide is for a solo founder or small team running an AI-built web app with user accounts, a database, and paid APIs. It combines published incident-response guidance with practical checks for that stack. The workflows below are editorial recommendations, not a report of penetration tests we performed.

If your app is being attacked: start here

Treat these as priorities, not a stopwatch. Containment and evidence collection can happen together; do not leave an active leak open while trying to collect perfect logs.

1. Stop automatic deployments and pause coding agents, scheduled jobs, or integrations that could make the incident worse.
2. Restrict the affected API route, database access, storage resource, or paid feature. A maintenance page only helps if it also blocks the underlying access.
3. From a trusted device and account, revoke exposed credentials or malicious sessions. If an administrator account is compromised, recover that control first.
4. Export available access, authentication, deployment, database, and billing logs. Record the first alert and every response action with UTC timestamps.
5. Contact the affected providers through their official support channels. Bring in an incident responder if data may have been stolen, systems are being altered, or the entry point is unclear.

Isolation and preserving short-lived evidence are central recommendations in CISA's ransomware response guidance. We adapt those principles here to web applications; a leaked API key and ransomware require different technical responses.

Do not wipe the deployment, delete suspicious files, or let an agent “clean everything up” before preserving evidence. If a device itself may be compromised, isolate it and use another trusted device for account recovery. Avoid powering it off unless needed to stop harm or directed by your responder, because volatile evidence can disappear.

Match the symptom to the first containment action

A signal justifies investigation. It does not automatically establish what happened.

If someone sends a vulnerability report, acknowledge it privately and ask for the affected URL, time, and a minimal redacted example. Do not ask them to retrieve more customer data to prove the problem.

A secret API key leaked: revoke it before cleaning Git

GitHub's guidance puts revocation or rotation before repository cleanup. Removing a file, making the repo private, or rewriting history cannot invalidate a copied credential.

Use the issuer's official dashboard and compromised-key procedure:

1. Revoke the exposed credential promptly. If a rotation process overlaps old and new keys, explicitly end the old key's validity; creating a replacement alone is insufficient.
2. Review usage beginning at the earliest plausible exposure, including logs available before discovery. Record what that key could access or change.
3. Install a replacement with the smallest usable permissions in trusted server configuration. Redeploy the consumers that need it.
4. Remove the leak from source, build output, logs, shared snippets, and affected deployment artifacts. Coordinate any Git history cleanup with collaborators.
5. Confirm through the provider's supported check that the old credential is invalid and that replacement credentials no longer appear in public output.

Preserve key identifiers and audit records without copying the full secret into your incident document.

For Supabase, identify the key type before deciding that public visibility is an incident. Its API key documentation distinguishes publishable keys, which are intended for client code, from secret keys and legacy service_role keys, which provide elevated access and bypass Row Level Security (RLS). Publishable keys still need appropriate database grants and RLS policies.

An exposed elevated key calls for credential revocation and a data-access investigation. Enabling RLS alone does not contain access through a credential that bypasses it. Follow the current provider procedure for your key type, especially for legacy keys with coupled rotation behavior.

Users can see each other's data: check authorization

Authentication establishes who the user is. Authorization determines which records and actions that identity may access.

A route that checks “logged in” but accepts any requested invoice ID can still expose another customer's invoice. Hiding the invoice link in the interface does not protect the API.

OWASP recommends denying access by default and checking permissions on every request. Apply the check where data is read or changed. If the browser accesses a database directly, review the database policies as well.

Restrict the vulnerable path, then investigate both exposure and exploitation:

• Identify the earliest vulnerable deployment or policy change.
• Map the records and fields the faulty rule could expose.
• Review available request and database logs for unauthorized access.
• Record gaps in retention, coverage, and identity information.

A reproducible access-control failure establishes that data was accessible. It does not establish that every accessible record was stolen. Equally, missing logs cannot establish that no one accessed it.

Run a two-account test with synthetic data

Use a staging environment and accounts you own. Put a distinctive test record under Account A, then:

1. Confirm A can read and update its record.
2. Sign in as Account B and request A's record through the actual API or database access path.
3. Attempt the same read while signed out.
4. Test an update or deletion against a disposable test record.
5. Check list, search, export, and file-download paths separately.

B and the signed-out caller must receive no protected record content and cause no unauthorized change. A denial might be a 403, a 404, or an empty database result depending on the design; verify the data and side effects rather than one status code.

Keep these checks as regression tests. A patch to the detail page leaves the incident unresolved if an export endpoint still returns the same data.

Someone took over an account: remove continuing access

Start with the account that controls recovery. An attacker controlling your email may be able to reset your hosting or source-control password again.

From a trusted device, recover affected accounts through official provider procedures. Review recovery addresses and MFA methods, then inspect active sessions, personal access tokens, SSH keys, OAuth grants, deploy keys, and newly added collaborators. Review deployment workflows, webhooks, and scheduled jobs for changes.

Invalidate affected sessions and refresh tokens using the authentication provider's supported mechanisms. A password reset does not prove that a stolen session has stopped working. OWASP's session guidance explains the need for server-side invalidation; deleting a cookie in your own browser does not terminate an attacker's session.

If signing keys may be exposed, use the provider's signing-key incident procedure. Do not assume rotating an unrelated application secret invalidates all issued tokens.

Revoke credentials the attacker could retrieve through the compromised account. Rebuilding the app is insufficient if an attacker retains access to the deployment system.

Unexpected API charges: find which path is spending

There are two different problems to distinguish:

• An attacker obtained the provider key and calls the provider directly.
• An attacker repeatedly calls your endpoint, which spends using your private server key.

Key revocation addresses the first path. The second also requires controls on your endpoint.

Pause the costly operation while you investigate. Check provider usage records alongside your application's request logs. Add server-enforced account quotas, request limits, input-size limits, and job timeouts before restoring the feature. If accounts are cheap to create, a per-account limit needs additional abuse controls.

OWASP's REST security guidance covers rate limiting and warns against relying exclusively on API keys for high-value resources. For payment integrations, Stripe recommends prompt rotation of a compromised secret key.

Confirm what your provider's budget setting actually does. An alert may notify you without stopping requests. Ask support about suspicious usage and billing review, but do not assume charges will be refunded.

The coding agent did something suspicious: stop its access

A coding agent may read repository files, issue descriptions, package output, or web pages containing hostile instructions. Those inputs must not gain authority to approve commands, reveal secrets, or change production permissions. OWASP's prompt-injection guidance places authorization and least-privilege enforcement outside the model.

Stop the run. Preserve the transcript, tool calls, command output, relevant files, and available network records. Disconnect the agent's credentials and integrations while you establish what it accessed.

If an unexpected command executed, assess its possible effects beyond the visible code diff. An unchanged repository does not rule out a credential read or an outbound request.

For future runs, use a dedicated development environment with synthetic data. Grant access to the task's files and tools, require review for sensitive operations, and keep production credentials out of its reach. These measures follow OWASP's agent-security guidance.

Our AI agent safety checklist before tool access helps you scope those permissions. Use it before reconnecting an agent after an incident.

Preserve an incident record you can hand to support

Keep original evidence in a restricted location and work from redacted copies. Export logs before retention windows expire. Record who collected each export and when; ask your responder about integrity and evidence-handling requirements.

OWASP's logging guidance recommends excluding or protecting passwords, tokens, and sensitive personal information. Do not turn the investigation record into another leak.

Copy this into your incident workspace:

Incident owner and trusted contact:
First alert time (UTC):
Observed symptom and source:
Affected app, environment, provider, route, or resource:
Confirmed facts:
Unconfirmed possibilities:
Earliest plausible exposure:
Potentially affected data and permissions:
Containment action, operator, and UTC time:
Revoked credential identifiers / sessions (no secret values):
Evidence locations, collection times, and retention gaps:
Provider support case references:
Fix, reviewer, and deployment identifier:
Recovery checks and actual results:
Communication / reporting owner and next update:
Remaining uncertainty and follow-up owner:

If customer data, payments, or business-critical systems may be affected, involve the responsible security and privacy contacts early. Ask qualified counsel or your organization's response lead to establish applicable notification and reporting requirements promptly; deadlines vary by jurisdiction, sector, and contract. Do not wait for a complete forensic report to begin that assessment.

In an initial update, state what you observed, what you restricted, what users should do if anything, and when you will update them. Avoid claiming “no data was accessed” without evidence that supports it.

Reopen only after recovery checks pass

Restoring a backup can restore the vulnerable code or configuration along with the data. A rollback also leaves stolen credentials valid unless you revoke them.

Before restoring access, assign someone to verify:

• The entry point is fixed, or the affected function remains disabled.
• Exposed credentials and attacker sessions are invalidated.
• No unexplained administrator, integration, workflow, or scheduled task remains.
• The relevant abuse test fails safely, while legitimate use still works.
• Restored data and deployed code come from a trusted recovery source.
• Logging, alerts, and an owner are ready to watch for recurrence.

If the host or build environment was compromised, plan a clean rebuild rather than trusting an in-place edit. If data was encrypted or deleted, preserve the affected state and restore a verified backup into a clean environment with provider or responder help.

NIST SP 800-61 Revision 3, published in April 2025, treats incident response as part of ongoing cybersecurity risk management. Recovery should feed a specific prevention change: a permission removed, a regression test added, or an alert that reaches an owner.

A security checklist for your next vibe-coded release

Check the deployed behavior as well as the source code. Use staging, disposable accounts, and synthetic records for these exercises.

Use parameterized queries for database inputs. Asking the model to “sanitize everything” is too vague to verify.

Dependency audits provide narrower evidence than their reassuring output can suggest. npm explains that its audit checks for known dependency vulnerabilities. A clean result does not evaluate your ownership rules, database policies, or agent permissions.

This is a starting checklist, not a complete application-security standard. Uploads, rich-text rendering, webhooks, and server-side URL fetching need feature-specific review. Apps handling sensitive personal data or important financial operations warrant qualified security review before launch.

Prompts that make an AI review easier to verify

Use an approved environment with redacted code and synthetic examples. Keep credentials and customer records out of the prompt. Ask for evidence the reviewer can check:

Review this app's access-control boundaries without editing code.
 
Map browser, server, database, storage, and external API access.
For each private operation, identify the authenticated identity,
ownership or role check, and enforcement location.
 
Report concrete findings with file and line references.
Separate confirmed behavior from assumptions and unknowns.
Propose staging tests using two synthetic accounts, including
cross-user reads, writes, exports, and signed-out requests.
 
Flag secrets in client output and unbounded paid operations.
Do not disable security controls to make tests pass.
Return the highest-priority findings for human review.

During an incident, constrain the request further:

Help organize the redacted incident evidence below.
Do not execute commands, edit files, or access production.
 
Separate confirmed facts, hypotheses, and missing evidence.
Suggest containment options and explain their service impact.
Identify logs worth preserving and provider help needed.
Propose checks that would establish whether each fix worked.
Do not infer that missing logs prove no unauthorized access.

The model's output is a set of leads to verify. Our explanation of why AI agents fail even when the model is smart covers the broader problem of treating a plausible answer as a successful system outcome.

Use the distinction between AI assistance and AI decision-making to assign responsibility: the assistant can organize evidence and propose a patch; an accountable person decides when to restore access.

For more practical prompts, model insights, and tool reviews for building with AI, join ThePromptBuddy's free bi-weekly newsletter. Start by keeping the incident record somewhere you can reach when the app is unavailable.