Cybersecurity

Your AI-Generated Application Works. But Is It Secure?

Learn the security essentials behind authentication, authorization, and AI-generated applications.

Evandro Gayer Gomes
Evandro Gayer Gomes
Illustration of an application connected to servers and data, protected by visual elements representing authentication, authorization, and digital security.

Introduction

People without a technical background, as well as professionals across different areas of a company, can now use generative AI to build customer portals, internal systems, and automation tools. This development approach, commonly known as vibe coding, can turn a natural-language description into a working application within days.

That accessibility creates opportunities to test ideas, automate processes, and build solutions that previously required more time and investment. Once an application begins processing invoices, documents, customer data, or access credentials, it also becomes part of important business processes and starts handling sensitive information. At that stage, a security failure can lead to unauthorized access, data exposure, and financial losses.

Evaluating an application therefore requires more than asking whether it works. Companies also need to understand who can sign in, how the system maintains that access, what each person is allowed to do, and where those rules are enforced. These questions involve common software development concepts such as authentication, sessions, cookies, and authorization.

This article explains those concepts in accessible language and shows how they apply to traditional websites, single-page applications, and mobile apps. It also introduces resources and standards such as OWASP, OAuth 2.0, and OpenID Connect, and discusses why review by experienced professionals remains important for applications built with generative AI.

How can teams balance productivity and secure development?

Building a prototype quickly is a valid way to test an idea before investing in a complete solution. Generative AI shortens that path by helping people create interfaces, business rules, and integrations through natural-language instructions.

The level of care needs to increase when the prototype receives real data, becomes available on the internet, or becomes part of business operations. At that point, decisions about architecture, access rules, data protection, and usage limits directly affect the security of the solution. Responsibility for those decisions remains with the people and organizations that put the system into operation.

In May 2026, Axios and WIRED reported on vibe-coded applications that had been left publicly accessible and, in some cases, exposed personal and corporate information. The research cited in the reports was produced by the security company RedAccess. The platforms involved disputed parts of the methodology and attributed some cases to settings selected by users. Even so, the journalists were able to independently verify some exposed applications.

The episode shows how greater development speed can shorten the distance between creating a prototype and making it available to real users. Without an equivalent review stage, unsafe configurations and access control failures can reach production just as quickly. To understand how this happens, we first need to distinguish expected functionality from secure behavior.

A working application can still be insecure

When people test an application during ordinary use, they usually check whether its main workflow works: a user can sign in, open an invoice, and update the information allowed for that account.

Those tests are useful, but they cover expected behavior. Security requires a different set of questions.

Instead of only checking whether a customer can view their own invoice, someone must determine whether that customer can view another customer's invoice. Instead of only confirming that an administrative button appears for the right people, someone must verify that the underlying administrative operation remains protected when called outside the visible interface.

It is similar to examining a store from two perspectives. The first inspection confirms that the door opens and the register completes a sale. The second looks for a restricted entrance that may have been left unlocked or a path that lets someone reach the stockroom without permission.

Applications built with generative AI can amplify this risk because people who have not yet developed a security mindset can assemble them very quickly. The interface may look professional and the main workflow may appear complete. That polished appearance does not demonstrate that the application is properly protected.

Recent research reinforces this point. In its 2025 report, Veracode found that 45% of the code-generation tasks it evaluated introduced a known security vulnerability. The company tested more than one hundred models across selected tasks and programming languages, so this percentage should not be treated as a universal rate for all AI-generated code. Within the scope of the study, however, it shows that a model can produce functional code while still reproducing insecure practices.

An academic preprint available on arXiv, focused on Java assignments, reached a similar conclusion. The study found vulnerabilities and defects in output from different models and observed that strong functional benchmark performance did not automatically translate into better overall quality or security. Producing the expected answer in a test does not demonstrate that a system is ready to handle real data and business operations.

Recognizing that distinction provides a starting point for a more effective security review. Before selecting technologies or configuring sign-in, a team needs to identify which data, features, and business processes actually require protection.

The first step is understanding what needs to be protected

Before discussing passwords or any specific technology, it helps to ask a more basic question: what does this application protect?

Security is often treated as something added near the end of development, almost like a finishing coat. In practice, security begins when the team identifies which information and actions require special protection.

