Beautiful Website, Paper-Thin Security: The Risks of Careless Vibe Coding

Picture the scene. Someone opens a laptop to show you the system they have just built. The interface looks great, the charts glide into place, and the buttons have polished animations. There is even a pricing page already. You ask:

“Nice website! What technology did you use?”

“Claude Code.”

The answer comes with the enthusiasm of someone who has just discovered fire. And I get it. Turning an idea into something that works is enormously satisfying. Watching AI help make that happen can feel as though a door that used to be locked has finally opened.

But the conversation continues. Where is the data stored? Who can access it? How are passwords stored? What prevents one customer from viewing another customer's information?

Silence.

That gap between “I managed to build it” and “I'm ready to deliver it” is what I want to discuss. In 2026, this situation has been coming up in conversations and projects I help with. That is an observation from my own experience, not a statistic about everyone who uses AI.

“Claude Code” still leaves a lot unanswered

Anthropic's documentation describes Claude Code as an AI coding tool that can read projects, edit files, and run commands. Saying you used it tells us something about the building process. We still need to understand the system that process produced. Source: Anthropic.

It is a bit like asking what a house is made of and hearing, “I used an excellent power screwdriver.” Great tool. Now let's talk about the structure.

You might have built a PHP application with Laravel, a React interface, a Python service, or a static page. You might use your own database, a managed service, or have no need to store data at all. Each choice comes with different responsibilities.

Nobody needs to memorize an alphabet soup of acronyms to earn a place in this field. But when you offer a product to customers, you need to be able to explain what it does, where the information lives, and who will maintain it. If you cannot do that yet, it is something to learn and review before delivery.

The label vibe coder covers very different experiences. My criticism here is specific: delivering a system that handles real data without understanding or checking the controls meant to protect it.

When admin123 becomes an administrator's badge

Recently, while helping businesses, departments, and institutions, I encountered a situation whose logic can be summarized like this:

if password == "admin123":
    user is an administrator

This is a simplified representation of the problem I described, not code copied from an identifiable system. That was precisely the issue: comparing the input against a fixed password was the only check used to decide who was an administrator.

You can imagine the demo. Someone enters the password, the dashboard opens, and the buttons appear. Everything seems to work. But the test has only shown that this combination opens the door. We still need to establish who received the key and which doors that person should be able to open.

Credentials embedded in code have a recognized classification: CWE-798, in MITRE's catalog. If a secret password is in code sent to the browser, anyone receiving that code can retrieve it. If it exists only on the server, it is still a fixed credential that needs appropriate handling. Source: MITRE.

Replacing admin123 with a very long phrase full of symbols may leave the flawed logic untouched. The review needs to cover user identity, privilege assignment, and protected operations. Putting a longer password into the same makeshift arrangement does not turn that arrangement into sound architecture.

Storing passwords takes more than a padlock icon

When someone says “passwords need encryption,” it is worth getting the terminology right. For login passwords, the usual recommendation is a dedicated password hashing algorithm, such as Argon2id, configured appropriately. The goal is to verify a password without keeping its original text so that it can be recovered later. Source: OWASP.

NIST's guidelines add a salt and a cost factor to this process: elements that make guessing attempts harder if someone obtains the hashes. That does not make a weak password unbeatable. HTTPS protects communication; storing passwords properly is a separate responsibility. Source: NIST.

If you are starting out, my suggestion is to use the authentication mechanisms provided by established frameworks and services, while understanding their configuration. Inventing a protection because “the AI said it's secure” creates a debt you may only discover when someone comes to collect.

And asking the agent to “add security,” getting a reassuring answer, and calling the review finished does not count. Someone needs to check the result, explain what changed, and verify whether it actually protects the operation.

The browser cannot hand out access badges

Authentication verifies identity. Authorization determines what that identity can do. OWASP recommends checking permissions on every request, in a trusted layer such as a server, gateway, or serverless function. The decision should not depend solely on checks in the browser. Source: OWASP.

Hiding the “Delete customer” button helps organize the interface. The deletion operation also needs to reject anyone without permission. Likewise, signing in to your own account should not grant access to every other customer's records.

Think of a club: showing a membership card at reception does not automatically authorize someone to open the cash register, enter the records room, and walk away with the television. Each kind of access has its own rules.

During a sales demo, everyone tends to follow the expected path: sign in, create a record, save. A responsible review also asks what happens when someone attempts an action that should be refused. That is where the dashboard's good looks stop answering the question.

The .env file has no magical powers

Another scenario deserves attention: someone learns to keep configuration in an .env file, does so, and considers the matter settled. Except the deployment is configured in a way that lets the server deliver that file over the internet.

The filename does not create an access barrier. If the file contains credentials and can be downloaded, organizing the folders has not prevented exposure.

Laravel's documentation gives a concrete warning: serving the application from the project root can expose sensitive configuration. It instructs you to point the server at the appropriate public directory structure. The same guide recommends disabling debug mode in production. Source: Laravel.

There is another possibility: the file remains protected, but a secret gets bundled into the JavaScript delivered to the browser. In Vite, for example, variables prefixed with VITE_ are exposed to client code during the build. The documentation warns that they should not contain sensitive information. Source: Vite.

These are two different paths to exposure. In both cases, we need to understand what is being published. “It's in the .env file” is the beginning of an investigation, not a security guarantee.

Having your own backend does not settle the discussion

We also need to be fair about architecture. An API can exist without a visual interface. A static website can do its job perfectly well. An application can use managed services for authentication and data without maintaining a backend of its own.

Supabase, for example, documents frontend access using a publishable key, RLS—rules that restrict access to database rows—and appropriate policies. Secret keys and service_role keys, which can bypass those restrictions, must stay out of the frontend. Source: Supabase.

Finding a publishable key in the browser therefore does not, by itself, prove a leak. And choosing a well-known service does not prove that its permissions have been configured correctly.

The useful question is straightforward: where is the access rule enforced, and what evidence shows that it works? A simple architecture can answer that. “The agent built it that way” cannot replace the answer.

Confidence needs a review, too

Research helps us examine this behavior carefully. In a study published at ACM CCS in 2023, 47 participants completed five programming tasks related to security. The AI-assisted group produced insecure solutions more frequently on four tasks and showed greater confidence in the security of the results. Study by Perry and colleagues.

This was a controlled experiment using an older model, codex-davinci-002. It does not measure today's Claude Code or the proportion of insecure applications in 2026.

There is a counterpoint: another study, presented at USENIX Security in 2023, evaluated 58 students on a task in C and found a small security impact in that setting. The tool, the task, and the way it is used all matter. Study by Sandoval and colleagues.

My takeaway is that we should treat confidence as a hypothesis until there is evidence. Ending a conversation with AI feeling reassured is not the same as having verified the system.

Claude Code's own documentation makes the user responsible for reviewing the safety of proposed code and commands. Safeguards for operating the agent and the security of the resulting application are separate matters. Source: Anthropic.

Once customers arrive, the stakes get bigger

At Oombe, I work with marketplace integrations. In projects involving public administration, I work with digital services intended for real people. That experience means I look at a registration screen and also think about who will depend on it after the demo.

If something failed, a merchant could lose access to an important operation. A citizen's information could be exposed. A team could be left unsure what happened or how to restore the service. These are examples of possible consequences, not accounts of incidents in those projects.

Someone starting out may see a form with five fields. For the person filling it out, those fields could contain a name, phone number, address, and information that should not be circulating freely.

In Brazil, Article 46 of the LGPD, the country's General Data Protection Law, requires technical and administrative measures to protect personal data and says they must be considered from the design stage of a product or service. An operation's size calls for a context-specific assessment; it does not justify ignoring protection. Source: LGPD.

Brazil's data protection authority, the ANPD, also provides a guide for small organizations, covering access controls, backups, and system updates. There are accessible ways to get started responsibly. Source: ANPD.

That is why “I'll launch it now and deal with security later” worries me so much. By the time “later” arrives, someone may already have entrusted their information to the product.

What I would ask before the first customer

I would start with a focused conversation, backed by demonstrations. Can the person who built the system answer these questions?

• What has been built? What components exist, where do they run, and who will maintain them?
• What data is necessary? Why is it collected, where is it stored, and who can access it?
• How is access restricted? Can an ordinary account do something reserved for an administrator? Can one customer reach another customer's data?
• Where are the secrets? What is public by design, and what needs to remain protected, including in the hosting configuration?
• How will a failure be detected and fixed? Are there designated people responsible, useful records, and a known way to restore the service?

These questions are a starting point for a review, not a certificate. The level of verification should reflect what the application does and the impact of a failure.

My recommendation for getting started is to narrow the scope. Build a prototype with fictional data, understand one feature at a time, and ask for a review before putting other people's information into the system. During validation, also demonstrate that prohibited operations are refused. OWASP recommends tests for authorization logic. Reference.

If you lack the knowledge, bring someone experienced into that stage. That might mean a one-off review, a partnership, or more time spent learning. Getting help is part of taking responsibility for a project.

The same logic applies to buyers: ask for explanations and evidence proportionate to the service. A serious supplier should be able to discuss limitations without answering every question with “trust me.”

The kite looks great. The shield needs to hold up

When I talked about these beautiful but fragile systems, I used an image that still feels perfect: Captain America decides to swap his shield for a tissue-paper kite. The kite is wonderful. Colorful, beautifully designed, great in a photo.

Until someone needs it to work as a shield.

That is how I see a polished dashboard resting on makeshift permissions. The design deserves praise. The customer's trust also requires a structure capable of supporting what was promised.

If AI brought you into programming, welcome. Ask questions, experiment, and make the most of that open door. You do not need to feel ashamed of what you have yet to learn; you do need to recognize when that gap calls for study or help before committing to a delivery.

And those who have been programming for years should review their own work, too. Years of experience do not eliminate mistakes, just as a powerful tool does not eliminate the need for judgment.

I want to see more people building useful solutions. I also want them to be able to explain what they built, take technical criticism, and look after the people who will use it.

The next time someone shows me a project, I will still begin with a sincere compliment:

Nice website. Now show me how you're protecting the people who will use it.

---

A technical opinion article informed by personal experience and the primary sources linked throughout. Documentation consulted on October 22, 2026. Examples have been simplified to explain the risks without identifying clients or institutions.