What Debuggix Found Inside AI-Generated Code: Hardcoded Keys, Exposed Configs, and Wildcard CORS

A 100-repo analysis of code written by Cursor, Lovable, and Bolt reveals predictable security patterns.

The rise of AI coding tools has changed how software gets built. Developers who could not write a function three years ago are shipping full-stack applications. Experienced developers are moving faster than ever. The barrier to building software has dropped dramatically.

But there is a cost.

The Debuggix team scanned 100 GitHub repositories over the past three months. Among them were projects built entirely with AI coding tools: Cursor, Lovable, Bolt, and similar platforms. The AI-generated code revealed consistent security patterns that every developer using these tools should understand.

This is not a critique of AI coding. The AI builds what the developer asks for. The problem is that most developers do not know what to ask for when it comes to security.

Pattern One: Hardcoded API Keys

Across nearly every AI-generated project we scanned, API keys were hardcoded directly in source files.

Stripe keys. Firebase keys. OpenAI keys. SendGrid keys. AWS access keys.

The AI does not know that these keys should be stored in environment variables. It only knows that the developer asked for a Stripe integration, and providing a hardcoded example key is the fastest way to demonstrate working code.

The developer, seeing the working code, commits it. The API key goes to GitHub. Within hours, automated bots scrape the key and use it to make unauthorized requests. What to do instead: Never commit API keys to your repository. Use environment variables or a secrets manager. Most platforms (Vercel, Render, DigitalOcean) provide secure environment variable storage. Use it.

Pattern Two: Exposed Firebase Configurations

Firebase is popular among AI-generated projects because it provides a complete backend without additional code. The AI can generate a Firebase configuration object and the developer has a working database and authentication system.

But the configuration object includes sensitive values. When committed to the repository, anyone who reads the code can see these values. If the Firebase security rules are not properly configured, an attacker can read or write to the database.

What to do instead: Firebase configuration objects are not secrets by themselves. But they become dangerous when combined with permissive security rules. Review your Firebase security rules before deploying. Ensure that database reads and writes require authentication unless you specifically intend public access.

Pattern Three: Missing Input Validation

AI-generated forms accept whatever the user provides. The AI does not add validation unless explicitly asked. Email fields accept non-email strings. Number fields accept letters. Date fields accept past dates for a future reservation.

This leads to two problems. First, bad data pollutes your database. Second, missing validation is a common vector for injection attacks.

What to do instead: Add validation to every form. For critical fields like email and phone number, use both client-side validation (for user experience) and server-side validation (for security).

Pattern Four: Wildcard CORS

Cross-Origin Resource Sharing (CORS) controls which web domains can make requests to your API.

The AI, when asked to build an API, frequently sets CORS to * (allow all origins). This works for the developer testing locally. It also means any website on the internet can make authenticated requests to your API if a user has an active session.

What to do instead: Set CORS to specific domains your frontend uses. For example, if your frontend is on yourapp.com, set CORS to allow only yourapp.com and your local development domains.

Pattern Five: Unpinned Dependency Versions

AI-generated package.json and requirements.txt files frequently use version ranges like ^1.2.3 or >=2.0.0. This means a future npm install might pull a newer version of a dependency than the developer tested.

If that newer version contains a vulnerability or breaking change, the application breaks or becomes compromised without any code change from the developer.

What to do instead: Pin your dependency versions. Use exact version numbers without caret or tilde prefixes. Use lock files (package-lock.json, yarn.lock) and commit them to your repository.

Why This Happens

The AI is not malicious. It is not careless. It is a pattern matcher trained on millions of public repositories.

The problem is that most public repositories contain these security gaps. The AI learned from them. Now it reproduces them.

The solution is not to stop using AI coding tools. The solution is to add automated security review to the workflow. The AI writes the code. A scanner checks the code. The developer reviews only what the scanner flags.

How Debuggix Approaches AI-Generated Code

Debuggix runs 9 security engines across every scanned repository. For AI-generated code, the most valuable engines are:

• Gitleaks and TruffleHog for hardcoded secrets
• ESLint with security plugins for input validation and CORS misconfigurations
• Semgrep for custom rules that catch Firebase exposure patterns
• OSV-Scanner for dependency version pinning issues

The AI filter reads the project’s documentation to understand context. If the documentation says “this is a development environment,” the filter adjusts expectations accordingly. If the documentation says “this Firebase configuration is intentionally public,” the filter respects that.

The result is a report showing only real issues, not every possible finding.

Debuggix is free for open source repositories. Paid plans for private repos start at $29 per month.

Try it at debuggix.space

This post is based on data collected from scanning 100 public GitHub repositories using Debuggix, with specific analysis of projects built using AI coding tools including Cursor, Lovable, and Bolt.