Inspectable coverage
31 security checks for AI-generated code
Browse every deterministic CodeCordon rule, what it detects, and the remediation it recommends. Coverage is explicit so a scan result can be judged against the checks that actually ran.
No account required. Public repositories only. Preview links expire after 24 hours.
AI/LLM Security
4 checks
LLM API called directly from browser code
An OpenAI/Anthropic API call (or 'dangerouslyAllowBrowser: true') appears in client-side code. The API key ships in the bundle where anyone can extract it and run up your bill.
User input interpolated into system prompt
User-controlled data is interpolated directly into a system prompt. Users can override your instructions ('ignore previous instructions…'), exfiltrate the prompt, or steer the model into unintended behavior.
Model output rendered as HTML without sanitization
LLM-generated content is rendered as raw HTML (dangerouslySetInnerHTML / innerHTML / v-html on completion|response|message variables). Model output is attacker-influenceable via prompt injection — this is stored XSS with extra steps.
Model output executed as code or shell command
LLM output is passed to eval, exec, or a shell. A prompt-injected model (or just a hallucinating one) gets arbitrary code execution on your server.
Authentication
5 checks
API route mutates data without any auth check
This API route handler writes to the database (create/update/delete) but contains no recognizable authentication or authorization check. AI code generators frequently scaffold working endpoints and skip auth entirely.
Auth marked as TODO / disabled
A comment admits authentication or a security check is missing or was turned off ('TODO: add auth', 'skip auth for now', 'disable auth'). These stubs routinely ship to production in vibe-coded apps.
Hardcoded login credentials
A username/password comparison against literal values (e.g. password === 'admin123') was found. Anyone reading the source — or guessing common defaults — can log in.
Password stored without hashing
A password value appears to be written to the database directly (e.g. create({ password: req.body.password })) with no hashing call nearby. A database leak exposes every user's real password.
Password hashed with MD5 or SHA-1
A password is passed to a fast legacy hash. MD5 and SHA-1 are cheap to brute-force and are not suitable password-storage algorithms.
Configuration
5 checks
Debug mode enabled
Debug flags (DEBUG=True, app.debug = true, NODE_ENV=development in deploy config) expose stack traces, internal paths, and sometimes interactive consoles to visitors.
.env exists but .gitignore doesn't exclude it
The project contains a .env file, but no .gitignore rule excludes it. One `git add .` (which AI agents run constantly) commits your secrets.
Database security rules wide open
Firebase/Supabase security rules allow unrestricted read/write ('allow read, write: if true', RLS disabled). Every row in your database is publicly readable and writable by anyone with your public app keys.
Remote script piped straight into a shell
A setup script or Dockerfile pipes a downloaded script into sh/bash. You execute whatever that URL serves at build time — a supply-chain compromise waiting to happen.
TLS certificate verification disabled
The HTTP or TLS client accepts invalid certificates. Attackers on the network can impersonate the upstream service and intercept credentials or data.
Injection
7 checks
SQL query built with string interpolation
A SQL statement is constructed by interpolating or concatenating variables directly into the query string. If any of those values come from user input, this is a textbook SQL injection.
Shell command built from dynamic input
A shell command is executed with interpolated variables (exec/execSync/spawn with shell, os.system, subprocess with shell=True). If input is user-controlled, an attacker can run arbitrary commands on the server.
Dynamic code execution (eval / new Function / exec)
Code is executed from a runtime-constructed string. Combined with any user-influenced input this is remote code execution; even without it, it defeats CSP and static analysis.
Filesystem path built from request input
A file path is constructed from request parameters (req.params/query/body or route params) and passed to filesystem APIs. Attackers can use ../ sequences to read or write files outside the intended directory.
SQL query built dynamically in native application code
A SQL statement is constructed with language interpolation or concatenation. If the inserted value is user-controlled, the query is vulnerable to SQL injection.
Shell command receives dynamic input
A native process or shell API is called with a dynamically constructed command. Untrusted input can escape the intended command and execute arbitrary code.
Untrusted data passed to unsafe deserialization
A native object deserializer is used on request-controlled data. Several of these formats can instantiate dangerous classes or execute gadget chains.
Secrets
4 checks
Hardcoded API key or credential
A real-looking API key or credential is embedded in the source. Anyone with repo access (or the client bundle) can steal and abuse it — this is the #1 cause of surprise cloud bills in AI-generated apps.
Secret assigned as string literal
A variable named like a secret (apiKey, password, jwtSecret…) is assigned a hardcoded string literal instead of being read from configuration.
.env file with real values present in codebase
A .env file containing non-placeholder values was found in the scanned code. If this is committed to git, every secret in it is exposed to anyone with repo access — forever, via git history.
Secret exposed to the browser via public env prefix
An environment variable with a public client prefix (NEXT_PUBLIC_, VITE_, REACT_APP_, EXPO_PUBLIC_) has a secret-sounding name. These variables are inlined into the JavaScript bundle and readable by every visitor.
Web Security
5 checks
CORS allows any origin
The API reflects or hardcodes Access-Control-Allow-Origin: * (or origin: true). Any website can call your API from a visitor's browser; combined with cookie credentials this enables data theft.
Session cookie set without httpOnly/secure
A cookie that looks like a session or auth token is set without httpOnly (readable by any injected script) or is explicitly marked insecure.
Unsanitized HTML injection (XSS)
HTML is injected into the DOM from a variable (dangerouslySetInnerHTML, innerHTML =, v-html, document.write). If the value contains user or model-generated content, scripts can execute in your users' browsers.
Weak JWT verification
JWTs are decoded without verification (jwt.decode used for auth decisions) or signed/verified with the insecure 'none' algorithm. Attackers can forge tokens and impersonate any user.
Request body used without validation
Request body fields are spread or passed directly into database writes (e.g. create({...req.body}) / insert(body)). This allows mass-assignment: clients can set fields you never intended (isAdmin, role, price…).
This library describes known-pattern static checks, not exhaustive vulnerability coverage. A clean result cannot prove an application is secure, and every finding still needs review in its code context.