Vibe check: The vibe coder’s security checklist

Mackenzie Jackson

4 min read

Guides

If it’s worth building, it’s worth securing.

Vibe coding has been generating a lot of buzz. While automating and coding with AI isn’t new, vibe coding holds the promise of democratizing software development: simply describe what you want in natural language and let the LLM do the rest.

From AI-enhanced IDEs like Cursor, Copilot in VS Code, and Windsurf, to platforms that abstract coding away completely (such as Bolt, Lovable, and v0), there’s already been an explosion in tooling in this space, and we’re expecting exponential growth to continue.

Check out AINativeDev for an overview of the AI development landscape

We want good vibes only

It’s freeing to be able to build quickly and “forget that the code even exists”—especially if you’re not a professional developer—but the biggest risk with vibe coding is that you don’t know what you don’t know, and a lot of the time you might not understand what the AI-generated code does.

Sure, you can validate that it does what you expect it to, but without knowing what’s going on under the hood, you won’t always know what risks the code is creating until it’s too late (and debugging is notoriously harder than actually writing the code in the first place). If you’re going to the effort of building something—even if you’re accelerating that process through vibe coding—the last thing you want is to be set back by security incidents.

Even seasoned developers have blind spots when it comes to security, and while vibe coding makes software development more accessible, it also makes it both faster and easier to leave your app exposed to vulnerabilities and attacks, like SQL injections, path traversal attacks, and secrets vulnerable to bad actors. While some vibe coding platforms are making an effort to stay ahead of vulnerabilities (v0 is by default skeptical of LLM code), there is still a very real risk of security gaps when vibe coding—leading to the snarky observation that vibe coding = Vulnerability-as-a-Service.

Just take the example below:

‍

Unfortunately there isn’t one obvious reason why our unfortunate friend above ended up having to shut down his app and start over. It’s clear his API keys were leaked, which allowed hackers to impersonate him, meaning they could access or alter data, functionality, or resources.

Any number of insecure API key management gotchas could have been at work here: hardcoding secrets into his application, an environment variable file unwittingly uploaded to his server, or falling victim to a path traversal vulnerability (hey, it even happened to Atlassian). Without additional security checks and processes it would have been easy for a hacker or bot to gain access to his API keys.

Common security vulnerabilities and risks

Whether it’s just you and ChatGPT, or you’re vibe coding with a dedicated tool like Lovable, you’re vulnerable to these common types of cyberattacks.

Cross-Site Scripting (XSS)

A cross-site scripting (XSS) attack exploits vulnerabilities in web applications where user-provided input is not properly validated or sanitized before being displayed or processed. Hackers can then “inject” malicious code via the user input, and when the injected script is executed, it can access sensitive information or perform unauthorized actions on behalf of the victim (in this case, one of your users). XSS attacks can be harmless fun (as in this self-retweeting tweet), but they put your users at risk of having their data exposed or even their accounts taken control of by hackers.

SQL injection attacks

Like XSS, an SQL injection (SQLi) attack injects malicious code into an application, often via a vulnerable user input field. Since SQL is the language many applications use to query their underlying database, this type of attack allows hackers to view or modify your database—accessing confidential data or even deleting records. The Equifax data breach of 2017 was a result of a SQL injection attack, Equifax itself wasn’t targeted—the company had failed to apply a security patch to one of its dependencies.

Path traversal attacks

Attackers can manipulate file path inputs (typically URLs or file parameters) to trick your application into returning non-public files or directories, bypassing access controls and allowing them to read and write to files containing confidential data. This type of attack is also made possible by insecure user inputs. In 2010, researchers discovered a path traversal vulnerability in Atlassian’s Confluence application that would have allowed attackers to retrieve any file on the server that is running Confluence, based on the permissions of the user under which Confluence was running.

Secrets leakage

