How to Find Security Issues in Your Website (Step-by-Step)

A security audit does not require expensive tools or years of experience. This step-by-step guide walks you through checking SSL, security headers, exposed files, DNS configuration, subdomains, open ports, and domain reputation — the same methodology used by professional penetration testers.

Before You Start: Ground Rules

This guide covers passive and semi-passive reconnaissance techniques — the same checks an attacker would perform before launching an actual attack. By running these checks yourself, you find and fix issues before they are exploited.

• Only test websites you own or have written authorization to test. Unauthorized testing is illegal.
• Document everything you find. Create a spreadsheet with findings, severity, and remediation status.
• Fix critical issues first. Prioritize exposed credentials and files over cosmetic header improvements.
• Re-test after fixing. Verify each fix is effective before moving to the next issue.

Step 1: Check Your SSL/TLS Configuration

SSL/TLS is the foundation of web security. Without it, everything transmitted between the user and your server — passwords, credit cards, session cookies — is visible to anyone on the network.

What to Check

• Certificate validity: Is the cert expired? Is it issued for the correct domain? Is the chain complete?
• Protocol support: TLS 1.2 and 1.3 should be enabled. TLS 1.0 and 1.1 should be disabled (they have known vulnerabilities).
• Cipher suites: Only strong ciphers should be enabled. Remove RC4, DES, 3DES, and any export-grade ciphers.
• HTTPS redirect: HTTP requests should 301 redirect to HTTPS.
• Mixed content: All resources (images, scripts, stylesheets) should load over HTTPS.

How to Check

# Quick SSL check with curl
curl -vI https://yourdomain.com 2>&1 | grep -E "(SSL|TLS|certificate|expire)"

# Check certificate expiration
echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

# Check supported TLS versions
for v in tls1 tls1_1 tls1_2 tls1_3; do
  echo -n "$v: "
  echo | openssl s_client -$v -connect yourdomain.com:443 2>&1 | grep -o "Protocol.*"
done

For a comprehensive check, use the SecureBin SSL Checker or Qualys SSL Labs for the most detailed analysis available.

Step 2: Audit Security Headers

Security headers instruct the browser on how to handle your site securely. Missing headers leave users vulnerable to XSS, clickjacking, and data injection attacks.

What to Check

# Fetch and display all security-relevant headers
curl -sI https://yourdomain.com | grep -iE "(strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy|x-xss-protection|cross-origin)"

You should see all of these headers:

• Strict-Transport-Security — forces HTTPS
• Content-Security-Policy — controls resource loading
• X-Frame-Options — prevents clickjacking
• X-Content-Type-Options — prevents MIME sniffing
• Referrer-Policy — controls referrer leakage
• Permissions-Policy — restricts browser features

Read our complete Security Headers Guide for detailed implementation instructions for each header. Use our CSP Builder to generate your Content-Security-Policy.

Step 3: Probe for Exposed Files and Paths

This is where most low-hanging vulnerabilities are found. Misconfigured servers frequently expose files that should never be public.

Critical Paths to Check

# Environment and config files
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.env
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.env.backup
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/wp-config.php
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/config.php

# Version control exposure
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.git/config
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.git/HEAD
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.svn/entries

# Debug and info endpoints
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/phpinfo.php
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/info.php
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/server-status
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/debug

# Backup files
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/backup.sql
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/db.sql
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/dump.sql

# Admin panels
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/admin
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/wp-admin
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/administrator

Any path returning HTTP 200 that should not be public is a finding. 403 means the server knows about the path but is blocking it (still a minor information disclosure). 404 is ideal — the server reveals nothing. Read our deep dive on the dangers of exposed .env files for the most common exposure.

Step 4: Analyze DNS Configuration

DNS misconfigurations can enable email spoofing, subdomain takeover, and information disclosure.

What to Check

# Check all DNS record types
dig yourdomain.com ANY +short

# Check email authentication
dig yourdomain.com TXT +short | grep -E "(spf|v=spf1)"
dig _dmarc.yourdomain.com TXT +short
dig default._domainkey.yourdomain.com TXT +short

