Website Security Audit Checklist: 25 Point Inspection (2026)

A website security audit identifies vulnerabilities before attackers do. This 25-point checklist covers every critical area from SSL configuration and security headers to exposed files, authentication flaws, and server misconfigurations. Use it as a systematic guide for auditing any website, whether it is your own or a client's. Start with the automated checks using the SecureBin Exposure Checker, then work through the manual verification steps.

How to Use This Checklist

This checklist is organized from quickest automated checks to more detailed manual inspections. Start with Section 1 (automated scanning) to identify the most obvious issues, then work through each subsequent section. For each item, we note whether it can be checked automatically or requires manual review, along with the severity level and remediation guidance.

Before beginning, gather the following information: the domain name, any subdomains, the technology stack (CMS, framework, web server), and any compliance requirements (PCI DSS, HIPAA, SOC 2). This context helps prioritize findings.

Section 1: Automated Exposure Scan (5 minutes)

Start every audit with automated scanning to identify the lowest-hanging fruit. These are issues that attackers find first because they use the same automated tools.

1. Run SecureBin Exposure Checker. The SecureBin Exposure Checker scans your domain for 19 types of sensitive file exposure, including .env files, .git directories, backup files, configuration files, and debug endpoints. This single scan catches the majority of critical exposures in under 30 seconds.
2. Check SSL/TLS configuration. Use the SecureBin SSL Checker to verify certificate validity, protocol versions (TLS 1.2 minimum, TLS 1.3 preferred), cipher suite strength, and certificate chain completeness. See our SSL security checklist for details.
3. Verify DNS records. Use the SecureBin DNS Lookup to check for SPF, DKIM, and DMARC records (email security), DNSSEC status, and any unexpected DNS entries.
4. Scan for open ports. Identify any unnecessary services exposed to the internet. Common risky findings include open database ports (3306, 5432, 27017), exposed admin panels (8080, 8443), and debug services.

Section 2: Security Headers (10 checks)

Security headers are HTTP response headers that instruct browsers to enable protective features. Missing headers are one of the most common findings in security audits and one of the easiest to fix. Check our security headers guide for implementation details.

5. Content-Security-Policy (CSP). Prevents XSS and data injection attacks by specifying which content sources are allowed. Use the SecureBin CSP Builder to generate a policy.
6. Strict-Transport-Security (HSTS). Forces HTTPS connections. Verify the header includes max-age=31536000 (1 year minimum), includeSubDomains, and ideally preload.
7. X-Content-Type-Options. Should be set to nosniff to prevent MIME type sniffing attacks.
8. X-Frame-Options. Should be DENY or SAMEORIGIN to prevent clickjacking. CSP's frame-ancestors directive is the modern replacement.
9. Referrer-Policy. Should be strict-origin-when-cross-origin or no-referrer to control information leakage in the Referer header.
10. Permissions-Policy. Restricts which browser features (camera, microphone, geolocation) your site can access. Disable features you do not use.
11. X-XSS-Protection. Set to 0 on modern browsers (the built-in XSS filter is deprecated and can introduce vulnerabilities). Rely on CSP instead.
12. Cache-Control for sensitive pages. Pages containing sensitive data should include Cache-Control: no-store, no-cache, must-revalidate and Pragma: no-cache.
13. Server header. Should not reveal detailed version information. Server: Apache/2.4.54 (Ubuntu) helps attackers identify known vulnerabilities. Remove or genericize it.
14. X-Powered-By header. Should be removed entirely. X-Powered-By: PHP/8.1.12 discloses your technology stack unnecessarily.

Section 3: Authentication and Session Security (5 checks)

15. Password policy strength. Verify the application enforces minimum password length (12+ characters recommended), blocks common passwords, and supports but does not require complexity rules. Test with our Password Strength Checker.
16. Session cookie security. Verify session cookies have Secure (HTTPS only), HttpOnly (no JavaScript access), and SameSite=Lax or Strict flags set.
17. MFA availability. Verify that multi-factor authentication is available and, for admin accounts, required. Check that the TOTP implementation follows standards using our TOTP Generator.
18. Login rate limiting. Verify that repeated failed login attempts are rate-limited or result in temporary account lockout. Test by submitting 10 to 20 incorrect passwords rapidly.
19. Session timeout. Verify that sessions expire after a reasonable period of inactivity (15 to 30 minutes for sensitive applications). Check that logout actually invalidates the session server-side.

Section 4: File and Directory Exposure (5 checks)

