Cyber Strategy
Cyber Secure
Cyber Operations
Cyber Response
Cyber ResilienceSoftware engineering has always balanced creativity with structure, but the pressure to ship faster has tilted that balance heavily toward speed. Out of this pressure came a pattern now known as vibe coding. It describes a mode of development where intuition replaces design, quick fixes override structured decisions, and code is assembled through patterns that “feel right” rather than patterns that are tested, reviewed, or validated.
Teams often do not notice the danger immediately. The product works. The feature deploys. The API responds. Everything appears smooth until a weakness buried deep in the application becomes an attacker’s entry point. That is the true risk behind vibe coding. The product functions, but the architecture behind it is fragile.
How Vibe Coding Works
The process seems straightforward. A developer describes an application’s purpose in plain language: “Build me a task management system with user authentication.” The AI model generates the necessary code, structures the database, connects APIs, and produces a functional application. If something needs adjustment, another conversational prompt refines the implementation.
This workflow eliminates much of the technical complexity that historically made software development inaccessible. Non-technical founders can prototype business ideas. Marketing teams can build internal tools without engineering support. Analysts can create data dashboards without learning SQL.
The speed feels revolutionary. Applications that would traditionally require days or weeks of development materialize in hours. But this velocity introduces a fundamental problem: developers rarely examine the code that makes their applications work. When functionality appears correct, there’s little incentive to scrutinize implementation details.
Real Vulnerabilities in Production Systems
Security teams analyzing vibe-coded applications found that roughly one in five contained exploitable vulnerabilities. These weren’t hypothetical weaknesses but actual flaws in deployed systems handling real user data.
Authentication in the Wrong Place
A common mistake involves implementing login systems entirely in browser-based JavaScript. These applications check passwords directly in code that downloads to users’ devices. Anyone with basic technical knowledge can view the source code and extract the hardcoded password.
One example included a login function that compared user input against the string “marketingdocs2025” stored in a JavaScript variable. If the values matched, the application set a flag in browser storage indicating successful authentication. An attacker could bypass this by opening developer tools and manually setting the authentication flag without knowing the password.
Another pattern involves applications that validate credentials against values embedded in client-side configuration files. The developers believed moving the password into a separate variable provided security, but the fundamental flaw remains: all authentication logic executes in an environment the user controls.
Credentials Embedded in Public Code
Research discovered numerous applications with third-party API keys hardcoded directly in JavaScript files. These included OpenAI API keys worth hundreds of dollars in usage, payment processor credentials capable of initiating transactions, and cloud service tokens with broad permissions.
When an application loads in a browser, all its JavaScript code becomes visible to anyone inspecting the page. API keys embedded this way are immediately compromised. Attackers can extract these credentials and use them for unauthorized access, running up costs on the victim’s account or accessing sensitive data through the compromised API.
Database Tables Without Access Controls
Many vibe-coded applications connect to backend database services but fail to properly configure access permissions. One gaming application exposed a database table containing player information including email addresses, IP locations, and account details. The database required no authentication for read access, allowing anyone with the connection string to query all records.
The connection details existed in client-side JavaScript, making them trivial to discover. An attacker could enumerate all database tables, identify those containing sensitive information, and extract complete datasets. From the developer’s perspective, the application worked correctly. Users could register accounts, save progress, and interact with the system. The security failure only became apparent during external review.
Internal Tools on Public Internet
Organizations use vibe coding to rapidly build internal dashboards, knowledge bases, and administrative interfaces. Many of these applications end up hosted on public URLs without authentication requirements. Attackers actively scan for applications built with specific platforms, identifying internal tools that leak proprietary information.
Examples include project management systems revealing company strategy, customer service dashboards exposing support tickets, and internal chatbots trained on confidential documents. These applications weren’t intended for public access but ended up discoverable because teams prioritized speed over security configuration.
Why AI Generates Insecure Code
Language models learn from massive code repositories that include both secure and vulnerable implementations. When generating code, these models optimize for functionality based on common patterns they’ve observed. Security considerations don’t factor into this process unless explicitly requested.
An AI model tasked with adding user authentication might implement the simplest approach that satisfies the functional requirement. Client-side password checking works in basic testing, so the model considers it a valid solution. The fact that this approach fails security principles isn’t apparent to the AI.
Models also lack context about how code will be used. They can’t distinguish between a prototype for local testing and a production system handling customer data. Without explicit security guidance, AI defaults to straightforward implementations that pass functional tests but fail security review.
The testing process compounds this issue. Developers verify that features work as intended, checking user interfaces and basic functionality. Security vulnerabilities remain invisible during typical testing workflows because they don’t prevent the application from functioning correctly.
Memory Safety Issues in Low-Level Code
Beyond web applications, vibe coding creates problems in systems programming. When tasked with parsing binary file formats, AI-generated C code frequently contains memory safety vulnerabilities.
Research found a vibe-coded parser that read file format headers without validating input sizes. An attacker could craft a malicious file with an extremely large length value, causing integer overflow when the parser allocated memory. The allocation would succeed with a small buffer, but subsequent operations would write beyond allocated boundaries, corrupting memory and potentially enabling code execution.
These vulnerabilities mirror classic security issues that have existed for decades. The difference lies in how easily they can be introduced when developers who lack systems programming experience use AI to generate low-level code. The parser worked correctly with valid input files, only revealing its flaws when fed intentionally malicious data.
Strategies for Secure AI-Assisted Development
Research demonstrates that modifying how developers prompt AI models significantly reduces vulnerable code generation. As AI systems increasingly handle both offensive and defensive security operations, organizations must incorporate secure coding techniques into their AI-assisted development workflows.
Explicit Security Requirements
Including security requirements in prompts produces measurably better results. Instead of asking for “a user login system,” specify “a server-side authentication system using OAuth that never stores passwords in client code.”
Language-specific prompts that address known vulnerability classes prove particularly effective. For Python development, prompts might emphasize avoiding pickle for untrusted data and using parameterized database queries. For JavaScript applications, prompts should stress that all authentication occurs server-side and no secrets belong in client code.
Code Review Workflows
Generating code and immediately feeding it back to the AI model for security review catches many issues. This two-pass approach involves first creating functionality, then explicitly asking the model to identify security vulnerabilities in what it generated.
Testing shows this technique reduces vulnerable code by approximately 30-40% compared to single-pass generation. While not comprehensive, it provides meaningful improvement without requiring deep security expertise from developers.
Architectural Boundaries
Critical security decisions must occur in places users cannot access or modify. For web applications, this means all authentication and authorization happens on backend servers. Client code should only collect credentials and send them to protected endpoints for validation.
API keys and service credentials should never appear in browser code. Instead, create backend endpoints that forward requests to third-party services. Store sensitive credentials in environment variables or secrets management systems accessible only to server processes. Organizations need to establish these architectural requirements as non-negotiable standards, particularly as data exfiltration techniques become more sophisticated and harder to detect through traditional monitoring.
Database Security Configuration
Start every data access configuration with deny-by-default policies. Database tables should require explicit permission for operations. Use row-level security to ensure queries automatically filter results based on the authenticated user’s identity and permissions.
Test these policies thoroughly by attempting unauthorized access through different user contexts. Verify that users cannot access other users’ data, that anonymous requests are blocked, and that privilege escalation isn’t possible through API manipulation.
Software engineering has always balanced creativity with structure, but the pressure to ship faster has tilted that balance heavily toward speed. Out of this pressure came a pattern now known as vibe coding. It describes a mode of development where intuition replaces design, quick fixes override structured decisions, and code is assembled through patterns that “feel right” rather than patterns that are tested, reviewed, or validated.
Teams often do not notice the danger immediately. The product works. The feature deploys. The API responds. Everything appears smooth until a weakness buried deep in the application becomes an attacker’s entry point. That is the true risk behind vibe coding. The product functions, but the architecture behind it is fragile.
How Vibe Coding Works
The process seems straightforward. A developer describes an application’s purpose in plain language: “Build me a task management system with user authentication.” The AI model generates the necessary code, structures the database, connects APIs, and produces a functional application. If something needs adjustment, another conversational prompt refines the implementation.
This workflow eliminates much of the technical complexity that historically made software development inaccessible. Non-technical founders can prototype business ideas. Marketing teams can build internal tools without engineering support. Analysts can create data dashboards without learning SQL.
The speed feels revolutionary. Applications that would traditionally require days or weeks of development materialize in hours. But this velocity introduces a fundamental problem: developers rarely examine the code that makes their applications work. When functionality appears correct, there’s little incentive to scrutinize implementation details.
Real Vulnerabilities in Production Systems
Security teams analyzing vibe-coded applications found that roughly one in five contained exploitable vulnerabilities. These weren’t hypothetical weaknesses but actual flaws in deployed systems handling real user data.
Authentication in the Wrong Place
A common mistake involves implementing login systems entirely in browser-based JavaScript. These applications check passwords directly in code that downloads to users’ devices. Anyone with basic technical knowledge can view the source code and extract the hardcoded password.
One example included a login function that compared user input against the string “marketingdocs2025” stored in a JavaScript variable. If the values matched, the application set a flag in browser storage indicating successful authentication. An attacker could bypass this by opening developer tools and manually setting the authentication flag without knowing the password.
Another pattern involves applications that validate credentials against values embedded in client-side configuration files. The developers believed moving the password into a separate variable provided security, but the fundamental flaw remains: all authentication logic executes in an environment the user controls.
Credentials Embedded in Public Code
Research discovered numerous applications with third-party API keys hardcoded directly in JavaScript files. These included OpenAI API keys worth hundreds of dollars in usage, payment processor credentials capable of initiating transactions, and cloud service tokens with broad permissions.
When an application loads in a browser, all its JavaScript code becomes visible to anyone inspecting the page. API keys embedded this way are immediately compromised. Attackers can extract these credentials and use them for unauthorized access, running up costs on the victim’s account or accessing sensitive data through the compromised API.
Database Tables Without Access Controls
Many vibe-coded applications connect to backend database services but fail to properly configure access permissions. One gaming application exposed a database table containing player information including email addresses, IP locations, and account details. The database required no authentication for read access, allowing anyone with the connection string to query all records.
The connection details existed in client-side JavaScript, making them trivial to discover. An attacker could enumerate all database tables, identify those containing sensitive information, and extract complete datasets. From the developer’s perspective, the application worked correctly. Users could register accounts, save progress, and interact with the system. The security failure only became apparent during external review.
Internal Tools on Public Internet
Organizations use vibe coding to rapidly build internal dashboards, knowledge bases, and administrative interfaces. Many of these applications end up hosted on public URLs without authentication requirements. Attackers actively scan for applications built with specific platforms, identifying internal tools that leak proprietary information.
Examples include project management systems revealing company strategy, customer service dashboards exposing support tickets, and internal chatbots trained on confidential documents. These applications weren’t intended for public access but ended up discoverable because teams prioritized speed over security configuration.
Why AI Generates Insecure Code
Language models learn from massive code repositories that include both secure and vulnerable implementations. When generating code, these models optimize for functionality based on common patterns they’ve observed. Security considerations don’t factor into this process unless explicitly requested.
An AI model tasked with adding user authentication might implement the simplest approach that satisfies the functional requirement. Client-side password checking works in basic testing, so the model considers it a valid solution. The fact that this approach fails security principles isn’t apparent to the AI.
Models also lack context about how code will be used. They can’t distinguish between a prototype for local testing and a production system handling customer data. Without explicit security guidance, AI defaults to straightforward implementations that pass functional tests but fail security review.
The testing process compounds this issue. Developers verify that features work as intended, checking user interfaces and basic functionality. Security vulnerabilities remain invisible during typical testing workflows because they don’t prevent the application from functioning correctly.
Memory Safety Issues in Low-Level Code
Beyond web applications, vibe coding creates problems in systems programming. When tasked with parsing binary file formats, AI-generated C code frequently contains memory safety vulnerabilities.
Research found a vibe-coded parser that read file format headers without validating input sizes. An attacker could craft a malicious file with an extremely large length value, causing integer overflow when the parser allocated memory. The allocation would succeed with a small buffer, but subsequent operations would write beyond allocated boundaries, corrupting memory and potentially enabling code execution.
These vulnerabilities mirror classic security issues that have existed for decades. The difference lies in how easily they can be introduced when developers who lack systems programming experience use AI to generate low-level code. The parser worked correctly with valid input files, only revealing its flaws when fed intentionally malicious data.
Strategies for Secure AI-Assisted Development
Research demonstrates that modifying how developers prompt AI models significantly reduces vulnerable code generation. As AI systems increasingly handle both offensive and defensive security operations, organizations must incorporate secure coding techniques into their AI-assisted development workflows.
Explicit Security Requirements
Including security requirements in prompts produces measurably better results. Instead of asking for “a user login system,” specify “a server-side authentication system using OAuth that never stores passwords in client code.”
Language-specific prompts that address known vulnerability classes prove particularly effective. For Python development, prompts might emphasize avoiding pickle for untrusted data and using parameterized database queries. For JavaScript applications, prompts should stress that all authentication occurs server-side and no secrets belong in client code.
Code Review Workflows
Generating code and immediately feeding it back to the AI model for security review catches many issues. This two-pass approach involves first creating functionality, then explicitly asking the model to identify security vulnerabilities in what it generated.
Testing shows this technique reduces vulnerable code by approximately 30-40% compared to single-pass generation. While not comprehensive, it provides meaningful improvement without requiring deep security expertise from developers.
Architectural Boundaries
Critical security decisions must occur in places users cannot access or modify. For web applications, this means all authentication and authorization happens on backend servers. Client code should only collect credentials and send them to protected endpoints for validation.
API keys and service credentials should never appear in browser code. Instead, create backend endpoints that forward requests to third-party services. Store sensitive credentials in environment variables or secrets management systems accessible only to server processes. Organizations need to establish these architectural requirements as non-negotiable standards, particularly as data exfiltration techniques become more sophisticated and harder to detect through traditional monitoring.
Database Security Configuration
Start every data access configuration with deny-by-default policies. Database tables should require explicit permission for operations. Use row-level security to ensure queries automatically filter results based on the authenticated user’s identity and permissions.
Test these policies thoroughly by attempting unauthorized access through different user contexts. Verify that users cannot access other users’ data, that anonymous requests are blocked, and that privilege escalation isn’t possible through API manipulation.
The Responsibility Gap
Vibe coding platforms provide infrastructure and AI capabilities, but application security depends on implementation choices made by developers. This creates a shared responsibility model where platform providers can improve AI behavior and offer security guidance, while developers must follow best practices and review generated code.
Organizations need visibility into vibe-coded applications their teams create. Without oversight, shadow IT proliferates as individuals build applications that handle sensitive data without security review. Establishing policies for AI-assisted development helps manage this risk.
Practical Steps Forward
Teams adopting vibe coding should implement security checkpoints in development workflows. Before deployment, applications should undergo review focusing on authentication implementation, secrets management, database permissions, and public accessibility.
Security training for developers using AI code generation should cover common pitfalls specific to vibe-coded applications. Understanding why client-side authentication fails or why embedded API keys create risk helps developers write better prompts and catch issues during review.
Regular audits of existing vibe-coded applications identify configuration drift and newly discovered vulnerabilities. Applications that were secure at deployment may become exposed through infrastructure changes or evolving attack techniques.
Building Securely With AI
Vibe coding represents a genuine advance in software development accessibility. The ability to describe applications in natural language and receive working implementations removes significant barriers. This democratization enables innovation that wouldn’t be practical through traditional development.
Security must be part of this new development paradigm from the beginning. The vulnerabilities found in vibe-coded applications aren’t unique to AI generation. Many represent security issues that have affected manually written code for decades. The difference lies in scale and how easily these flaws spread when developers rely on AI without adequate review.
With proper precautions, vibe coding delivers productivity benefits without creating disproportionate security risks. The key is approaching AI-generated code with the same security mindset applied to any other development method, recognizing that speed and convenience cannot come at the expense of safety.
The Responsibility Gap
Vibe coding platforms provide infrastructure and AI capabilities, but application security depends on implementation choices made by developers. This creates a shared responsibility model where platform providers can improve AI behavior and offer security guidance, while developers must follow best practices and review generated code.
Organizations need visibility into vibe-coded applications their teams create. Without oversight, shadow IT proliferates as individuals build applications that handle sensitive data without security review. Establishing policies for AI-assisted development helps manage this risk.
Practical Steps Forward
Teams adopting vibe coding should implement security checkpoints in development workflows. Before deployment, applications should undergo review focusing on authentication implementation, secrets management, database permissions, and public accessibility.
Security training for developers using AI code generation should cover common pitfalls specific to vibe-coded applications. Understanding why client-side authentication fails or why embedded API keys create risk helps developers write better prompts and catch issues during review.
Regular audits of existing vibe-coded applications identify configuration drift and newly discovered vulnerabilities. Applications that were secure at deployment may become exposed through infrastructure changes or evolving attack techniques.
Building Securely With AI
Vibe coding represents a genuine advance in software development accessibility. The ability to describe applications in natural language and receive working implementations removes significant barriers. This democratization enables innovation that wouldn’t be practical through traditional development.
Security must be part of this new development paradigm from the beginning. The vulnerabilities found in vibe-coded applications aren’t unique to AI generation. Many represent security issues that have affected manually written code for decades. The difference lies in scale and how easily these flaws spread when developers rely on AI without adequate review.
With proper precautions, vibe coding delivers productivity benefits without creating disproportionate security risks. The key is approaching AI-generated code with the same security mindset applied to any other development method, recognizing that speed and convenience cannot come at the expense of safety.
See also:
Dubai