Website Security Audit Checklist 2025

Running a website without regular security audits is like leaving the front door of your office unlocked and hoping nobody walks in. Sooner or later, someone will. A security audit gives you a clear picture of where your defenses stand and what needs fixing before an attacker finds the gaps.

At Envestis in Lugano, we perform security assessments for businesses across Switzerland and beyond. This article walks you through every phase of a professional website security audit so you know exactly what to expect and what to demand from your security provider.

What Is a Website Security Audit?

A website security audit is a systematic examination of your web application, server configuration, and supporting infrastructure. The goal is to find vulnerabilities, misconfigurations, and weaknesses before malicious actors exploit them.

A proper audit goes well beyond running an automated scanner. It combines automated tools with manual analysis and expert interpretation. The output is a prioritized list of findings with concrete remediation steps.

External vs. Internal Assessment

There are two main perspectives for a security audit:

External assessment: Evaluates your website from the outside, the same way an attacker on the internet would see it. This covers publicly accessible services, open ports, exposed files, and externally visible misconfigurations.
Internal assessment: Examines the server environment from the inside, including file permissions, server configuration, database security, and internal network exposure. This requires access credentials.

Most audits start external. If you only have budget for one type, start there. An external assessment catches the issues most likely to be exploited by opportunistic attackers.

Phase 1: OSINT (Open Source Intelligence)

Before touching your website directly, a good auditor gathers publicly available information. This is the OSINT phase, and it often reveals more than people expect.

What OSINT Covers

DNS records: MX, TXT, CNAME, A, AAAA records. These reveal your hosting provider, email services, and sometimes internal hostnames that should not be public.
WHOIS data: Domain registration details, registrar, creation and expiry dates. Expired domains or soon-to-expire ones are a risk.
Subdomain enumeration: Tools like subfinder, amass, or certificate transparency logs reveal subdomains you may have forgotten about. Staging environments, old test sites, and admin panels frequently appear here.
Email addresses: Leaked employee emails from breaches (checked against databases like Have I Been Pwned) can be used for credential stuffing or phishing.
Code repositories: Public GitHub repos sometimes contain API keys, database credentials, or internal documentation.
Historical data: The Wayback Machine and cached pages can reveal old site structures, removed pages, and previously exposed sensitive content.

Why OSINT Matters

Attackers start with OSINT. If your staging site at staging.yourcompany.ch runs an unpatched WordPress with default credentials, no amount of hardening on your production site matters. OSINT finds the forgotten corners.

Phase 2: Technology Fingerprinting

Next, the auditor identifies the technology stack powering your website. Knowing the exact CMS, framework, server software, and plugin versions is critical because each has its own set of known vulnerabilities.

What Gets Fingerprinted

Component	How It Is Detected	Why It Matters
Web server	HTTP response headers (`Server` header)	Version-specific exploits (e.g., Apache 2.4.49 path traversal)
CMS	Meta tags, file paths, login pages	WordPress, Joomla, Drupal each have unique vulnerability profiles
JavaScript frameworks	Source code analysis, specific file paths	Outdated jQuery, Angular, or React versions may have XSS flaws
Plugins/extensions	URL patterns, HTML comments, CSS/JS references	Plugins are the #1 attack vector in CMS-based sites
Server-side language	File extensions, error messages, cookies	PHP, Python, Node.js each have different misconfiguration risks
CDN / WAF	Response headers, IP ranges, behavior analysis	Knowing the CDN helps assess what protections are in place

Tools like Wappalyzer, BuiltWith, and whatweb automate much of this, but experienced auditors also check manually. Automated tools miss custom setups and deliberately hidden indicators.

Phase 3: Vulnerability Scanning

With the technology stack identified, the auditor runs targeted vulnerability scans. This is the phase most people think of when they hear "security audit."

Automated Scanning Tools

Professional auditors typically combine several tools:

Nmap: Port scanning and service detection. Finds open ports that should not be exposed (database ports, admin interfaces, FTP).
Nikto: Web server scanner that checks for dangerous files, outdated server software, and common misconfigurations.
OWASP ZAP or Burp Suite: Web application scanners that crawl your site and test for injection flaws, XSS, CSRF, and other OWASP Top 10 vulnerabilities.
WPScan / CMSScan: CMS-specific scanners that check for vulnerable plugins, themes, and core versions.
SSLyze / testssl.sh: Dedicated SSL/TLS configuration analysis.

Manual Testing

Automated scanners catch roughly 60-70% of common vulnerabilities. The rest requires manual testing. Experienced auditors will:

