Insecure Defaults Detector

Automated security scanner that identifies insecure default configurations in applications, frameworks, databases, cloud services, and infrastructure components before deployment.

When to Use This Skill

Choose Insecure Defaults Detector when:

• Setting up new application frameworks and need secure baseline configs
• Auditing existing configurations for known insecure defaults
• Hardening cloud infrastructure before production deployment
• Reviewing database and middleware configurations
• Building security baseline policies for new technology adoptions

Consider alternatives when:

• Need runtime vulnerability detection — use DAST tools
• Need compliance-specific checks — use CIS Benchmark scanners
• Performing code-level security analysis — use SAST tools

Quick Start

Copy
# Activate insecure defaults detector
claude skill activate ultimate-insecure-defaults-detector-workshop

# Scan application configs
claude "Check for insecure defaults in our Express.js configuration"

# Database hardening
claude "Audit PostgreSQL default configuration for security issues"

Example Default Detection

Copy
// Common insecure defaults in Express.js
const express = require('express');
const app = express();

// INSECURE DEFAULT: X-Powered-By header reveals framework
// Fix: app.disable('x-powered-by');

// INSECURE DEFAULT: No rate limiting
// Fix: app.use(rateLimit({ windowMs: 15 * 60 * 1000, max: 100 }));

// INSECURE DEFAULT: No CORS restrictions
// Fix: app.use(cors({ origin: 'https://yourdomain.com' }));

// INSECURE DEFAULT: Body parser with unlimited size
// Fix: app.use(express.json({ limit: '10kb' }));

// INSECURE DEFAULT: No security headers
// Fix: app.use(helmet());

// INSECURE DEFAULT: Verbose error messages in production
// Fix: app.use((err, req, res, next) => {
//   res.status(500).json({ error: 'Internal Server Error' });
// });

// INSECURE DEFAULT: Session with default secret
// Fix: app.use(session({
//   secret: process.env.SESSION_SECRET,  // Not 'keyboard cat'
//   cookie: { secure: true, httpOnly: true, sameSite: 'strict' }
// }));

Core Concepts

Common Insecure Defaults by Category

Category	Insecure Default	Secure Alternative
Web Framework	Debug mode enabled	Disable debug in production
Web Framework	Verbose error responses	Generic error messages
Database	Root/admin without password	Strong password + least privilege
Database	Listening on 0.0.0.0	Bind to localhost or private IP
Cloud	Public S3 buckets	Private with explicit access policies
Cloud	Default VPC security groups	Restrictive ingress/egress rules
Auth	No password complexity	Minimum 12 chars, complexity rules
Auth	Unlimited login attempts	Account lockout after 5 failures
TLS	All cipher suites enabled	TLS 1.2+ with strong ciphers only
Logging	Sensitive data logged	PII masking in all log outputs

Technology-Specific Checks

Technology	Key Defaults to Change	Risk Level
PostgreSQL	listen_addresses = '*', no pg_hba.conf restrictions	Critical
MongoDB	No authentication, bind to all interfaces	Critical
Redis	No password, protected-mode off	Critical
Nginx	Server tokens on, autoindex on	Medium
Docker	Running as root, no resource limits	High
Kubernetes	No network policies, default service account	High
AWS	Public access on new resources, overprivileged IAM	Critical
Node.js	No helmet, no rate limiting, trust proxy off	High

Copy
# Kubernetes insecure defaults to fix
apiVersion: v1
kind: Pod
spec:
  containers:
    - name: app
      # INSECURE: Running as root (default)
      # FIX:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      # INSECURE: No resource limits (default)
      # FIX:
      resources:
        limits:
          memory: "256Mi"
          cpu: "500m"
        requests:
          memory: "128Mi"
          cpu: "250m"

Configuration

Parameter	Description	Default
scan_targets	Technologies to scan	Auto-detect
severity_threshold	Minimum severity to report	medium
include_fixes	Include remediation commands	true
check_cloud	Scan cloud provider configs	true
output_format	Report format: markdown, json, sarif	markdown
baseline_file	Known accepted risks to suppress	null

Best Practices

1. Audit defaults immediately when adopting new technology — Don't wait for a security review cycle. The first deployment of any new technology should include a default configuration audit. Create a hardening checklist specific to each technology in your stack.

2. Automate default detection in CI/CD pipelines — Add configuration scanning to your deployment pipeline. Tools like checkov (Terraform), hadolint (Dockerfile), and kubesec (Kubernetes) catch insecure defaults before they reach production.

3. Maintain a secure baseline configuration library — Create templated, hardened configurations for every technology in your stack. New projects start from these templates rather than framework defaults, eliminating entire classes of insecure defaults by default.

4. Document every accepted risk — When business requirements force accepting an insecure default (e.g., public S3 bucket for static assets), document the risk, mitigation controls (CloudFront + WAF), and review schedule in a risk register.

5. Review defaults after every major version upgrade — Framework and database upgrades sometimes change default values. A default that was secure in PostgreSQL 14 might change behavior in PostgreSQL 16. Review release notes specifically for default value changes.

Common Issues

Security scanner flags defaults that are already overridden in runtime configuration. Scanners may read configuration files without understanding runtime overrides, environment variables, or infrastructure-level controls. Document which defaults are overridden and where, and use scanner suppression with justification comments for verified-safe configurations.

Hardening defaults breaks application functionality. Some insecure defaults exist because the secure alternative requires additional setup. For example, enabling readOnlyRootFilesystem in Kubernetes breaks applications that write to temporary files. Fix by adding explicit emptyDir volume mounts for write-needed paths rather than reverting to insecure defaults.

Team members reset configurations to defaults during troubleshooting. Use infrastructure-as-code and gitops to manage all configurations. When someone manually changes a config for debugging, the IaC system reverts it on next deployment. Add pre-commit hooks that validate configuration files against your security baseline before allowing commits.