Vezraa AI Application Security Framework (VAASF)
The VAASF addresses the unique security challenges of AI-powered development. Each AI tool creates distinct risk patterns that traditional security assessments miss. This framework systematically evaluates security across the modern AI development stack.
Cursor Security Considerations
Cursor is an AI-native IDE with deep agentic capabilities, including terminal access, file system modification, and one-click deployment. The VAASF evaluates Cursor-built applications for several security patterns unique to agentic IDEs. First, Cursor agents may generate code with hardcoded API keys or secrets if the model was trained on repositories containing exposed credentials, and the agentic terminal access means these secrets could be committed and pushed before the developer notices. Second, Cursor's ability to execute terminal commands means generated code might install malicious dependencies or modify configuration files without explicit user intent. Third, the speed of Cursor development often means security defaults are accepted without consideration. The VAASF checks for telltale signs of Cursor-generated code including consistent code patterns that indicate AI authorship, default configuration files, and the presence of commented-out debug endpoints that were generated during iterative prompting.
Claude Security Considerations
Claude generates code through conversational prompting, often producing complete application files including routes, database schemas, and authentication logic. The VAASF identifies patterns common to Claude-generated applications. Claude tends to generate comprehensive but sometimes overly permissive authentication middleware — routes may be publicly accessible when they should require authorization, or admin routes may use weak authorization checks like URL-based role detection. Claude-generated code frequently includes detailed error messages in API responses, exposing stack traces, database schema details, and internal IP addresses. The VAASF specifically checks for Claude's artifact generation pattern where HTML files may be generated with embedded inline scripts that bypass CSP, and database connection code may default to development-mode settings. Applications built with Claude also commonly lack proper request validation, accepting raw user input directly into database queries or file system operations.
Lovable Security Considerations
Lovable is a full-stack AI app builder that generates production-ready applications with authentication, databases, and API routes. The VAASF identifies several recurring security patterns in Lovable-built applications. Lovable applications frequently use Supabase as their backend, making Row Level Security (RLS) configuration the single most critical security control. The VAASF specifically tests whether RLS policies actually restrict data access or simply appear to be configured. Lovable-generated authentication flows may use default session configurations with overly long expiry times, no refresh token rotation, and missing MFA options. The generated UI components often include API keys in client-side code for direct Supabase client access, which means a malicious actor who inspects the JavaScript source can access the Supabase API directly. The VAASF checks for these exposed keys and tests whether they can be used to access data beyond the intended scope.
Bolt Security Considerations
Bolt generates complete web applications from natural language descriptions with a focus on rapid prototyping and deployment. Bolt-built applications exhibit specific security patterns the VAASF evaluates. Bolt often generates applications with permissive CORS configurations — either allowing all origins during development or using wildcard patterns that persist into production. The generated applications frequently rely on client-side state management for authorization decisions, meaning a user can manipulate the application state to bypass access controls. Bolt's rapid deployment cycle means generated applications may ship with debug endpoints, test routes, and console.log statements that expose sensitive data. The VAASF also checks for Bolt's tendency to generate applications with hardcoded configuration objects containing API endpoints, service URLs, and third-party API keys in client-side bundles where they are visible to anyone who inspects the JavaScript source.
Replit Security Considerations
Replit combines an online IDE with AI code generation, making it a powerful but security-sensitive development environment. The VAASF evaluates Replit-built applications for several platform-specific concerns. Replit's public-by-default sharing model means many applications are publicly accessible with source code visible, including any secrets or API keys embedded in configuration files. Replit AI tends to generate applications with inline secrets stored in environment variables that may be visible to Replit's platform or shared publicly when projects are forked or remixed. The generated applications often lack proper authentication because Replit apps are commonly built as prototypes that inadvertently become production services. The VAASF checks for Replit-specific patterns including the default Replit domain in callback URLs (causing OAuth redirect URI mismatches), Replit database API keys in client code, and applications that rely on Replit's authentication proxy rather than implementing proper session management.
Supabase Security Considerations
Supabase is a Firebase alternative that provides database, authentication, storage, and real-time functionality as a managed service. The VAASF dedicates substantial attention to Supabase because it's the most common backend for AI-built applications. The critical vulnerability is RLS misconfiguration — Supabase's Row Level Security must be explicitly configured for every table, and AI-generated applications frequently have RLS disabled entirely or configured with overly permissive policies like allowing all authenticated users to read or write all rows. The VAASF tests Supabase RLS policies by attempting to access data from unauthenticated and unauthorized contexts. It also checks for exposed Supabase anon and service_role keys in client-side code, checking whether an attacker with these keys can access restricted data. Service Role keys in client code are particularly dangerous because they bypass all RLS policies entirely. The framework also evaluates Supabase Edge Function security, storage bucket permissions, and authentication provider configuration.
Common AI App Vulnerabilities
Across all AI-powered development tools, the VAASF identifies several recurring vulnerability patterns. Exposed API keys and secrets in client-side code are by far the most common finding — AI models trained on public repositories have learned to embed credentials directly in source code. Missing or misconfigured Row Level Security affects nearly every Supabase-backed application. Overly permissive CORS policies allowing any origin to access API endpoints. No rate limiting on authentication endpoints, enabling credential stuffing and brute force attacks. Missing Content Security Policy headers leaving applications vulnerable to XSS. Hardcoded environment-specific URLs (localhost, staging URLs) in production code. Verbose error messages in API responses that expose stack traces and database schema. And perhaps most critically, a general lack of input validation — AI-generated applications often trust user input implicitly, passing it directly to database queries and file system operations without sanitization or validation.
AI-built apps have unique vulnerabilities. Find them before attackers do.
Scan Your AI App →