Security Misconfiguration

What it is

Misconfiguration is every way a correctly written application can be made unsafe by how it is set up: debug mode left on so stack traces reach the browser, default accounts still active, error pages that reveal the framework and version, CORS set to allow any origin, security headers missing, cloud storage buckets public, environment files reachable at a URL.

It moved up to second place in 2025 because modern apps have more configuration surface than ever: a framework, a host, a database provider, an auth provider, a CDN, each with defaults that favour getting started over being safe.

How it shows up in AI-generated code

AI coding tools produce misconfiguration in a specific way: they copy the defaults from tutorials, and tutorial defaults are development defaults. DEBUG = True. Access-Control-Allow-Origin: *. A .env file committed because the tutorial had one. rejectUnauthorized: false to make a self-signed certificate work locally. Each is the right answer for a laptop and the wrong answer for a URL.

Live, this is the category that shows up as an exposed environment file. Among 4,740 probed apps we found hosts serving /.env and /.git/config at the root, which turns a configuration slip into a full credential and source leak. Security headers were the most common low and medium findings across the whole set, present on nearly every site: not exploitable on their own, but the reason a later cross-site scripting or clickjacking issue lands.

Example: Wildcard CORS with credentials

// Express, copied from a tutorial
app.use(cors({ origin: "*", credentials: true }));
app.set("env", "development");   // stack traces in responses

const ALLOWED = ["https://app.example.com"];
app.use(cors({ origin: ALLOWED, credentials: true }));
app.set("env", process.env.NODE_ENV ?? "production");
app.use(helmet());                 // sensible security headers

Wildcard origin with credentials is refused by browsers in the strict form, so tools often reflect the request origin instead, which is worse: any site can make credentialed calls. Allow-list the origins you actually serve.

How to find it

• Request /.env, /.env.production and /.git/config on your live domain. Anything but 404 is a finding.
• Trigger an error on purpose and look at the response. A stack trace or framework version means debug is on.
• Check the response headers for HSTS, Content-Security-Policy, X-Content-Type-Options and a clickjacking protection.
• Send a request with an Origin header from a domain you do not own and see whether it is reflected in Access-Control-Allow-Origin.
• Prbl's live scan does all of these: the exposed-file probe, the six header checks, plain-HTTP detection, and rule PRBL-C003 for disabled TLS verification in the repo.

How to fix it

• Block dotfiles at the host or web server, and never put an env file inside a public directory.
• Set the framework to production mode by environment variable and make the app refuse to start in debug outside development.
• Send security headers from one place, middleware or host config, so every response carries them. A CSP generator gets you a safe starting policy.
• Allow-list CORS origins explicitly. Never reflect the request origin.
• Never disable TLS verification to fix a certificate error; fix the certificate.

What Prbl checks for this category

Run a free scan on a public repo or a live URL. Findings link to the fix guides below.

Fix guides for this category

Go deeper

• What are security headers?
• Security headers guide
• CORS misconfiguration in AI code
• Insecure defaults in AI coding tools
• CSP generator
• Exposed .env checker

Common questions