20. .env and configuration files. Verify that /.env, /.env.production, /config.php, /wp-config.php.bak, and similar files return 403 or 404, not their contents. The Exposure Checker automates this.
21. .git directory. Verify that /.git/config and /.git/HEAD are not accessible. An exposed git directory allows attackers to download your entire source code history.
22. Directory listing. Verify that directory browsing is disabled. Navigating to a directory without an index file should return 403, not a list of files.
23. Backup files. Check for common backup file patterns: index.php.bak, database.sql, backup.tar.gz, dump.sql. These frequently contain credentials and sensitive data.
24. Admin panel exposure. Verify that admin interfaces (/admin, /wp-admin, /administrator) are protected by IP restriction, VPN, or additional authentication layer, not just a password form.

Section 5: Application Security (5 checks)

25. CORS configuration. Verify that the Access-Control-Allow-Origin header does not use wildcards (*) for authenticated endpoints. Overly permissive CORS allows unauthorized cross-origin requests. See our CORS misconfiguration guide.

Beyond CORS, a complete application security audit should also cover:

• Input validation. Test all user inputs for SQL injection, XSS, and command injection. Use parameterized queries and output encoding consistently.
• File upload security. Verify that uploads are restricted by file type (whitelist, not blacklist), scanned for malware, stored outside the web root, and served with correct MIME types.
• Error handling. Verify that production error pages do not reveal stack traces, database queries, file paths, or framework versions.
• API security. Verify that API endpoints require authentication, implement rate limiting, validate input, and do not expose excessive data. See our API security guide.

Audit Workflow: Putting It All Together

1. Automated scan (5 min). Run SecureBin Exposure Checker, SSL Checker, and DNS Lookup.
2. Header review (10 min). Check all 10 security headers using browser dev tools or curl.
3. Authentication testing (20 min). Test login security, session management, and access controls.
4. File exposure check (10 min). Verify sensitive files and directories are not accessible.
5. Application testing (30+ min). Test CORS, input validation, error handling, and API endpoints.
6. Document findings. Categorize each finding by severity (Critical, High, Medium, Low) and provide specific remediation steps.
7. Schedule follow-up. Re-scan after remediation to verify fixes. Schedule regular audits (quarterly recommended).

Common Mistakes in Security Audits

• Only scanning the main domain. Subdomains often have weaker security than the main site. Include all subdomains in your audit scope.
• Ignoring third-party scripts. Third-party JavaScript (analytics, ads, widgets) can introduce vulnerabilities. Audit what scripts are loaded and ensure your CSP restricts them.
• One-time audit mindset. Security is not a one-time activity. New vulnerabilities are discovered daily, code changes introduce new risks, and configurations drift over time. Automate what you can and schedule regular manual reviews.
• Not testing authenticated paths. Many vulnerabilities only appear behind authentication (IDOR, privilege escalation, data exposure). Always test both unauthenticated and authenticated functionality.

Frequently Asked Questions

How often should I run a website security audit?

Run automated scans (like the SecureBin Exposure Checker) weekly or after every deployment. Conduct a full manual audit quarterly for most websites. High-risk applications (e-commerce, healthcare, financial services) should have continuous automated scanning plus monthly manual reviews. Any significant code change, infrastructure migration, or new feature launch should trigger an additional audit.

Can I do a security audit myself or do I need a professional?

This checklist is designed for self-service auditing and covers the most common and impactful issues. A developer or system administrator can work through it effectively. However, for compliance requirements (PCI DSS, SOC 2), high-value targets, or after a security incident, professional penetration testing is recommended. Professional testers bring specialized tools, experience with complex attack chains, and formal reporting that meets audit requirements.

What should I do if I find critical vulnerabilities?

For critical findings (exposed credentials, SQL injection, exposed .env files), fix them immediately. Rotate any exposed credentials, patch the vulnerability, and verify the fix. For findings that require more time to remediate (like implementing CSP or migrating to a secrets manager), create a prioritized remediation plan with deadlines and track progress. Do not leave critical issues open for more than 48 hours.

How do I prioritize security findings?

Use this priority framework: Critical (active data exposure, exposed credentials, injectable endpoints) should be fixed immediately. High (missing HSTS, weak authentication, exposed admin panels) should be fixed within one week. Medium (missing security headers, information disclosure, session issues) should be fixed within one month. Low (cosmetic security improvements, informational headers) can be addressed during regular development cycles.

The Bottom Line

A website security audit does not have to be overwhelming. This 25-point checklist gives you a systematic approach that covers the most critical security areas. Start with the automated scans from the SecureBin Exposure Checker, work through the security headers, test authentication, check for exposed files, and review application security. Run this checklist quarterly, fix critical findings immediately, and you will be ahead of the vast majority of websites on the internet.

Related reading: Website Security Headers Guide, Free Website Security Scan, How to Find Security Issues on Your Website.