Consider a customer portal. Customers can create accounts, review invoices, and use an assistant powered by generative AI. Internal employees use the same system to update information and manage customer accounts.

The security questions now become more concrete.

Which information is public, and which information must remain private? Who is allowed to read a record, and who can change it? What would happen if one customer gained access to another company's documents? These questions connect technical controls to actual business consequences.

This exercise is a simplified form of threat modeling. Despite the technical name, the idea is practical: identify what could go wrong, who might exploit it, and what the resulting harm could be.

Even an initial review like this can be valuable. An internal task organizer that contains no sensitive data may require one level of protection. A system that stores personal data, financial documents, or supports critical business operations requires a higher level of protection and responsibility.

This is one area where experienced professionals make a difference. They can identify abuse paths that are easy to miss when everyone is focused on the application's normal workflow.

Once the team has identified the data and operations that need protection, the next step is to translate those needs into system rules. Three groups of concepts are especially useful for following that process:

  • Authentication confirms the identity of a person or system.
  • Sessions and cookies help the application recognize a user across subsequent interactions.
  • Authorization determines which data and operations that identity can access.

These concepts follow a logical sequence. First, the application identifies the user. It then needs to maintain that access securely. With every new request, it must also confirm that the person has permission to perform the requested action. The process begins with identity.

What is authentication?

Authentication is the process of confirming who is making a request to a system. In plain language, it helps the application answer the question: “Is this person really who they claim to be?”

Authentication may use an email address and password, a passkey, or an account managed by an external identity provider. It also occurs between systems when one service needs to prove its identity before connecting to another.

Authentication involves more than displaying a sign-in page. The visible form is only one part of the process.

How are passwords stored? How does account recovery work? Do sensitive accounts use multifactor authentication? Does access expire, and can it be terminated safely? These decisions are as much a part of authentication as the page where a user enters a password.

OWASP, an international nonprofit foundation that maintains open projects focused on improving software security, treats authentication as a complete system rather than a user-interface detail. Its Authentication Cheat Sheet provides practical guidance on passwords, account recovery, multifactor authentication, and related controls.

Imagine an application that allows a user to reset a password through a link that never expires and can be reused. The sign-in page may look flawless, while the alternative path into the account remains vulnerable. Additional protections such as multifactor authentication become particularly important for accounts with financial access or administrative privileges. The level of protection should reflect the impact of a potential compromise.

Sessions and cookies: what do these terms mean?

After authentication, the application needs to recognize the user during subsequent requests. This is necessary because every page opened, button clicked, or piece of information loaded may initiate a new exchange with the server. Without a continuity mechanism, users would have to provide their credentials again for every action.

A session represents the period during which the application considers a user authenticated. In a traditional website, the main session data usually remains on the server. The browser receives a random identifier that allows the server to locate the correct session. That identifier may be stored in a cookie, a small piece of data that the browser automatically sends to the website in later requests.

Consider the entrance to a condominium or gated residential building. Security staff check a visitor's identity and create an entry record. They then provide a temporary badge. The record maintained by security represents the session, while the visitor's badge serves the role of the cookie. When the visitor approaches another controlled area, the badge can be checked against the record to confirm that the visit is still valid.

This comparison also shows why session cookies need protection. If someone copies an active session identifier, they may be able to present it to the server and impersonate the legitimate user. To reduce that risk, the application should use encrypted connections, prevent unnecessary access to the cookie by browser scripts, define an expiration period, and invalidate the session when the user signs out.

A cookie does not need to contain the user's password or complete profile. In many systems, it only holds the identifier needed to locate the session on the server. Other architectures may use different digital credentials, such as tokens, which become relevant when we discuss single-page applications and mobile apps.

Cookies also require attention from a privacy perspective. A cookie required to maintain authentication serves a different purpose from one used to track browsing behavior or personalize advertising. When developing an application, the team needs to identify which cookies will be created, what data they contain, how long they remain active, and whether they are shared with third parties.

In Brazil, this processing must take the Brazilian General Data Protection Law, known as LGPD, into account. Applications offered to people in the European Union may also be subject to the General Data Protection Regulation, or GDPR, as well as European rules for privacy in electronic communications. Consent requirements depend on purpose and context: cookies that are strictly necessary for a service may be treated differently from those used for analytics or advertising. Brazil's National Data Protection Authority provides specific guidance on cookies, transparency, and user choice.