Test authentication mechanisms (brute force protections, session management, password reset flows)
Check authorization controls (can user A access user B's data?)
Attempt business logic abuse (price manipulation, coupon stacking, rate limit bypass)
Test file upload functionality for unrestricted uploads
Check API endpoints for information disclosure or missing authentication

Phase 4: SSL/TLS Analysis

SSL/TLS configuration is one of the most critical aspects of website security. A poorly configured certificate or outdated protocol version can expose all traffic between your users and your server.

What Gets Checked

Certificate validity: Is the certificate current? Does it cover all subdomains? Is the chain of trust complete?
Protocol versions: TLS 1.2 and 1.3 should be the only enabled protocols. TLS 1.0 and 1.1 are deprecated. SSLv3 is a critical finding.
Cipher suites: Weak ciphers (RC4, DES, export ciphers) must be disabled. The server should prefer strong cipher suites and support forward secrecy.
HSTS: HTTP Strict Transport Security should be enabled with a reasonable max-age (at least 6 months). Include subdomains and preload directives where possible.
Certificate transparency: The certificate should be logged in CT logs for accountability.
OCSP stapling: Improves both security and performance of certificate revocation checks.

Common SSL/TLS Issues We Find

In our audits across Swiss businesses, the most frequent SSL/TLS problems are:

Missing HSTS header (very common, easy to fix)
TLS 1.0/1.1 still enabled (especially on older Windows Server installations)
Incomplete certificate chains causing warnings on some devices
Wildcard certificates used where they should not be
Mixed content (HTTPS page loading HTTP resources)

Phase 5: Email Authentication Check

Your website and your email share the same domain. Weak email authentication makes your domain vulnerable to spoofing, which attackers use for phishing campaigns targeting your clients and partners.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. Common issues include:

Missing SPF record entirely
SPF record with +all (allows anyone to send as your domain)
Too many DNS lookups (SPF has a 10-lookup limit)
Including services you no longer use

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing emails. The auditor checks that DKIM is properly configured for all sending services (your mail server, marketing tools, CRM, etc.).

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails. A proper DMARC policy progresses from p=none (monitoring) to p=quarantine and eventually p=reject.

We regularly find Swiss businesses with no DMARC record at all, leaving their domain wide open for spoofing.

Phase 6: Security Headers

HTTP security headers are a critical defense layer that many websites completely ignore. They are free to implement and significantly reduce the attack surface.

Essential Security Headers

Header	Purpose	Recommended Value
`Content-Security-Policy`	Prevents XSS and data injection	Strict policy limiting script sources
`X-Content-Type-Options`	Prevents MIME type sniffing	`nosniff`
`X-Frame-Options`	Prevents clickjacking	`DENY` or `SAMEORIGIN`
`Referrer-Policy`	Controls referrer information	`strict-origin-when-cross-origin`
`Permissions-Policy`	Controls browser features	Disable unused features (camera, microphone, etc.)
`Strict-Transport-Security`	Forces HTTPS	`max-age=31536000; includeSubDomains`

Content Security Policy Deep Dive

CSP deserves special attention because it is both the most powerful and the most commonly misconfigured security header. A proper CSP:

Blocks inline scripts (prevents most XSS attacks)
Whitelists only necessary script sources
Uses nonces or hashes for inline scripts that cannot be externalized
Reports violations to a monitoring endpoint

Start with Content-Security-Policy-Report-Only to monitor before enforcing. Many sites break when CSP is first deployed because they rely on inline scripts or third-party resources they were not aware of.

Phase 7: CMS-Specific Checks

If your site runs on a CMS like WordPress, Joomla, or Drupal, there are platform-specific security concerns that need dedicated attention.

WordPress Checklist

Core version current (check against wordpress.org release page)
All plugins updated and actively maintained
Unused plugins and themes removed (not just deactivated)
Default admin username changed
Login page protected (rate limiting, 2FA, or IP restriction)
XML-RPC disabled if not needed (common brute-force vector)
File editing disabled in wp-config.php (DISALLOW_FILE_EDIT)
Database prefix changed from default wp_
Directory listing disabled
wp-config.php not accessible via web
Debug mode disabled in production

General CMS Security

Admin interface accessible only from trusted IPs or VPN
Strong password policy enforced for all users
File upload restrictions properly configured
Error messages do not reveal system information
Automatic updates enabled for security patches

Phase 8: Performance and SEO Impact

Security and performance are linked more closely than most people realize. Security issues can directly harm your search engine rankings and user experience.

How Security Affects SEO

Blacklisting: Google flags compromised sites with "This site may be hacked" warnings, devastating organic traffic.
HTTPS: Google uses HTTPS as a ranking signal. Mixed content warnings reduce trust and rankings.
Page speed: Poorly configured security measures (overly aggressive WAF rules, redundant redirects) slow down your site.
Spam injection: SEO spam injected by attackers (pharmaceutical keywords, hidden links) triggers manual penalties.

Security Measures That Improve Performance

Good security hygiene often improves performance as a side effect:

Removing unused plugins reduces page weight and server load
Enabling HTTP/2 (which requires HTTPS) improves loading speed
Proper CSP headers reduce the risk of cryptojacking scripts that slow down your site
CDN implementation improves both security (DDoS mitigation) and speed

How to Interpret Audit Results

A professional security audit report categorizes findings by severity. The standard classification is:

Severity Levels

Critical: Immediately exploitable vulnerabilities that could lead to full system compromise. Examples: SQL injection, remote code execution, default admin credentials. Fix these within 24 hours.
High: Serious vulnerabilities that require some conditions to exploit. Examples: stored XSS, authentication bypass, sensitive data exposure. Fix within 1 week.
Medium: Vulnerabilities that require user interaction or specific conditions. Examples: reflected XSS, CSRF, missing security headers. Fix within 1 month.
Low: Minor issues that provide information to attackers or indicate suboptimal configuration. Examples: server version disclosure, verbose error messages. Fix within 3 months.
Informational: Best practice recommendations and observations. Not directly exploitable but worth addressing. Plan these into your maintenance cycle.

Reading the CVSS Score

Many audit reports include CVSS (Common Vulnerability Scoring System) scores. The scale runs from 0.0 to 10.0:

0.0: No vulnerability
0.1-3.9: Low
4.0-6.9: Medium
7.0-8.9: High
9.0-10.0: Critical

CVSS scores consider factors like attack complexity, required privileges, user interaction, and potential impact on confidentiality, integrity, and availability.

False Positives

Automated scanners produce false positives. A good audit report clearly marks findings that were manually verified versus those flagged only by automated tools. Always ask your auditor to confirm critical and high findings manually.

What to Do After an Audit

Receiving an audit report is just the beginning. Here is a practical approach to acting on the results:

Immediate Actions (Week 1)

Fix all critical vulnerabilities. No exceptions, no delays.
Change any compromised or weak credentials.
Patch all software with known vulnerabilities.
Disable any services or features flagged as unnecessary attack surface.

Short-Term Actions (Month 1)

Address high-severity findings.
Implement missing security headers.
Configure email authentication (SPF, DKIM, DMARC).
Set up monitoring and alerting for future issues.
Review and update backup procedures.

Long-Term Actions (Quarter 1)

Address medium and low findings.
Establish a regular patching schedule.
Plan a follow-up audit to verify fixes.
Develop a security policy document.
Train staff on security awareness.

Schedule Regular Audits

A single audit is a snapshot. Websites change constantly: new content, new plugins, new features. We recommend:

Annual comprehensive audit: Full assessment with manual testing.
Quarterly automated scans: Catch new vulnerabilities and configuration drift.
Continuous monitoring: Uptime, SSL certificate expiry, domain reputation, and security header checks.

The Complete Security Audit Checklist

Here is the consolidated checklist we use at Envestis for website security assessments. Use this to evaluate your own site or to verify that your security provider is thorough.

OSINT and Reconnaissance

DNS record analysis (A, AAAA, MX, TXT, CNAME, NS)
Subdomain enumeration
WHOIS and registration data review
Certificate transparency log review
Breach database check for corporate emails
Public code repository search
Historical website analysis

Infrastructure

Port scan (TCP and UDP top ports)
Service version detection
Operating system fingerprinting
Cloud configuration review (S3 buckets, Azure blobs)
CDN and WAF identification

SSL/TLS

Certificate validity and chain
Protocol versions (TLS 1.2/1.3 only)
Cipher suite strength
HSTS configuration
OCSP stapling
Mixed content check

Application Security

OWASP Top 10 vulnerability testing
Authentication and session management
Authorization and access control
Input validation and output encoding
File upload security
API security
Error handling (no information leakage)

Security Headers

Content-Security-Policy
X-Content-Type-Options
X-Frame-Options
Referrer-Policy
Permissions-Policy
Strict-Transport-Security

Email Authentication

SPF record validation
DKIM configuration
DMARC policy and reporting

CMS Security

Core version and patch level
Plugin and theme audit
User and permission review
Admin interface access control
File integrity check

Get a Professional Security Audit

If you are running a business website, especially one that handles customer data, processes payments, or represents your brand, a professional security audit is not optional. It is a fundamental business practice.

Envestis provides comprehensive website security audits for businesses in Lugano, across Switzerland, and internationally. Our audits follow the methodology outlined in this article and comply with industry standards including OWASP Testing Guide and PTES.