Secrets—like passwords, encryption keys, API tokens, and digital certificates—give bad actors the keys to your kingdom. These sensitive pieces of data can allow hackers to impersonate you, access your data, and modify your code. A staggering 23 million secrets were found in public source code repositories in 2024, according to the GitGuardian State of Secrets Sprawl report (up 25% on the previous year). Secrets can get exposed by accidentally hardcoding them into your application, or through a vulnerability like the tj-actions/changed-files compromise of March 2025: attackers modified the tj-actions/changed-files GitHub Action code, causing the compromised action to print CI/CD secrets in GitHub Actions build logs.

Supply chain attacks

As much as 85-95% of your application’s code could be powered by open-source libraries and projects. Supply chain attacks don’t exploit one specific type of vulnerability or target a particular application, but rather go after the underlying open-source projects on which many companies depend. The Equifax data breach above was a result of a supply chain attack which had already been mitigated—showing the importance of monitoring your dependencies and applying security patches promptly.

Vibe coding is an amazing tool for exploration and building a proof of concept, but the moment you’re interested in turning something into a viable product and business, you’ll want to set up security checks and best practices to protect what you’ve built.

Can’t I just ask the AI to write more secure code?

Look, this is a valid question. We know that AI doesn’t write secure code by default, but a very quick and dirty improvement is to ask it explicitly to make it secure (as in literally add the words “and make it secure” to your prompt). Surprisingly, this does actually result in code with fewer vulnerabilities.

You can also get the AI to review its own code for vulnerabilities and security gaps, such as asking it to find hardcoded secrets, verify that data isn’t publicly accessible, scan the project for vulnerable dependencies, or identify user input fields (such as forms) with insufficient input validation. All of these efforts will improve the security of your application.

But the point of fact checking AI-generated code for potential hallucinations, vulnerabilities, or other security gaps, is that it’s too risky to have it correct itself without human oversight. You can absolutely integrate AI with traditional scanning methods to enhance things, but not replace them (for example, Aikido uses AI to auto-triage security alerts and propose fixes).

The strongest software engineers are also usually the ones who are most comfortable admitting when they don’t know something. The trouble with leaning too much on AI to police itself is that it is not uncommon for it to make a confident assertion about something that’s wrong, instead of admitting uncertainty. That’s why we don’t recommend relying on AI alone for securing your application.

The good news is that many companies and open-source projects have been dedicated to addressing these security issues long before vibe coding became a thing. One of the biggest lessons new developers learn is to stand on the shoulders of giants. There will be many components to your application that are sensitive and mission critical (things like authentication, cryptography, or even just how you let users upload files to your UI), and asking Cursor or GPT to build those for you is:

Not going to add to your product differentiation
Highly likely to introduce security risks

It’s far better in those cases to lean on providers that focus purely on solutions to those problems. LLMs aren’t specifically trained on best practices or solving a problem in the most efficient or secure way. In many cases, the most elegant solution is to use a pre-existing service rather than building your own (even if you’re offloading the heavy lifting to AI).

It’s easy to get overwhelmed and not know where to begin. We’ve put together this checklist to help you get started building more securely.

‍

Level 0

These are the table-stakes security measures you’ll want to get in place as soon as possible. Once these practices are set up and part of your process, you can build freely without killing the vibe.

Implement Git best practices

One of the common pitfalls of vibe coding is that when adding new functionality or attempting to fix a problem, it’s more intuitive to simply replace what you had before with the new AI-generated code. This works until it doesn’t; eventually, you might hit a wall where nothing the AI produces is helping and you’re even worse off than you were before.

This is what version control is for

Version control like Git emerged as a way for developers to collaborate on projects without overwriting each other’s work. But even if you’re building solo it serves as a way of backing up your progress, which helps with isolating bugs and being able to revert a change when something goes wrong. Here are three key Git practices that will help you build more securely:

Create a .gitignore file for sensitive files

A .gitignore file is simply a plain text file that tells Git what to ignore (i.e. not commit to your repository). Typically, you want Git to ignore computer-generated files like logs, as these clutter your repository and could contain information about the application that could be used to compromise it. Your .env file should also be ignored, as it contains sensitive environment variables (like API keys and passwords) that hackers could use to impersonate you to gain access to your system.

