AI coding tools can turn an idea into a working website in hours instead of weeks. The interface looks complete, users can sign in, data is stored, and the product can be deployed almost immediately.
But a website that works is not necessarily a website that is secure.
An application may behave correctly for legitimate users while exposing API keys, allowing one account to access another user’s data, or leaving sensitive endpoints available without authentication.
So, is vibe-coded web development secure?
It can be—but it should never be considered secure by default. The code, APIs, access controls, dependencies, and production configuration still require independent review.
Here are seven security risks to check before deploying an AI-generated website.
1. Exposed API keys and secrets
AI coding assistants often connect applications to databases, payment gateways, email providers, cloud platforms, and external APIs.
To make these integrations work quickly, credentials may be placed directly in the source code or configuration files.
Common examples include:
- API keys
- Database passwords
- JWT signing secrets
- OAuth client secrets
- Webhook secrets
- Cloud access keys
- Private keys
- Service account credentials
Secrets can also leak through committed .env files, Git history, frontend bundles, source maps, logs, Docker images, CI/CD configurations, error messages, screenshots, or prompts sent to AI tools.
A particularly common mistake is referencing a secret environment variable in frontend code. After the application is built, that value becomes part of the JavaScript downloaded by every browser.
If a secret has been pushed to a public repository, assume it has been compromised. Removing the line later is not enough—the credential should be revoked and rotated.
2. Authentication that only looks secure
A complete login screen does not prove that the backend is protected.
AI-generated applications may include registration, login, logout, password recovery, role selection, and “remember me” functionality while still missing important controls such as:
- Login rate limiting
- Secure cookie configuration
- Reasonable token expiration
- Token revocation after password changes
- One-time password-reset links
- Account verification
- Multi-factor authentication
- Backend account-status checks
A frequent mistake is protecting only the user interface.
For example, the frontend may redirect unauthenticated users to /login, while the following endpoint still returns customer information without validating a session:
GET /api/customers
Attackers do not need to use the interface. They can call the API directly with scripts, cURL, Postman, or automated security tools.
Authentication must be enforced on the server for every protected request.
3. Broken authorization and cross-user data access
Authentication answers:
Who is the user?
Authorization answers:
What is this user allowed to do?
An application may authenticate users correctly while still exposing data through broken authorization.
Consider this URL:
/orders/1001
If changing 1001 to 1002 reveals another customer’s order, the application is not verifying ownership of the requested resource.
The same issue can affect:
- Customer IDs
- User IDs
- Invoice IDs
- Tenant IDs
- Project IDs
- File IDs
- Support tickets
- Document download URLs
This is especially dangerous in multi-tenant SaaS applications. A single authorization mistake may allow one company to read or modify another company’s data.
AI-generated code may also fail to understand business rules such as:
- A requester cannot approve their own request
- Employees may only access records from their department
- Managers may view records but not delete them
- Trial accounts cannot access paid features
- Support agents cannot transfer account ownership
- Tenant data must remain completely isolated
These problems usually require manual testing because scanners cannot fully understand business intent.
4. Frontend-only input validation
AI tools frequently add validation to forms: required fields, valid email formats, numeric phone numbers, file extensions, and minimum or maximum values.
However, browser-side validation can be bypassed by sending requests directly to the API.
Attackers may submit:
- Negative or extremely large values
- Unexpected fields
- Modified prices
- Administrative roles
- Very long strings
- HTML or JavaScript
- Query fragments
- Unusual file paths
- Executable files
- Oversized payloads
Without server-side validation, the application may become vulnerable to SQL injection, NoSQL injection, cross-site scripting, command injection, path traversal, mass assignment, malicious file uploads, or server-side request forgery.
Treat every value received by the backend as untrusted—even if the frontend already validated it.
5. Unsafe or imaginary dependencies
When asked to implement a new feature, a coding assistant may recommend installing another package.
That package might:
- Contain known vulnerabilities
- Be abandoned or poorly maintained
- Imitate the name of a popular library
- Introduce unnecessary transitive dependencies
- Use an incompatible license
- Run installation scripts
- Come from an unknown maintainer
- Not actually exist yet
The last case creates a particularly interesting supply-chain risk.
An AI model may generate a plausible package name that does not exist in the registry. An attacker can later register that name and publish malicious code. Developers who follow the AI-generated installation command may then install the attacker’s package.
Malicious dependencies can steal environment variables and tokens, modify source code, compromise CI/CD pipelines, or create persistent access to development systems.
Never install a dependency only because the command succeeds and the original error disappears.
6. Insecure APIs and production configuration
Relatively secure application code can still be deployed in an unsafe environment.
Common configuration problems include:
- Databases exposed to the internet
- Public storage buckets
- Debug mode enabled in production
- CORS allowing every origin
- Public source maps
- Unauthenticated administration dashboards
- Forgotten test endpoints
- Backups stored in public directories
- Stack traces returned to users
- Overprivileged service accounts
- Demo environments using production data
A prototype may begin as an internal dashboard and later be shared with partners, sent through email, or indexed by a search engine.
Without authentication or network restrictions, an “internal tool” can quietly become a public application.
Security review therefore needs to cover the deployment environment—not just the source code.
7. Overprivileged AI coding agents
The security risk is not limited to generated code. The coding agent itself may become part of the attack surface.
Depending on its configuration, an agent may be able to:
- Read an entire repository
- Modify or delete files
- Execute shell commands
- Install packages
- Read environment variables
- Access databases
- Connect to cloud services
- Use MCP servers
- Deploy applications
- Interact directly with production
If the agent processes malicious instructions hidden inside a repository, issue, document, website, email, API response, or package documentation, broad permissions can significantly increase the damage.
A compromised or manipulated agent might expose secrets, install malicious packages, weaken security settings, modify code, or execute dangerous commands.
AI agents should follow the principle of least privilege. Give them only the access required for the current task and keep sensitive production actions behind explicit human review.
Which projects need the most scrutiny?
Not every vibe-coded website has the same risk level.
A static landing page without accounts, stored data, or backend integrations generally carries less risk than a multi-tenant SaaS platform.
Security assessment should be prioritized when the website:
- Has user accounts
- Stores personal or customer data
- Processes payments
- Supports multiple roles
- Exposes APIs
- Uses a multi-tenant architecture
- Connects to internal systems
- Includes an administration panel
- Accepts file uploads
- Uses autonomous AI agents
- Serves enterprise customers
The greater the business impact of a compromise, the less appropriate it is to rely exclusively on AI-generated security checks.
Final thoughts
Vibe coding does not automatically produce insecure websites.
AI can help teams create prototypes, validate ideas, automate repetitive work, and deliver products faster. The risk appears when code generation moves faster than the team’s ability to review, test, and govern it.
Before an AI-generated website goes into production, the team should be able to answer:
- What data does the application process?
- Who is allowed to access that data?
- Which APIs are publicly available?
- Where are secrets stored?
- Which dependencies are installed?
- What actions can the AI agent perform?
- Which failures could affect customers or business operations?
- Who is responsible for incident response?
Asking an AI tool to “write secure code” may reduce some mistakes, but it cannot replace code review, API testing, authorization testing, dependency analysis, configuration review, and penetration testing.
For applications with sensitive data or important business logic, the next step should be a verifiable security process—not another prompt asking the AI to review its own work.
The original Vietnamese article is available here:
Are Vibe-Coded websites secure? 7 risks to check
What security issue have you encountered most often in AI-generated applications?
Top comments (0)