# Check for zone transfer vulnerability (should fail)
dig @ns1.yourdomain.com yourdomain.com AXFR

# Check nameservers
dig yourdomain.com NS +short

Use our DNS Lookup tool for a comprehensive DNS analysis. Key findings to look for:

• Missing SPF record: Anyone can send email pretending to be from your domain
• Missing DMARC record: No policy enforcement on spoofed emails
• Zone transfer allowed: Exposes your entire DNS infrastructure to anyone
• Dangling CNAMEs: Subdomains pointing to deprovisioned services (subdomain takeover risk)

Step 5: Enumerate Subdomains

Forgotten subdomains are a major attack vector. Old staging servers, development environments, and deprecated services often have weaker security than the main site.

# Using DNS brute force (common subdomain names)
for sub in www mail ftp admin dev staging test api app blog shop cdn static; do
  ip=$(dig +short $sub.yourdomain.com)
  if [ -n "$ip" ]; then
    echo "$sub.yourdomain.com: $ip"
  fi
done

# Check Certificate Transparency logs (finds all certs issued for your domain)
curl -s "https://crt.sh/?q=%25.yourdomain.com&output=json" | python3 -m json.tool | grep name_value | sort -u

Certificate Transparency logs are particularly valuable because they reveal every SSL certificate ever issued for your domain and its subdomains — including ones you may have forgotten about. Each discovered subdomain should be checked for the same issues (SSL, headers, exposed files) as your main domain.

Step 6: Check for Open Ports

Only the ports you need should be open. Common findings include exposed database ports, admin panels on non-standard ports, and debug services left running.

# Check common web and service ports
for port in 21 22 23 25 53 80 443 3000 3306 5432 6379 8080 8443 9200 27017; do
  (echo >/dev/tcp/yourdomain.com/$port) 2>/dev/null && echo "Port $port: OPEN" || echo "Port $port: closed"
done

Ports that should generally NOT be exposed to the internet:

• 3306 (MySQL) — database should only be accessible from application servers
• 5432 (PostgreSQL) — same as MySQL
• 6379 (Redis) — unauthenticated by default, frequent target
• 9200 (Elasticsearch) — often unauthenticated, exposes all indexed data
• 27017 (MongoDB) — historically exposed without auth by default
• 23 (Telnet) — unencrypted protocol, should never be used

Use our Port Lookup tool to understand what each port is used for and whether it should be exposed.

Step 7: Verify Domain Reputation

If your domain is on spam blacklists or malware blocklists, your emails will be rejected and your search rankings will suffer. This can happen if your server was compromised and used to send spam, or if a previous owner of the domain had a bad reputation.

• Google Safe Browsing: Check if Google flags your site as dangerous
• Spam blacklists: Check major RBLs (Spamhaus, Barracuda, SORBS) for your IP and domain
• VirusTotal: Check if any security vendor flags your domain as malicious
• MX Toolbox: Comprehensive blacklist check for email deliverability

Use our Whois Lookup to check domain registration details and our IP Lookup to analyze your server's IP reputation.

Step 8: Review Technology Stack

Identifying the technologies your site uses helps find version-specific vulnerabilities.

# Check server headers for technology information
curl -sI https://yourdomain.com | grep -iE "(server|x-powered-by|x-generator|x-aspnet)"

# Check for common CMS fingerprints
curl -s https://yourdomain.com/wp-login.php -o /dev/null -w "%{http_code}"   # WordPress
curl -s https://yourdomain.com/user/login -o /dev/null -w "%{http_code}"      # Drupal
curl -s https://yourdomain.com/administrator -o /dev/null -w "%{http_code}"   # Joomla

# Check JavaScript libraries for known vulnerabilities
# View source and note library versions, then check retire.js or Snyk DB

Best practice: Remove or anonymize the Server and X-Powered-By headers. They provide no value to users and help attackers identify your stack. In Nginx: server_tokens off;. In Apache: ServerTokens Prod.

Step 9: Test Authentication and Session Management

If your site has a login system, test these manually:

