Insecure Defaults

Security skill for detecting insecure default configurations that create vulnerabilities when applications run with missing or incomplete configuration. Focuses on fail-open patterns where apps run insecurely rather than crash safely.

Overview

The insecure-defaults plugin identifies security vulnerabilities caused by dangerous default values that allow applications to run in production with weak or missing security controls. It distinguishes between fail-secure patterns (app crashes) and fail-open patterns (app runs insecurely).

Author: Trail of Bits
Version: 1.0.0

Critical Distinction: Applications that crash without proper configuration are safe (fail-secure). Applications that run with insecure defaults are vulnerable (fail-open).

Vulnerability Categories

The plugin detects five categories of insecure defaults:

Hardcoded Fallback Secrets

JWT keys, API keys, session secrets with fallback values

Default Credentials

admin/admin, root/password, test API keys

Weak Cryptographic Defaults

MD5, DES, ECB mode for security-sensitive operations

Permissive Access Control

CORS *, public by default, world-writable permissions

Missing Security Configuration

Authentication disabled by default, debug mode enabled

When to Use

Use this skill when:

Security auditing production applications or services
Configuration review of deployment manifests (Docker, Kubernetes, IaC)
Pre-production checks before deploying new services
Code review of authentication, authorization, or cryptographic code
Environment variable handling analysis for secrets management
API security review checking CORS, rate limiting, authentication
Third-party integration review for hardcoded test credentials

When NOT to Use

Do not use this skill for:

Test fixtures explicitly scoped to test environments (test/, spec/, __tests__/)
Example/template files (.example, .template, .sample suffixes)
Development-only tools (local Docker Compose for dev, debug scripts)
Documentation examples in README.md or docs/ directories
Build-time configuration that gets replaced during deployment
Crash-on-missing behavior where app won’t start without proper config (fail-secure)

When in doubt: trace the code path to determine if the app runs with the default or crashes.

Installation

/plugin install insecure-defaults

Workflow

Follow this workflow for every potential finding:

SEARCH: Project Discovery

Determine language, framework, and project conventions. Find secret storage locations, credentialed integrations, cryptography usage, and security configuration.

VERIFY: Actual Behavior

Trace code paths to understand runtime behavior. Determine what happens if configuration is missing.

CONFIRM: Production Impact

Check if production config provides the variable or if the insecure default reaches production.

REPORT: With Evidence

Document location, pattern, verification results, production impact, and exploitation scenario.

Category 1: Fallback Secrets

Vulnerable Patterns

# File: src/auth/jwt.py
SECRET_KEY = os.environ.get('SECRET_KEY', 'dev-secret-key-123')

# Used in security context
def create_token(user_id):
    return jwt.encode({'user_id': user_id}, SECRET_KEY, algorithm='HS256')

Why vulnerable: App runs with known secret if env var is missing. Attacker can forge tokens/access database.

Secure Patterns

# File: src/auth/jwt.py
SECRET_KEY = os.environ['SECRET_KEY']  # Raises KeyError if missing

# App won't start without SECRET_KEY - fail-secure

Category 2: Default Credentials

Vulnerable Patterns

# File: src/models/user.py
def bootstrap_admin():
    """Create default admin account if none exists"""
    if not User.query.filter_by(role='admin').first():
        admin = User(
            username='admin',
            password=hash_password('admin123'),
            role='admin'
        )
        db.session.add(admin)
        db.session.commit()

Why vulnerable: Default admin accounts or test credentials reach production if env vars missing.

Secure Patterns

Disabled default account

# File: src/models/user.py
def bootstrap_admin():
    """Admin account MUST be configured via environment"""
    username = os.environ['ADMIN_USERNAME']
    password = os.environ['ADMIN_PASSWORD']

    if not User.query.filter_by(username=username).first():
        admin = User(username=username, password=hash_password(password), role='admin')
        db.session.add(admin)

Category 3: Fail-Open Security

Vulnerable Patterns

# File: config/security.py
REQUIRE_AUTH = os.getenv('REQUIRE_AUTH', 'false').lower() == 'true'

@app.before_request
def check_auth():
    if not REQUIRE_AUTH:
        return  # Skip auth check
    # ... auth logic

Why vulnerable: Default is insecure. App runs without authentication, accepts requests from any origin, or leaks stack traces if env var missing.

Secure Patterns

# File: config/security.py
REQUIRE_AUTH = os.getenv('REQUIRE_AUTH', 'true').lower() == 'true'  # Default: true

# Or better - crash if not explicitly configured
REQUIRE_AUTH = os.environ['REQUIRE_AUTH'].lower() == 'true'

Category 4: Weak Crypto

Vulnerable Patterns

# File: src/auth/passwords.py
import hashlib

def hash_password(password):
    """Hash user password"""
    return hashlib.md5(password.encode()).hexdigest()

Why vulnerable:

MD5 is cryptographically broken, rainbow tables exist
DES has 56-bit keys (brute-forceable), ECB mode leaks patterns
SHA1 collisions exist

