Common Security Misconfigurations and How to Fix Them

Security misconfigurations are the most common finding category in external security assessments — our analysis of why misconfigurations dominate scan results explains the structural reasons behind this pattern. Most are straightforward to fix once identified -- the challenge is knowing they exist and understanding the specific configuration change needed for your server environment.

This guide covers the 20 most frequent misconfigurations found in external scans, organized by category, with concrete fixes for Nginx, Apache, and common cloud platforms.

TLS/SSL Misconfigurations

1. TLS 1.0/1.1 Still Enabled

Risk: Deprecated protocols with known vulnerabilities (BEAST, POODLE). Attackers can downgrade connections to exploit weaknesses. For a comprehensive TLS hardening approach, see our TLS protocol and cipher hardening guide.

Fix for Nginx:

ssl_protocols TLSv1.2 TLSv1.3;

Fix for Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Fix for AWS ALB: Update the security policy to ELBSecurityPolicy-TLS13-1-2-2021-06 or newer.

Fix for Cloudflare: Dashboard > SSL/TLS > Edge Certificates > Minimum TLS Version > TLS 1.2

2. Weak Cipher Suites

Risk: Ciphers like RC4, DES, 3DES, and export-grade ciphers can be broken, allowing traffic decryption.

Fix for Nginx:

ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;

Fix for Apache:

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder on

3. Missing HSTS Header

Risk: Without HSTS, the first connection to your site can be intercepted and downgraded from HTTPS to HTTP (SSL stripping).

Fix for Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Fix for Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Important: Before adding includeSubDomains, verify that ALL subdomains support HTTPS. Before adding preload, verify at hstspreload.org.

4. Incomplete Certificate Chain

Risk: Some clients cannot verify your certificate if intermediate certificates are missing, causing trust errors.

Fix: Concatenate your certificate with the intermediate certificate(s):

cat server.crt intermediate.crt > fullchain.pem

In Nginx:

ssl_certificate /etc/ssl/certs/fullchain.pem;

5. Missing OCSP Stapling

Risk: Without OCSP stapling, clients must contact the CA's OCSP server to check certificate revocation, adding latency and a privacy leak.

Fix for Nginx:

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;

HTTP Security Header Misconfigurations

6. Missing Content-Security-Policy

Risk: Without CSP, your site has no browser-enforced protection against cross-site scripting (XSS) attacks. See our HTTP security headers implementation guide for full header configurations including nonce-based CSP.

Start with report-only to avoid breaking functionality:

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; report-uri /csp-report" always;

Move to enforcement after confirming no legitimate resources are blocked:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'" always;

7. Missing X-Content-Type-Options

Risk: Browsers may MIME-sniff content, interpreting uploaded files as executable scripts.

Fix (all servers):

add_header X-Content-Type-Options "nosniff" always;

8. Missing X-Frame-Options

Risk: Your site can be embedded in frames on attacker-controlled pages for clickjacking attacks.

Fix:

add_header X-Frame-Options "DENY" always;

Use SAMEORIGIN instead of DENY if your site legitimately uses iframes for its own content.

9. Missing Referrer-Policy

Risk: Full URLs (potentially containing tokens, session IDs, or sensitive paths) are sent to third-party sites via the Referer header.

Fix:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

10. Missing Permissions-Policy

Risk: Your site may inadvertently allow access to sensitive browser features like camera, microphone, and geolocation.

Fix:

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;

Information Disclosure Misconfigurations

11. Server Version Disclosure

Risk: Version information helps attackers identify specific vulnerabilities to exploit.

Fix for Nginx:

server_tokens off;

Fix for Apache:

ServerTokens Prod
ServerSignature Off

Fix for Express.js:

app.disable('x-powered-by');

12. X-Powered-By Header

Risk: Reveals the application framework and version (e.g., X-Powered-By: PHP/8.1.2).

Fix for Nginx (proxy):

proxy_hide_header X-Powered-By;

Fix for PHP (php.ini):

expose_php = Off

