How to Audit Web Servers and Web Applications: Checklist

Web servers and web applications face the internet all day, so they attract more attacks than almost any other system. When you audit web servers, you check both layers: the server software, such as Nginx, Apache or IIS, and the application running on it.

This guide covers scope, tools, the audit steps and a practical checklist.

Scope

• Web server software and its configuration.
• The operating system underneath.
• TLS certificates and settings.
• The web application, its APIs and admin panels.
• Supporting parts: databases, CDNs, WAFs and load balancers.
• Processes for deployment, patching and monitoring.

Useful tools

• Configuration review: CIS Benchmarks for Nginx, Apache HTTP Server and IIS.
• TLS testing: testssl.sh or an online TLS scanner.
• Web scanners: OWASP ZAP or Burp Suite for application testing.
• Header checks: browser developer tools or online header scanners.
• Standards: the OWASP Top 10 and the OWASP Application Security Verification Standard (ASVS).

Steps to perform the audit

1. Map the attack surface: list domains, subdomains, open ports, admin URLs and APIs.
2. Review the server: check versions, modules, configuration and file permissions.
3. Test TLS: check protocols, ciphers, certificate validity and HSTS.
4. Test the application: authentication, sessions, access control and input handling, ideally with a penetration test.
5. Review operations: patching, backups, logging, monitoring and deployment.
6. Report: rank findings by risk, with clear fixes.

Web server checklist

• The server software is supported and patched.
• Only ports 80 and 443 face the internet; port 80 only redirects to HTTPS.
• The server hides version banners, for example with server_tokens off; in Nginx.
• Directory listing stays off.
• The team removes unused modules and sample files.
• The web server runs as a low-privilege user.
• File permissions prevent the web server from writing to code directories.
• Only an allowed IP range, a VPN or strong authentication can reach admin interfaces.

TLS and security headers

• The server allows only TLS 1.2 and TLS 1.3.
• Certificates stay valid and renew automatically.
• The site sends an HSTS header.
• The site sends security headers: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options or frame-ancestors, and Referrer-Policy.
• Cookies use the Secure, HttpOnly and SameSite flags.

Application security checks

• Login supports MFA, and the app limits repeated failed attempts.
• Sessions expire, and logout really ends them.
• The server checks authorization on every request.
• The server validates inputs, and queries use parameterised statements.
• The app limits uploads by type and size and stores them outside the web root.
• Error messages do not reveal stack traces or software versions.
• Third-party libraries and plugins stay current; for WordPress, remove unused plugins and themes.
• Secrets live outside the code repository.

Operations and monitoring

• A WAF or CDN protects against common attacks and DDoS.
• Access and error logs go to a central system, and someone reviews alerts.
• The team tests backups of code, configuration and databases.
• Deployments follow change management.

Common findings

Auditors often find outdated plugins, exposed admin panels, missing security headers, verbose error pages and old TLS versions still enabled. Most of these take little effort to fix.

Related guides

• How to audit applications
• How to set up an SSL certificate for Nginx

Sources

• OWASP Top 10

Preparing for an ISO 27001 or IT audit? Our ISO 27001 readiness assessment finds your gaps before the auditor does. You can also start with our free ISO 27001:2022 readiness checklist, or contact us for a quote.