• Password policy: Does the site accept weak passwords like "123456"?
• Account lockout: Are there limits on failed login attempts?
• Session cookies: Do they have the Secure, HttpOnly, and SameSite flags?
• Password reset: Does the reset token expire? Can it be reused? Does the reset link use HTTPS?
• 2FA: Is two-factor authentication available? Is it enforced for admin accounts?

# Check session cookie flags
curl -sI https://yourdomain.com/login -c - | grep -i "set-cookie"
# Look for: Secure; HttpOnly; SameSite=Strict (or Lax)

Generate strong passwords with our Password Generator and test password strength with our Password Strength Checker. If your site uses JWT tokens for authentication, inspect them with our JWT Decoder.

Step 10: Create a Security Audit Report

Document every finding with these fields:

1. Finding: Clear description of the issue
2. Severity: Critical, High, Medium, Low, Informational
3. Evidence: The exact request/response or screenshot
4. Remediation: Specific steps to fix the issue
5. Status: Open, In Progress, Fixed, Verified

Prioritize remediation by severity. Critical and High findings (exposed credentials, missing SSL, exploitable vulnerabilities) should be fixed immediately. Medium findings (missing headers, information disclosure) should be addressed within a week. Low and informational findings can be scheduled for the next development cycle.

The Complete Security Audit Checklist

Here is a summary checklist you can use for every audit:

1. SSL/TLS valid, TLS 1.2+ only, strong ciphers, HTTPS redirect working
2. All six security headers present (HSTS, CSP, X-Frame, X-Content-Type, Referrer-Policy, Permissions-Policy)
3. No exposed .env, .git, config, backup, or debug files
4. DNS records include SPF, DKIM, DMARC; no zone transfer; no dangling CNAMEs
5. No unnecessary open ports (especially database and cache ports)
6. Domain not on any blacklists
7. Server/technology version headers removed or anonymized
8. Session cookies have Secure, HttpOnly, SameSite flags
9. Admin panels are not publicly accessible (IP restriction or VPN)
10. All software is up to date with no known CVEs

Frequently Asked Questions

How long does a website security audit take?

A basic automated scan takes under a minute. The manual steps in this guide take 1-3 hours for a single domain. A comprehensive professional penetration test including application-level testing (SQL injection, XSS, business logic) takes 1-2 weeks. Start with the automated scan to get a baseline, then work through the manual steps for areas the scanner cannot cover. The SecureBin Exposure Checker handles the automated portion in seconds.

Do I need professional penetration testing?

For websites handling sensitive data (financial, healthcare, personal information), professional penetration testing is strongly recommended at least annually. The steps in this guide cover surface-level issues that are easily found. Professional testers go deeper — testing application logic, authentication flows, authorization boundaries, and business logic that automated tools cannot assess. However, this guide will catch the majority of common issues that lead to breaches.

What is the difference between a vulnerability scan and a penetration test?

A vulnerability scan (what this guide and automated tools provide) identifies known weaknesses by checking configurations, versions, and exposed resources. It does not attempt to exploit anything. A penetration test goes further by actively attempting to exploit vulnerabilities to prove impact and demonstrate real risk. Think of it as the difference between checking if a door is unlocked (scan) versus actually walking through it (pentest).

Should I fix issues in order or all at once?

Fix critical issues immediately and in order of severity. Exposed credentials and files should be remediated within hours — rotate all exposed secrets and block access. Missing security headers can be deployed in a single server config change. DNS issues may require coordination with your DNS provider or registrar. The key is to not let perfect be the enemy of good: fixing the top 5 critical issues provides more security improvement than trying to fix everything simultaneously.

The Bottom Line

Finding security issues in your website does not require expensive tools or deep expertise. The ten steps in this guide cover the same ground that attackers use for reconnaissance. By running these checks yourself, you find and fix vulnerabilities before they are exploited. Start with an automated scan for a baseline, then work through the manual steps. Make it a regular habit — the threat landscape changes constantly, and what was secure last month may not be secure today.

Related tools: Exposure Checker, SSL Checker, DNS Lookup, CSP Builder, Port Lookup, Whois Lookup, IP Lookup, and 70+ more free tools.