Maintain a clear commit history

Keeping changes as self-contained as possible makes it easier to identify when a bug or vulnerability was introduced, and easier to revert without having to redo other work. Going a step further and setting up signed commits verifies that the right developers are committing code to your repository (even if that’s only you!).

Separate feature development, staging, and production branches

Branching in Git helps to create distinct, self-contained spaces to work on, preview, and release code. Actively developing new features in a separate branch helps to prevent unfinished, buggy, or insecure code from accidentally being committed to your live application. Once a new feature or functionality is fully developed and tested, a staging branch acts as another security and quality gate, allowing you to review and finalize the changes before releasing to production. Only fully tested and stable features can then be merged into your production (usually called main) branch.

Hosted Git repositories: GitHub GitLab

Keep secrets separate from code

‍

‍

Secrets—such as your passwords, encryption keys, API tokens, and digital certificates—should be handled separately from code to avoid committing directly to your codebase. You can check your code for secrets with Aikido, even from your Cursor IDE.

Protect your app from DDoS attacks

A Distributed Denial-of-Service Attack (DDoS) attempts to disrupt the normal traffic of a targeted server, service, or network by overwhelming the target or its surrounding infrastructure with a spike of Internet traffic. These attacks can have devastating consequences, and it’s surprisingly simple to protect yourself by integrating basic DDoS protections with a content delivery network (CDN) like CloudFlare or CloudFront. Some domain hosting providers even offer a CDN as a built-in service.

Don’t do authentication by yourself

Authentication (like your login flow) is a sensitive component of your application that you’ll want to leave to the experts. Using a dedicated tool to enforce a password policy and easily offer single sign-on or even multi-factor authentication for your app as you scale up will protect your user accounts and your reputation.

Great tools: Auth0, Quasr

Never do your own cryptography

By the same token, cryptography is an expertise, so always rely on established mechanisms, libraries, and tools. Building your own implementations, or using flags and options you don’t fully understand,

will expose you to major risks. Libraries such as NaCL expose few options, restricting you to good choices.

‍

Level 1

Set up a CI/CD pipeline to monitor your code

Implementing a CI/CD pipeline with testing is like adding quality checkpoints to the assembly line of your application code. You can integrate static code analysis tools to perform Static Application Security Testing (SAST), which scans your code for flaws that can lead to security vulnerabilities. You can also integrate a tool for Dynamic Application Security Testing (DAST, sometimes called surface monitoring) to simulate attacks and identify vulnerabilities in your web app’s frontend (such as looking for open ports or unrestricted inbound traffic).

Opensource DAST: ZAP

Opensource SAST: Opengrep

Monitor your dependencies

Whether you’re aware of it or not, most of the code that powers your application is likely drawn from the open-source projects and third-party libraries that AI models are trained on. These are your dependencies, and sometimes even those have their own dependencies—all of which make up your software supply chain. A single flaw in any of these libraries could put your entire application at risk, but you can reduce risk by using the right tools to monitor your dependencies for known vulnerabilities.

Recommended tool: Trivy

Set it up in seconds with Aikido

Check your dependencies for malware

Similarly, your supply chain can include malicious packages containing malware. These are exceptionally dangerous, as attackers typically act fast after they’ve succeeded at getting malware into your code. So you also need to react quickly. Note that Common Vulnerabilities and Exposures (CVE) databases are too slow and won’t keep you safe from these kinds of attacks.

Tools: Aikido Intel

Set it up in seconds with Aikido

Use lockfiles to protect your supply chain

If you don’t use lockfiles, any time you build your application, you’ll pull in the latest versions of all open-source packages. Lockfiles enable reproducible builds by pulling in the same versions of your open-source dependencies. This keeps your application stable in the event of any breaking changes in your dependencies, but also protects your app against supply-chain attacks when the latest version of a dependency has been compromised. A recent example of this is tj-actions/changed-files vulnerability of March 2025: attackers modified the tj-actions/changed-files GitHub Action code, causing the compromised action to print CI/CD secrets in GitHub Actions build logs.