Once the user's identity has been confirmed and a session has been established, one decision remains for each operation: whether that user is allowed to access the requested data or perform the requested action. That is the role of authorization.

What is authorization?

Authentication determines who has signed in. Authorization determines what that person is allowed to do afterward.

Imagine a portal where each customer can view their own invoices. A user signs in, opens an invoice, and notices that its address ends in a number such as 1042. The user changes that number to 1043. If the system displays another customer's invoice, the application has a serious authorization vulnerability.

This is a classic example of an Insecure Direct Object Reference, commonly abbreviated as IDOR. This type of vulnerability is currently included in OWASP's Broken Access Control category. The technical name matters less than the underlying logic: the system confirmed the user's identity but failed to verify whether that user was allowed to access the specific resource.

The consequences for a business are concrete. An invoice may expose financial information, while an internal document may contain personal or commercially sensitive data. In addition to damaging trust, an incident can enable fraud and create regulatory obligations.

A valid sign-in should therefore never be interpreted as broad authorization. A person may be correctly identified while still having no right to view, modify, approve, export, or delete a particular record.

Why does hiding a button fail to protect a feature?

Hiding a button, disabling a menu, or blocking a visible page can improve the user experience, but it does not protect the operation behind the interface.

The reason is straightforward: the visible portion of the application runs in an environment controlled by the user. Anyone who controls the browser or installed application can inspect requests, repeat calls, change parameters, and try paths that the normal interface does not display.

In less technical terms, this would be like assuming that a room is protected because its main door has no sign. If the hallway remains open and there is no lock, a curious person can still try to enter.

Every sensitive operation must be validated by the component that controls the data and rules: the server, usually through an Application Programming Interface, or API. An API is the channel through which the interface sends requests to the server. The server must determine who made the request, which action was requested, and whether that person is authorized to perform it.

The OWASP API Security Top 10:2023 emphasizes this point by placing authorization failures among the most significant API risks. It also highlights how poorly separated administrative functions and unrestricted business flows can cause harm even when the application appears to work correctly.

How do roles and permissions organize access?

Small applications often begin with a simple distinction: there is a regular user and an administrator. That may appear sufficient at first, but the model usually becomes inadequate as the system grows.

A company may have employees, managers, and customers with different responsibilities. A support representative, for example, may need to view a customer record without receiving permission to change billing information. The system needs to represent these distinctions explicitly.

This is where concepts such as roles, permissions, resource ownership, and customer isolation become relevant. In a system shared by multiple organizations, each organization may be treated as a tenant. A failure in this layer can allow one organization to see another organization's information.

For people creating software with generative AI, this can be a particularly difficult area. The tool may quickly generate screens, tables, filters, and database queries. Someone still needs to define the rules governing different users, teams, and organizations. Those rules do not emerge on their own.

Without careful design, the system may place too much trust in information provided by the interface. It might, for example, accept a company identifier supplied by the browser or trust an unverified claim that a particular person is an administrator. That is a dangerous basis for access control.

Why does architecture change the security requirements?

Many problems begin with the assumption that every application works the same way internally.

A traditional website, where the server builds pages and sends completed HTML to the browser, commonly uses a session associated with a cookie. A single-page application, or SPA, runs much of its interface in the browser and retrieves data through APIs. Mobile apps and system-to-system integrations also require credentials and flows appropriate for their environments.

For a nontechnical reader, consider the differences among protecting a house, a retail store, and an industrial warehouse. The same general principles apply, but the location of entrances, the flow of people, and the assets being protected change the design of locks, cameras, and operating procedures.

Software works in a similar way.

Code delivered to a browser can be inspected by the user. A secret embedded in that visible code should therefore be treated as exposed. A similar principle applies to mobile apps: installing software on a user's device does not turn that device into an impenetrable vault.

This is where technologies such as OAuth 2.0 and OpenID Connect become relevant. OAuth 2.0 defines mechanisms for granting limited access to applications. OpenID Connect adds an identity layer that allows an application to confirm who signed in. These technologies provide established standards, but their security still depends on selecting and configuring a flow that is appropriate for the application.