Use bcrypt/Argon2 for passwords, AES-GCM for encryption, SHA256+ for signatures.

Secure Patterns

# File: src/auth/passwords.py
import bcrypt

def hash_password(password):
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt())

Weak crypto for non-security checksums (cache keys, ETags) is acceptable.

Category 5: Permissive Access

Vulnerable Patterns

# File: src/storage/files.py
def create_secure_file(path):
    fd = os.open(path, os.O_CREAT | os.O_WRONLY, 0o666)  # rw-rw-rw-
    return fd

Why vulnerable:

Any user can write to file (should be 0o600 or 0o644)
Sensitive data exposed publicly
CORS misconfiguration allows credential theft from any site

Search Patterns

Use these grep patterns to discover insecure defaults:

Fallback Secrets

grep -r "getenv.*\) or ['\"]" **/config/ **/auth/
grep -r "process\.env\.[A-Z_]+ \|\| ['\"]" src/
grep -r "ENV\.fetch.*default:" config/

Hardcoded Credentials

grep -r "password.*=.*['\"][^'\"]{8,}['\"]" src/
grep -r "api[_-]?key.*=.*['\"][^'\"]+['\"]" config/
grep -r "secret.*=.*['\"][^'\"]+['\"]" --include="*.py" --include="*.js"

Weak Defaults

grep -r "DEBUG.*=.*true" config/
grep -r "AUTH.*=.*false" src/
grep -r "CORS.*=.*\*" server/

Crypto Algorithms

grep -r "MD5\|SHA1\|DES\|RC4\|ECB" src/auth/ src/crypto/

Rationalizations to Reject

Reject these shortcuts that lead to missed findings:

Rationalization	Why It’s Wrong
”It’s just a development default”	If it reaches production code, it’s a finding
”The production config overrides it”	Verify prod config exists; code-level vulnerability remains
”This would never run without proper config”	Prove it with code trace; many apps fail silently
”It’s behind authentication”	Defense in depth; compromised session still exploits weak defaults
”We’ll fix it before release”	Document now; “later” rarely comes

Report Format

For each finding, document:

Finding: Hardcoded JWT Secret Fallback
Location: src/auth/jwt.ts:15
Pattern: const secret = process.env.JWT_SECRET || 'default';

Verification: App starts without JWT_SECRET; secret used in jwt.sign() at line 42
Production Impact: Dockerfile missing JWT_SECRET
Exploitation: Attacker forges JWTs using 'default', gains unauthorized access

Severity: CRITICAL

Audit Context Building - Understand security architecture
Differential Review - Review config changes in PRs

Get Started

Core Concepts

Smart Contract Security

Code Auditing

Static Analysis Tools

Verification & Testing

Specialized Tools

Development

Infrastructure & Tools

Other

Overview

Vulnerability Categories

Hardcoded Fallback Secrets

Default Credentials

Weak Cryptographic Defaults

Permissive Access Control

Missing Security Configuration

When to Use

When NOT to Use

Installation

Workflow

Category 1: Fallback Secrets

Vulnerable Patterns

Secure Patterns

Category 2: Default Credentials

Vulnerable Patterns

Secure Patterns

Category 3: Fail-Open Security

Vulnerable Patterns

Secure Patterns

Category 4: Weak Crypto

Vulnerable Patterns

Secure Patterns

Category 5: Permissive Access

Vulnerable Patterns

Search Patterns

Rationalizations to Reject

Report Format

Build docs developers (and LLMs) love

Get Started

Core Concepts

Smart Contract Security

Code Auditing

Static Analysis Tools

Verification & Testing

Specialized Tools

Development

Infrastructure & Tools

Other

Documentation Index

​Overview

​Vulnerability Categories

Hardcoded Fallback Secrets

Default Credentials

Weak Cryptographic Defaults

Permissive Access Control

Missing Security Configuration

​When to Use

​When NOT to Use

​Installation

​Workflow

​Category 1: Fallback Secrets

​Vulnerable Patterns

​Secure Patterns

​Category 2: Default Credentials

​Vulnerable Patterns

​Secure Patterns

​Category 3: Fail-Open Security

​Vulnerable Patterns

​Secure Patterns

​Category 4: Weak Crypto

​Vulnerable Patterns

​Secure Patterns

​Category 5: Permissive Access

​Vulnerable Patterns

​Search Patterns

​Rationalizations to Reject

​Report Format

​Related Skills

Build docs developers (and LLMs) love

Overview

Vulnerability Categories

When to Use

When NOT to Use

Installation

Workflow

Category 1: Fallback Secrets

Vulnerable Patterns

Secure Patterns

Category 2: Default Credentials

Vulnerable Patterns

Secure Patterns

Category 3: Fail-Open Security

Vulnerable Patterns

Secure Patterns

Category 4: Weak Crypto

Vulnerable Patterns

Secure Patterns

Category 5: Permissive Access

Vulnerable Patterns

Search Patterns

Rationalizations to Reject

Report Format

Related Skills