Insecure Defaults

Identifies fail-open vulnerabilities: configurations where missing env vars, secrets, or settings cause the application to run in an insecure state rather than failing safely.

When to Use

• Pre-deployment security audit of production application
• Reviewing config files, .env handling, or secrets management
• Auditing environment variable usage across the codebase
• Checking cryptographic algorithm choices
• Reviewing Docker / IaC / Kubernetes configs for permissive defaults
• User asks "is this safe to deploy?" or "are there hardcoded secrets?"

When NOT to Use

• Test code (tests/, spec/, __tests__/, *.test.*) — test defaults are intentional
• .example, .template, .sample files — placeholders by design
• Documentation examples
• Build-time config guaranteed to be replaced during deployment
• Dev-only tooling that never runs in production

Rationalizations to Reject

• "The default is only used locally" — local development often mirrors production configs; defaults leak
• "We always set the env var in production" — "always" breaks eventually; code must fail-safe
• "It's an internal service, not exposed" — internal breach + fail-open = full compromise
• "The weak algorithm is only for non-sensitive data" — "non-sensitive" classifications drift over time
• "The tests pass with the default" — test pass ≠ production safe

Core Distinction

The fundamental question for every finding:

Fail-Open (DANGEROUS): App runs insecurely when config is absent

# DANGEROUS — runs with weak secret if env var missing
SECRET = os.environ.get('SECRET_KEY') or 'default-secret'

Fail-Secure (SAFE): App crashes/refuses to start when required config is absent

# SAFE — raises KeyError if env var missing, app won't start
SECRET = os.environ['SECRET_KEY']

# Also safe — explicit error message
SECRET = os.environ.get('SECRET_KEY')
if not SECRET:
    raise RuntimeError("SECRET_KEY environment variable is required")

Analysis Workflow (4 Phases)

Phase 1 — Discovery

Map the attack surface:

# Find all env var reads
grep -rn "os.environ\|os.getenv\|process.env\|getenv" --include="*.py" --include="*.ts" --include="*.js" .

# Find all config/settings files
find . -name "config*.py" -o -name "settings*.py" -o -name "*.env*" | grep -v ".example"

# Find potential hardcoded secrets
grep -rn "password\|secret\|token\|api_key\|apikey\|credential" -i --include="*.py" .
grep -rn "password\|secret\|token\|api_key\|apikey\|credential" -i --include="*.ts" .

Inventory:

• All env var reads and their fallback values
• All cryptographic operations and algorithm choices
• All authentication/authorization configuration points
• All external service configuration (URLs, timeouts, TLS settings)

Phase 2 — Verification

For each env var read, classify:

Trace each fail-open pattern: where is the value used?

• Used in cryptographic operation → CRITICAL
• Used in auth check → CRITICAL
• Used in external API call → HIGH
• Used in logging / non-security context → LOW

Phase 3 — Production Assessment

Verify whether production actually sets required variables:

• Check deployment configs: docker-compose.yml, k8s/, .env.production, CI/CD secrets
• Check if documented: is the env var listed in README / deployment guide?
• Check if validated at startup: is there an explicit startup check?

A fail-open pattern is more severe if:

• No startup validation exists
• Env var is not documented
• Deployment config shows it's sometimes unset

Phase 4 — Findings Documentation

For each finding:

## [Severity] <Short title>

**File:** path/to/file.py:42
**Pattern:** fail-open / hardcoded / weak algorithm

**Vulnerable code:**

SECRET = os.environ.get('SECRET_KEY') or 'dev-secret-change-me'

**What happens if env var is missing:**
Application starts with `SECRET_KEY = 'dev-secret-change-me'`. An attacker
who knows this default can forge session tokens / HMAC signatures.

**Fix:**

SECRET = os.environ.get('SECRET_KEY') if not SECRET: raise RuntimeError("SECRET_KEY is required. Set it in your environment.")

Finding Categories

1. Weak Env Var Fallbacks

# All of these are fail-open:
SECRET = os.getenv('SECRET') or 'default'
SECRET = os.environ.get('SECRET', 'changeme')
DB_PASSWORD = config.get('db_password', 'postgres')
API_KEY = os.environ.get('API_KEY', '')   # empty string = no auth

2. Hardcoded Credentials

# Hardcoded in source — always a finding regardless of context
DB_URI = "postgresql://admin:password123@localhost/prod"
AWS_SECRET = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

3. Weak Cryptographic Algorithms

# Weak — even if fallback looks "fine"
hashlib.md5(password)              # collision attacks, rainbow tables
hashlib.sha1(password)             # deprecated for password hashing
Cipher.new(key, AES.MODE_ECB)     # ECB reveals patterns
DES.new(key)                       # 56-bit key, brute-forceable

4. Permissive Default Access Controls

CORS_ORIGINS = ["*"]               # any origin can send cookies
DEBUG = os.environ.get('DEBUG', True)   # debug on by default
ALLOW_REGISTRATION = True           # open registration in production

5. TLS / Certificate Validation

requests.get(url, verify=False)    # MITM possible
ssl._create_unverified_context()   # disables cert validation globally

6. Insecure Defaults in Config Files

# docker-compose.yml
services:
  db:
    environment:
      POSTGRES_PASSWORD: ""        # empty password

# nginx.conf
server_tokens on;                  # leaks nginx version

Severity Classification

Output Format

# Insecure Defaults Audit: <scope>

## Summary
- Fail-open patterns found: X
- Hardcoded credentials found: X
- Weak algorithms found: X
- Files audited: X / Y total

## 🔴 Critical

### [C1] Fail-open session secret
...

## 🟠 High
...

## ✅ What's secure
- `DATABASE_URL` correctly uses `os.environ['DATABASE_URL']` (fail-secure)
- Password hashing uses `bcrypt` correctly