These flows commonly use an access token, a digital credential that an application presents when requesting data or operations from an API. As with a session identifier stored in a cookie, exposure of an access token may allow someone else to use the granted access. The correct way to store and renew tokens depends on the application's architecture.

Does signing in with an external account solve everything?

An external identity provider is a specialized service that authenticates users for other applications. This is what happens when a website offers options such as “Sign in with Google” or “Sign in with Microsoft.” Instead of receiving and verifying the password directly, the application sends the user to the selected provider. After authentication, the provider returns verifiable information about that person's identity.

This model can improve the user experience and reduce the application's responsibility for password storage. Protocols such as OpenID Connect were designed to support this type of identity integration between systems.

The provider's role generally ends with confirming identity and sharing information authorized by the user. Internal permissions remain the application's responsibility. If a person signs in correctly through an external provider but can access another company's documents, authentication succeeded and the application still failed at authorization.

The provider can be compared to a building reception desk operated by a specialized contractor. The reception staff checks identification and records who entered, while each company in the building remains responsible for deciding who may enter its offices and access its files. In the same way, an identity provider solves an important part of the process but does not replace the application's access rules.

Common mistakes in rapidly generated applications

When an application is assembled quickly, teams should pay particular attention to four patterns:

  • treating the presence of a sign-in page as sufficient proof of security;
  • protecting the visible interface while leaving APIs without equivalent authorization checks;
  • trusting browser-supplied data to determine the company, permission, or value associated with an operation;
  • publishing credentials, configuration, or internal tools in an internet-accessible environment.

Recent reporting about vibe coding helps illustrate this risk. Whether the cause is a platform flaw, a user-selected setting, or poor application design, the pattern is consistent: systems that appeared useful and ready became visible or accessible beyond what their creators intended.

What should a company review before using the system with real data?

Not every prototype requires an extensive security audit. At the same time, a system that handles real data should not be treated as an inconsequential draft.

Before putting an application into real use, a company should review at least five areas.

First, identify the data and operations that require special protection. An invoice and a public marketing page, for example, rarely have the same sensitivity.

Second, define who may view, create, modify, approve, export, or delete each type of information. This access matrix may look bureaucratic, but it removes dangerous ambiguity.

Third, verify that permissions are enforced by the server rather than only by the screen the user sees.

Fourth, determine whether the application exposes credentials, files, configuration, or administrative areas.

Fifth, test the system using genuinely different user profiles. One simple check is to create customers belonging to two separate organizations and confirm that neither can access the other's data, including after changing URLs and API requests.

Why does review by experienced professionals remain important?

Generative AI has expanded access to software development. More companies and professionals can turn ideas into real tools with far less friction, creating significant productivity gains.

Security and scalability still depend on judgment, context, and accountability. A system may look polished while containing flaws in its access rules, data organization, resource consumption, account recovery, customer separation, monitoring, or business continuity.

Experienced technology professionals remain important in this environment. They help select an appropriate architecture, review access controls, and identify ways an apparently safe workflow could be abused. They also evaluate whether the system can grow without becoming expensive, fragile, or difficult to maintain. This analysis separates a local experiment from a system that should be managed as part of business operations.

The OWASP Application Security Verification Standard, commonly known as ASVS, organizes verification requirements according to the level of confidence an application needs. The idea of proportionality is useful: the greater the potential impact of a system, the more rigorous its evaluation and monitoring should be.

If your company is developing an application with generative AI or needs to review a solution before putting it into production, we can help evaluate its architecture, access controls, and major risks. Contact Fronteira Labs to discuss your project.

Conclusion

Software development with generative AI has already changed how companies experiment, build, and launch new tools. It creates a real competitive advantage while also introducing the risk of confusing speed with maturity.

A working application can remain insecure. A polished interface can conceal exposed data, overly broad permissions, and improvised decisions about identity.

Businesses should use generative AI to move faster and allow more people to participate in software creation. As a system moves closer to real use with customer data and important business operations, review by experienced professionals becomes increasingly valuable.

Generative AI can help write code and suggest architectures, libraries, and workflows. Responsibility for the consequences of a deployed system remains with the people and organizations that developed and published it.

Sources

Read More

Link copied