Prevent cross-site scripting attacks with strict CSP headers

CSP headers can protect you from common XSS attacks by providing an additional security layer that controls which dynamic resources are allowed to load. That prevents attackers from injecting scripts into your web pages.

Check if you’ve set them up correctly with Aikido

Use a web application firewall

Use a web application firewall (WAF) or Runtime Application Self-Protection (RASP) to protect web-facing servers against unknown zero-day threats, including unknown SQL injection or XSS threats. The tool scans and prevents user requests with suspicious or malicious behavior (such as an injection payload), acting as a last line of defense against attacks.

Great tools: AWS WAF Aikido Zen

‍

Level 2

With the above security measures in place, it’s time to level up your security posture.

Implement best practices for containers

Containers package software so that it can run reliably when moved from one computing environment to another. They bundle an application with all of its necessary dependencies, such as libraries, frameworks, and configuration files (everything in your supply chain), into a single package. This ensures that the application runs consistently, regardless of the environment it's deployed in.

If you use containers for deployment, there are some best practices that will help to harden your application.

Keep your Docker base images updated

Vulnerabilities in your base container image (the blueprint for what your container is made up of) put your application at risk. Regularly download all security updates for your base image. For servers, you can delegate this to a PaaS provider like Heroku or AWS Beanstalk.

Scan your Docker security using: Syft Grype Trivy

Set it up in seconds with Aikido

Run Docker containers with restricted privileges

Limited privileges makes it hard for successful attackers to take over the host or bounce to other services. Avoid running containers with privileged user roles, such as root on Unix systems, or Administrator or System on Windows systems.

Protect your secrets

Keeping secrets separate from code is a great start. If you’re using containers, you’ll also want to ensure your secret files and other sensitive data are adequately protected. That includes using secrets management tools (many cloud providers offer their own), Kubernetes secrets if using Kubernetes, rotating secrets regularly, and setting expiration dates on your secrets.

Secrets management tools: HashiCorp Vault AWS Secrets Manager Google Cloud Secret Manager

Check your packages for their End Of Life (EOL)

As packages get older and stop being supported, the risk of exploits increases. You should make sure to upgrade packages that are soon reaching their end of life.

Or set it up in seconds with Aikido’s container scanning feature

Implement best practices for your cloud accounts

Keep development, staging, and production cloud accounts separate

Just as you want to keep your development, staging, and production Git branches separate, the same applies to your cloud accounts. While you could create virtual networks inside your cloud accounts to keep staging and production separate, this can become fussy later as you grow, as you’ll end up continually managing user access rights for new devs. We recommend keeping development, staging and production infrastructure in completely separate cloud accounts. All cloud providers offer unified billing, so that’s one less headache.

Use cloud posture management tools

Cloud providers offer so many features that it’s easy to miss or misconfigure something that puts you at risk. Use a cloud security posture management (CSPM) tool to scan your cloud for anomalies.

CSPM Tools: Cloudsploit AWS Inspector

Set it up in seconds with Aikido

Enable cloud budget alerts

In the event your cloud account is hacked, one sure-fire way to detect that someone is mining Bitcoin on your account is to have budget alerts set up to monitor expenditure. Your cloud provider should offer built-in alerts for this, or you can set up cloud scanning with Aikido to check for budget concerns and risky misconfigurations.

Check your LLMs for the most common exploits

As well as building with LLMs, you might be integrating LLMs into your public-facing product. You might have a chatbot offering support to users, or an AI assistant that helps them onboard. If your customers interact with an LLM in any form, it’s a good idea to test them for the most common exploits so you aren’t exposing customers to security risks.

Check the most common exploits: OWASP Top 10 for LLMs

Beyond

Implement a secure development life cycle

A big part of modern security practice is shifting left—bringing security measures into the development lifecycle earlier. This helps you to get into the habit of good practices at every stage of the project, and to catch issues earlier before they are a real threat. That means adhering to a security checklist like this one, familiarizing yourself with typical security flaws and looking out for them during code review, and implementing security checks on pull requests as well.