Security Misconfigurations

Security misconfiguration is the most preventable vulnerability category on the OWASP Top 10 — and consistently one of the most commonly found. It doesn't require a sophisticated exploit or a zero-day. It requires finding something that was left open, left default, or left behind. Default credentials, open cloud storage buckets, verbose error pages, and forgotten admin panels have caused some of the largest breaches on record.

What misconfiguration actually means

Misconfiguration isn't a single vulnerability — it's a category of failures that share one trait: something was set up incorrectly, incompletely, or not at all. The system works. It just works in a way that exposes more than it should.

In 2019, Capital One suffered a breach exposing over 100 million customer records. The attacker didn't crack encryption or exploit application code. They found a misconfigured Web Application Firewall that was set up with overly permissive IAM roles — it was allowed to query AWS metadata endpoints that exposed temporary credentials. Those credentials gave access to S3 buckets containing the data. One misconfigured permission, one breach, $80 million in fines.

The categories of misconfiguration appear consistently across every environment:

Open cloud storage — the S3 bucket problem

Between 2017 and 2020, hundreds of organisations exposed sensitive data through publicly readable AWS S3 buckets. The breaches followed an identical pattern: a developer created a bucket, set it to public for testing or convenience, and nobody changed it back. Verizon, Accenture, the US Army, the NSA's contractor — all had data exposed this way.

The fix is simple. The habit of checking is what's missing.

# Check if a specific S3 bucket is publicly accessible
aws s3api get-bucket-acl --bucket your-bucket-name

# Check the bucket policy for public access statements
aws s3api get-bucket-policy --bucket your-bucket-name

# Check the public access block settings (the master switch)
aws s3api get-public-access-block --bucket your-bucket-name

# Enable public access block on a bucket — closes all public access
aws s3api put-public-access-block \
  --bucket your-bucket-name \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# Audit ALL buckets in your account for public access issues
aws s3api list-buckets --query "Buckets[].Name" --output text | \
  tr '\t' '\n' | \
  while read bucket; do
    echo "--- $bucket ---"
    aws s3api get-public-access-block --bucket "$bucket" 2>/dev/null || echo "No block config set — check manually"
  done

# get-public-access-block on a misconfigured bucket
{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": false,
        "IgnorePublicAcls": false,
        "BlockPublicPolicy": false,
        "RestrictPublicBuckets": false
    }
}
# All four are false — this bucket has NO public access protection

# After applying put-public-access-block
{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": true,
        "RestrictPublicBuckets": true
    }
}
# All four true — public access is now fully blocked

# Audit output across all buckets
--- production-assets ---
BlockPublicAcls: true, RestrictPublicBuckets: true
--- dev-uploads-temp ---
No block config set — check manually
--- backup-archive-2023 ---
No block config set — check manually

Scanning for misconfigurations with nikto and nmap

Before an attacker maps your misconfigurations, you should. Nikto is a web server scanner that checks for dangerous files, outdated software, missing headers, and common misconfiguration patterns. Nmap's scripting engine goes further — it can test for default credentials, enumerate services, and identify known-vulnerable configurations across any open port.

# Basic nikto scan against a web server
nikto -h https://example.com

# Scan with specific checks — misconfigurations and outdated software
nikto -h https://example.com -Tuning 5 -Format txt -output nikto-report.txt

# Nmap — service version detection and default script scan
sudo nmap -sV -sC -p 80,443,8080,8443,22,21,3306,5432 example.com

# Nmap — check for default credentials on common services
sudo nmap -p 21,22,23,3306,5900 --script=ftp-anon,ssh-auth-methods,telnet-info,mysql-empty-password example.com

# Check if .git directory is exposed on a web server
curl -s -o /dev/null -w "%{http_code}" https://example.com/.git/HEAD

# Check for common exposed files
for path in /.env /backup.zip /phpinfo.php /admin /wp-admin /.git/HEAD /config.php /database.sql; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.com$path")
  echo "$code — https://example.com$path"
done

# nikto -h https://example.com (abbreviated)
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          93.184.216.34
+ Target Hostname:    example.com
+ Target Port:        443
---------------------------------------------------------------------------
+ Server: nginx/1.18.0
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-Content-Type-Options header is not set.
+ No CGI Directories found
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ OSVDB-3092: /admin/: This might be interesting...
+ OSVDB-3268: /backup/: Directory indexing found.
+ /backup/db_dump_2024.sql: Database backup file found.
+ OSVDB-3233: /phpinfo.php: PHP Info file found. May expose version info.
+ 8135 requests: 0 error(s) and 7 item(s) reported

# Exposed files check output
200 — https://example.com/.env              ← CRITICAL
200 — https://example.com/phpinfo.php       ← HIGH
200 — https://example.com/.git/HEAD         ← HIGH
200 — https://example.com/admin             ← REVIEW
403 — https://example.com/wp-admin
404 — https://example.com/backup.zip
404 — https://example.com/config.php
200 — https://example.com/database.sql      ← CRITICAL

Default credentials — the easiest win for attackers

Default credentials are usernames and passwords that ship with software out of the box — admin/admin, root/toor, admin/password. They exist for initial setup convenience. They're documented publicly in every product's manual. Attackers have comprehensive lists of them and try them automatically against every service they find.

In 2016, the Mirai botnet — which took down Dyn's DNS infrastructure and disrupted half the internet — was built almost entirely by scanning for IoT devices with default credentials. It used a list of 61 username/password combinations. Sixty-one. That list compromised hundreds of thousands of devices because their owners never changed the defaults.

Building a misconfiguration checklist

The most effective defence against misconfiguration is a repeatable checklist that gets run against every new deployment. Not once at launch — on every change, every new environment, every new service added to the stack.

Practice Questions

Quiz