Fix for Express.js:

app.disable('x-powered-by');
// Or use helmet:
const helmet = require('helmet');
app.use(helmet());

13. Detailed Error Pages

Risk: Stack traces, file paths, database queries, and internal IP addresses exposed in error responses.

Fix: Configure custom error pages for all HTTP error codes:

Nginx:

error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;

For application frameworks, ensure production mode is enabled:

# Node.js
NODE_ENV=production

# Django
DEBUG = False

# Rails
config.consider_all_requests_local = false

# PHP
display_errors = Off
log_errors = On

Email Authentication Misconfigurations

14. DMARC at p=none

Risk: Your domain can be spoofed freely. p=none only reports spoofing -- it does not prevent it.

Fix: Progressively tighten your DMARC policy:

# Step 1: Quarantine 25% of failures
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"

# Step 2: Quarantine 100%
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"

# Step 3: Reject all failures
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

Analyze DMARC aggregate reports between each step to ensure legitimate email is passing.

15. SPF Soft Fail (~all)

Risk: Soft fail is treated as a mild negative signal by most receiving servers, providing weak enforcement.

Fix: Change ~all to -all:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Ensure all legitimate sending services are included before switching to hard fail. Our SPF record configuration guide walks through the process of auditing your sending services and building a correct SPF record.

16. SPF Exceeding 10 Lookups

Risk: SPF evaluates to permanent error (permerror) when lookups exceed 10, effectively disabling SPF.

Fix: Reduce lookups by replacing include mechanisms with ip4/ip6 where possible:

# Before (3 lookups from includes)
v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net -all

# After (1 lookup + direct IPs for static senders)
v=spf1 include:_spf.google.com ip4:205.201.128.0/20 ip4:167.89.0.0/17 -all

DNS Misconfigurations

17. No DNSSEC

Risk: DNS responses can be spoofed, redirecting users to malicious servers.

Fix: Enable DNSSEC through your DNS hosting provider. The process varies by provider but generally involves:

1. Enable DNSSEC signing in your DNS host's dashboard
2. Copy the DS record provided by the DNS host
3. Add the DS record at your domain registrar

18. No CAA Records

Risk: Any certificate authority can issue certificates for your domain.

Fix: Add CAA records restricting issuance to your authorized CAs:

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild "letsencrypt.org"
example.com.  CAA  0 iodef "mailto:security@example.com"

19. Dangling CNAME Records

Risk: CNAME records pointing to unclaimed services (decommissioned cloud resources, cancelled SaaS subscriptions) can be taken over by attackers (subdomain takeover).

Fix: Audit all CNAME records. For each:

1. Verify the target is still active and owned by your organization
2. If the target is no longer active, remove the CNAME record
3. If the target is a cloud resource, verify ownership cannot lapse

Network Misconfigurations

20. Unnecessary Open Ports

Risk: Each open port is an attack vector. Database ports, remote desktop, and admin interfaces should not be internet-facing.

Fix with iptables:

# Block common dangerous ports
iptables -A INPUT -p tcp --dport 3389 -j DROP  # RDP
iptables -A INPUT -p tcp --dport 3306 -j DROP  # MySQL
iptables -A INPUT -p tcp --dport 5432 -j DROP  # PostgreSQL
iptables -A INPUT -p tcp --dport 27017 -j DROP # MongoDB
iptables -A INPUT -p tcp --dport 6379 -j DROP  # Redis

Fix with cloud security groups (AWS, Azure, GCP): Remove inbound rules for non-essential ports. Restrict SSH to known IP ranges or VPN CIDR blocks.

Verification

After applying any fix, verify it with CyberShield:

1. Quick scan the relevant module to confirm the finding is resolved
2. Full scan to ensure the fix did not introduce new issues
3. Compare with previous scan to verify the specific finding changed from present to resolved

Regular scanning catches configuration regressions. Server updates, deployments, and infrastructure changes can reintroduce misconfigurations that were previously fixed. Weekly scanning ensures your fixes persist.