2.4 Over-Permissive Configurations

AI coding agents consistently produce configurations that are wide open by default. These are not code logic bugs — they are settings that grant too much access to too many callers, violating a foundational security principle called the Principle of Least Privilege.

Principle of Least Privilege: Every component — a user, a service, a database role, a cloud resource — should have only the minimum permissions it needs to do its job. Nothing more.

A related concept you'll often hear is blast radius: the scope of damage a security incident can cause is directly proportional to the permissions that were granted at the time. A credential that can only read from one S3 folder causes very little harm if stolen. A credential with wildcard permissions ("Action": "*") on the same AWS account can be used to wipe every database, create backdoor accounts, and read all secrets in the account.

Why AI Defaults to Permissive Settings#

Introductory tutorials prioritize getting things working. A tutorial showing you how to set up a CORS policy doesn't want to interrupt the narrative with a discussion of allowed origins — so it uses *. A tutorial showing you how to create an IAM policy uses "Action": "*" because it avoids the need to explain individual IAM permission names.

These permissive patterns appear so often in beginner and intermediate tutorials that they make up the majority of what AI models have learned. When an AI generates a configuration, it reproduces the most common pattern it has seen — which is the one that requires the least explanation. Veracode's 2025 benchmark found that AI-generated code introduces 2.74 times more vulnerabilities than human-written code, and Apiiro research found 322% more privilege escalation paths in AI-assisted codebases. Over-permissive configurations are a major contributor to both statistics.

Blast Radius: Wildcard vs. Least Privilege
Rendering diagram...

The four most common over-permissive patterns AI produces, each explained and fixed:

1. Wildcard CORS Header#

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls which websites are allowed to make requests to your API from the user's browser.

When a user visits evil-site.com and that site's JavaScript tries to call your API at api.myapp.com, the browser checks your CORS headers before allowing the request. If you have Access-Control-Allow-Origin: *, you're telling the browser: "any website can make authenticated requests to this API on behalf of my users."

You might think that combining * with credentials: true is safe because browsers block that combination — and they do. But a wildcard CORS policy is still dangerous for APIs that use token-based authentication. In token-based auth, JavaScript attaches the token directly to each request in the Authorization header, not as a cookie. Because the token doesn't travel as a cookie, the browser's built-in credential-blocking protection never kicks in, and any website can make authenticated requests to your API on behalf of your users.

Wildcard CORS Header

High
2.4 · Over-Permissive ConfigurationsCWE-942

A wildcard CORS policy allows any website to make requests to your API from users' browsers.

2. Wildcard IAM Policies#

IAM (Identity and Access Management) is the cloud permission system that controls what actions each resource or service account is allowed to perform. It applies to AWS, Google Cloud, Azure, and similar platforms.

AI frequently generates IAM policies with "Action": "*", which grants permission to do anything on any resource. This is the cloud equivalent of giving every service full administrator access. If a role with wildcard IAM permissions is compromised — through a stolen key, a vulnerable application, or a prompt-injected AI agent — the attacker inherits the ability to perform every action across the entire cloud account.

Wildcard IAM Policy

High
2.4 · Over-Permissive ConfigurationsCWE-269

A wildcard Action grants this role permission to perform any operation on any resource.

3. Public S3 Bucket ACLs#

AI sometimes generates S3 (Amazon Simple Storage Service) bucket configurations with public access enabled, or with ACLs (Access Control Lists) that make all uploaded objects publicly readable. This exposes every file in the bucket to anyone on the internet.

Public S3 buckets are a consistent source of real-world data breaches. Documented incidents include exposure of employee passport scans and PII from four major airports (over 1.5 million files), breaches at large organizations involving millions of customer records, and an ongoing pattern where stolen data is stored in misconfigured buckets as attacker infrastructure. Automated bucket scanners — tools that continuously probe cloud storage for publicly accessible buckets — find and index exposed content within hours of it appearing online.

Public S3 Bucket

High
2.4 · Over-Permissive ConfigurationsCWE-732

Bucket created without disabling public access — and files uploaded with public-read ACL.

4. Database Bound to 0.0.0.0#

When a database server binds to 0.0.0.0, it accepts connections from any IP address — including the public internet. AI generates this when setting up local development configurations, and those same configurations often get deployed to production unchanged.

The address 0.0.0.0 means "listen on every available network interface." In a cloud environment, that includes any public interface the host has. In Docker, publishing a port with "5432:5432" maps to 0.0.0.0:5432 on the host by default, which means the database port is reachable from outside the container — and potentially from outside the server entirely if no firewall rule is blocking it.

Automated scanners find exposed databases within minutes of deployment. Default credentials (postgres/postgres, root with no password, admin/admin) are tried immediately, and they often succeed on AI-generated setups because the AI that wrote the binding configuration also wrote the credentials.

Database Bound to 0.0.0.0

High
2.4 · Over-Permissive ConfigurationsCWE-923

PostgreSQL configuration binding to all network interfaces — reachable from any IP address.

Summary: Configuration Checklist#

Over-permissive configuration patterns to check after every AI coding session

ConfigurationWhat AI GeneratesWhat to Change It To
CORScors() with no options, Access-Control-Allow-Origin: *Explicit origin allowlist with specific domains
IAM"Action": "*", "Resource": "*"Named action list scoped to specific resource ARNs
S3Missing PublicAccessBlockConfiguration, ACL: 'public-read'All four Block Public Access settings enabled; pre-signed URLs for file access
Databaselisten_addresses = '0.0.0.0', ports: - "5432:5432" in DockerBind to localhost; remove Docker port mappings for databases

The same principle applies to all four: identify the smallest set of callers and actions that actually need access, and configure exactly that. Everything else should be denied by default.

Sources: