Hardcoded API keys. Exposed Firebase configs. Missing input validation. Wildcard CORS. Unpinned dependencies. The data from 100 repos is consistent.
AI coding tools have 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.
But there is a cost.
The Debuggix team scanned 100 GitHub repositories over three months. Among them were projects built entirely with AI coding tools: Cursor, Lovable, Bolt, and similar platforms.
The AI-generated code revealed five security patterns that appeared in almost every project.
Pattern One: Hardcoded API Keys
The finding: Stripe keys, Firebase keys, OpenAI keys, SendGrid keys, AWS access keys committed directly to source files.
Why it happens: The AI does not know that 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 risk: Automated bots scrape GitHub for API keys. Within hours of a commit containing a key, bots will find it and use it to make unauthorized requests. A compromised Stripe key can make charges. A compromised AWS key can spin up expensive infrastructure. A compromised OpenAI key can cost thousands per hour.
The fix: Never commit API keys. Use environment variables. Most platforms (Vercel, Render, DigitalOcean, AWS) provide secure environment variable storage. Use it.
How Debuggix catches it: Gitleaks and TruffleHog scan git history for patterns matching known secret formats. The AI filter ignores keys in example directories or test files.
Pattern Two: Exposed Firebase Configurations
The finding: Firebase configuration objects containing apiKey, authDomain, databaseURL, projectId, and storageBucket committed to source files.
Why it happens: Firebase is popular among AI-generated projects because it provides a complete backend without additional code. The AI generates a configuration object, and the developer has a working database and authentication system.
The risk: Firebase configuration objects are not secrets by themselves. They are designed to be included in client-side code. But when combined with permissive security rules, they become dangerous. An attacker who reads the configuration can attempt to read or write to the database. If security rules allow public access, the database is compromised.
The fix: Review Firebase security rules before deploying. Ensure that database reads and writes require authentication unless you specifically intend public access. Use Firebase Security Rules to validate input and restrict access.
How Debuggix catches it: ESLint with security plugins flags Firebase configuration objects in source files. The AI filter checks whether the project documentation indicates intentional public access.
The finding: Forms that accept any input. Email fields that accept non-email strings. Number fields that accept letters. Date fields that accept past dates for a future reservation.
Why it happens: The AI does not add validation unless explicitly asked. It builds a working form. Validation is a separate concern that the developer must specify.
The risk: Missing validation leads to two problems. First, bad data pollutes your database. Second, missing validation is a common vector for injection attacks. An attacker can submit malicious payloads that your application does not expect.
The fix: 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). Never rely on client-side validation alone.
How Debuggix catches it: Semgrep rules flag input handlers that do not include validation logic. The AI filter understands context and ignores validation that appears in client-side code if server-side validation is present.
Pattern Four: Wildcard CORS
The finding: Cross-Origin Resource Sharing set to * (allow all origins) in API responses.
Why it happens: The AI, when asked to build an API, sets CORS to * because it works for local testing. The developer deploys without changing it.
The risk: Any website on the internet can make authenticated requests to your API if a user has an active session. An attacker can host a malicious site that makes requests to your API using your users' cookies.
The fix: 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. Never use * in production.
How Debuggix catches it: ESLint and Semgrep flag CORS headers set to *. The AI filter checks whether the project is explicitly documented as a public API intended for cross-origin access.
Pattern Five: Unpinned Dependency Versions
The finding: package.json and requirements.txt files using version ranges like ^1.2.3 or >=2.0.0.
Why it happens: The AI generates version ranges because they are common in public repositories. The developer does not change them.
The risk: 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.
The fix: Pin 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.
How Debuggix catches it: OSV-Scanner and Trivy check for unpinned dependencies and report them as configuration issues. The AI filter prioritizes findings in production dependencies over development dependencies.
The Common Thread
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: debuggix.space