Cybersecurity

Beyond Login: Other Security Risks in Applications Built with AI

Learn about the most common security vulnerabilities in AI-built applications and how to reduce risk using OWASP-recommended practices.

Evandro Gayer Gomes
Evandro Gayer Gomes
Person using a laptop with a cybersecurity interface under development, displaying a security dashboard with protection icons in a modern workspace illuminated with blue lighting.

Introduction

In the first article in this series, we saw that a login screen represents only the most visible part of application security. Authentication and session management determine who gets in and how access remains valid. Cookies and authorization affect how that access is maintained and what each person is allowed to do.

These controls are essential, but they do not address every risk. An application also accepts external input and communicates with other systems. It may process files and rely on third-party components. It must also limit resource usage and record unusual activity so incidents can be detected in time.

The risk increases when a solution built quickly with generative AI moves beyond the prototyping stage and begins handling customer data or financial operations. IBM's Cost of a Data Breach Report 2025 estimated the global average cost of a data breach at USD 4.4 million. Among organizations that reported AI-related security incidents, 97% lacked adequate access controls for those systems.

This article broadens the discussion to other points of exposure. The goal is to explain recurring vulnerabilities, show why they also appear in applications built with AI, and present practical measures for reducing each risk.

What Is OWASP, and Why Does It Matter?

OWASP stands for the Open Worldwide Application Security Project. It is a nonprofit foundation and an open community dedicated to software security. Its projects include standards and guides maintained with contributions from professionals around the world.

One of its best-known publications is the OWASP Top 10. It groups security risks that are especially important for raising awareness and reviewing applications. It does not replace a complete assessment, but it provides a widely recognized starting point for identifying recurring problems.

OWASP also maintains the Cheat Sheet Series, which provides more specific guidance on prevention and implementation. This article uses the OWASP Top 10:2025, the OWASP API Security Top 10:2023, and these practical guides as its main references.

The risks covered are:

  • injection and Cross-Site Scripting, or XSS;
  • Cross-Site Request Forgery, or CSRF;
  • Server-Side Request Forgery, or SSRF;
  • insecure file upload and processing;
  • exposure of keys, passwords, and other credentials;
  • software supply chain failures;
  • unrestricted resource consumption;
  • security logging and alerting failures.

These categories do not represent every possible security risk. They provide a practical selection of problems that may remain hidden even when login and basic permissions appear to work correctly.

When Data Becomes a Command

Information supplied by a user should be treated only as data. An injection flaw occurs when part of that input is interpreted as an instruction by an internal component, such as a database.

Consider a search field whose text is inserted directly into a query. If the application does not keep the supplied value separate from the command structure, manipulated input may change how the query behaves.

The OWASP Top 10:2025 category for Injection also includes XSS. In this case, external content is inserted into a page in a way that causes the browser to execute it as code. This may expose session information or alter the content shown to the user.

Applications built quickly may be vulnerable when generated code mixes data with commands or disables protections provided by the development framework. A visually correct interface does not demonstrate that dynamic content is being handled safely.

How to Reduce the Risk

Queries and commands should use parameterized interfaces that keep external values separate from the instruction being executed. Input validation remains important, but it should not be the only defense.

To prevent XSS, the application should preserve the automatic output encoding provided by its framework and sanitize content when displaying HTML is genuinely necessary. The OWASP XSS Prevention Cheat Sheet emphasizes that no single technique solves the problem by itself.

A Content Security Policy, or CSP, can reduce the impact of some attacks. It should be treated as an additional layer of protection, not as a substitute for handling content correctly.

During a review, the team should identify where external data enters the application and trace how it is used through to the final query, command, or page.

When the Browser Acts on the User's Behalf

After a person signs in, the browser may automatically send the cookie that keeps the session active. CSRF abuses this behavior by causing the browser to perform an action the user did not intend.

For example, a malicious page may try to submit a request that changes the email address on an authenticated account. The attacker does not need the password because the victim's browser presents a valid session to the application.

This risk mainly affects operations that change data. Confirming that a session exists does not prove that the request came from the application's legitimate workflow.

How to Reduce the Risk

The first step is to use the CSRF protection provided by the development framework. When no built-in protection exists, operations that modify information should receive and validate a dedicated anti-CSRF token on the server.

The OWASP CSRF Prevention Cheat Sheet also recommends validating request origins and configuring the SameSite cookie attribute. Sensitive operations may require an additional confirmation from the user.

Requests that change application state should not be implemented as simple read operations. During a review, every relevant operation should demonstrate that the request came through the expected workflow, not merely from a browser with an active session.

When the Application Becomes a Bridge to Restricted Destinations

The previous risk abuses the trust placed in the browser. SSRF abuses the trust and network reach of the server itself.

This flaw occurs when an application accepts an externally supplied address and sends a request without adequately controlling the destination. A feature that imports an image from a URL, for example, could be manipulated into trying to reach an internal service.

The attacker uses the application as an intermediary because the server may be able to access resources that are not directly available from the internet. In cloud environments, this may also expose infrastructure information.

How to Reduce the Risk

When legitimate destinations are known, the application should maintain an explicit list of allowed domains or services. The address must be validated after resolution, including any redirects that may occur.

The OWASP SSRF Prevention Cheat Sheet recommends combining application-level checks with network restrictions. The server should be able to communicate only with systems required for its function.

The application should also limit accepted protocols and block access to internal addresses when they are not part of the expected workflow. During a review, every feature that retrieves external content should have clearly defined destinations and behavior.

When an Uploaded File Becomes a Dangerous Entry Point

An image or document should not be considered safe simply because it has the expected file extension. Its contents may exploit the processing tool or consume excessive resources.

The incident known as ImageTragick showed how a specially crafted image could trigger command execution in vulnerable versions of ImageMagick. The issue was registered as CVE-2016-3714 in the National Vulnerability Database.

The risk increases when the application performs additional processing, such as optical character recognition or document conversion. In that situation, the file passes through other libraries before producing the expected result.

How to Reduce the Risk

The application should accept only the file formats required by the business function and verify the file's actual contents. It should also enforce a size limit before processing begins.

The OWASP File Upload Cheat Sheet recommends generating internal file names and storing uploaded files outside publicly accessible application directories. The process that reads them should have only the permissions it needs.

When the level of risk warrants it, processing can take place in an isolated environment and include malware scanning. During a review, the file should be traced from receipt through storage and final transformation.

When Credentials Are Exposed in Source Code

API keys, passwords, and tokens allow an application to access other systems. When one of these credentials is placed directly in source code, it may provide an immediate route to sensitive resources.

The risk does not necessarily disappear when the secret is removed from the current version. GitHub's documentation on secret leakage risks explains that a credential may remain in repository history or automation logs.

AI coding assistants may suggest placing a key directly in the code to test an integration. The shortcut becomes dangerous when the credential remains active as the prototype evolves.

How to Reduce the Risk

Credentials should be stored in a secret management system, separate from the source code. Each application should receive only the access required to perform its function.

Whenever possible, credentials should be short-lived and rotated automatically. The team should also prevent them from appearing in logs and use tools that detect secrets added to a repository.

An exposed credential should be treated as compromised. Deleting it from a file is not enough: the old value must be revoked, a new one created, and any possible misuse investigated.

When a Dependency Compromises the Application

Nearly every modern application uses third-party libraries. This software supply chain speeds up development, but it also makes product security dependent on external components.

The OWASP Top 10:2025 includes supply chain failures among the leading risks for web applications. A problem may arise when a component contains a known vulnerability or when its distribution process is compromised.

AI-generated code adds a specific variation. The study We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, published at the 34th USENIX Security Symposium in 2025, analyzed 576,000 samples produced by 16 models and found recommendations for packages that did not exist.

This phenomenon is known as package hallucination. An attacker can register an invented name in a public package registry and wait for someone to install it without confirming its origin.

How to Reduce the Risk

Every dependency suggested by AI should be verified against the project's official documentation. Before installation, the team should confirm who maintains the package and whether it is still actively updated.

The versions in use should be recorded in a reproducible way and checked continuously against vulnerability databases. OWASP also recommends maintaining an inventory of components and removing dependencies that do not serve a necessary function.

Updates should not reach important systems automatically without testing. During a review, every external component should have a confirmed origin and version. The organization should also have a process for monitoring dependencies throughout the application's life cycle.

When No One Sets Usage Limits

An application can be abused even when no data is accessed without authorization. It may be enough to repeat a legitimate operation without adequate limits.

This issue is especially important when a request triggers a metered service, such as an AI model. A single call may cost very little, but automated repetition can create a significant expense before anyone notices.

The OWASP API Security Top 10:2023 describes this problem as Unrestricted Resource Consumption. In addition to financial cost, abuse can exhaust system capacity and cause an outage.

How to Reduce the Risk

The application should limit how many requests each user can make within a given period. It should also restrict input size and the amount of data returned by each operation.

Long-running processes should have execution timeouts and memory limits. For third-party services, the organization should configure spending caps or budget alerts.

These values should reflect legitimate product usage. During a review, every operation with meaningful cost or resource consumption should have a measurable limit and a defined response for when that limit is reached.

When an Incident Happens and No One Notices

Even a well-reviewed application may encounter errors or attempts at abuse. The difference lies in the ability to detect unusual behavior and begin responding before the impact grows.

The OWASP Top 10:2025 category for Security Logging and Alerting Failures covers situations in which important events are not recorded or do not trigger an appropriate response.

IBM's 2025 report attributed part of the reduction in the global average cost of data breaches to faster identification and containment. Well-designed logs help reconstruct what happened, but only when they are supported by alerts and a response process.

How to Reduce the Risk

The application should log authentication failures and sensitive operations with enough context to support an investigation. Logs should be protected against tampering and retained for the required period.

The OWASP Logging Cheat Sheet warns that passwords and access credentials should not be stored in logs. Only the personal data required for the logging purpose should be recorded, and that information should be protected appropriately.

The organization should define which behaviors trigger alerts and who is responsible for reviewing them. This workflow must be tested, because an alert that no one receives or understands does not improve incident response.

A Minimum Review Before Real-World Use

The risks discussed above can be turned into practical questions:

  1. Does external input remain separate from commands executed by the application?
  2. Are authenticated operations protected against forged requests?
  3. Can integrations reach only the destinations they require?
  4. Are files validated, limited, and processed under safe conditions?
  5. Are credentials kept out of source code, and can they be revoked quickly?
  6. Are dependencies verified and monitored for vulnerabilities?
  7. Do operations have volume and cost limits?
  8. Do suspicious events produce logs, alerts, and a defined response?

This list does not replace a technical assessment. The level of rigor depends on the data involved and the consequences of a failure.

A local tool that does not handle real data may go through a simpler process. An application that serves customers or performs critical operations needs architecture, testing, and monitoring that match that responsibility.

Experienced developers remain important because they turn general recommendations into decisions suited to the context. They identify possible abuse paths, choose proportionate controls, and verify that protections continue to work as the application evolves.

Conclusion

Login addresses only part of application security. Even after identity and permissions are under control, the application must still treat external content with caution, limit its communication with other systems, and protect the components on which it depends.

It must also control resource consumption and maintain visibility into unusual behavior. Without these layers, a system may work correctly during a demonstration and remain vulnerable when it enters real-world use.

Generative AI reduces the time required to turn an idea into working software. That advantage makes reviews based on business context and the consequences of failure even more important.

When an application begins to affect customers or critical operations, security is no longer something to add later and it becomes part of the product itself.

Sources

Read More

Link copied