Find vulnerabilities in web servers: 30+ hardening checks

Apache and Nginx configs look simple, but they are compositional. A directive can appear at top-level, inside an Apache <VirtualHost>, inside an Nginx server { }, inside a <Location> or a location { }: meaning changes with scope. Security headers declared in the wrong scope are formally present but do not apply to the page they were meant to protect. Modern ciphers declared at top-level get overridden by a legacy directive in a specific vhost. Regex grep does not see these subtleties: AST parsing does, and this version of the linter is based on a proper AST parser written in vanilla JS (~750 LOC total) producing a navigable tree of blocks and directives with line numbers.

What it actually checks. The linter applies 30+ checks across 5 families. SSL/TLS: obsolete protocols (SSLv2, SSLv3, TLSv1, TLSv1.1) and modern ones (TLSv1.2, TLSv1.3), weak ciphers (RC4, 3DES, EXPORT, NULL) vs strong ciphers, presence of forward secrecy (ECDHE/DHE), AEAD (GCM, ChaCha20-Poly1305), OCSP stapling. Security headers with value validator: this is the difference vs regex-based linters. CSP with unsafe-inline in script-src = effectively disabled, flagged medium; CSP with * wildcard, unsafe-eval, missing report-uri: separate findings each. HSTS with max-age < 6 months: medium. HSTS without includeSubDomains: low. HSTS without preload: info. Information disclosure: ServerTokens / server_tokens verbose, autoindex on, /server-status and /nginx_status not restricted. Availability and hardening: listen 80 without HTTPS redirect, rate limiting on auth endpoints (/login, /auth, /register), HTTP/2 enabled, mod_security WAF present. Nginx semantic overrides: the classical case where an add_header inside a location silently wipes all parent server add_header for that location, leaving the page without HSTS/CSP/X-Frame.

Difference between context-aware and regex-based linters. The previous linter on this tool ran regex grep on the entire config text: /Strict-Transport-Security/i.test(text). Result: HSTS declared inside <Location /admin> counted as HSTS present, even though the header was obviously not emitted outside /admin. Critical false negative. Same problem with Nginx add_header: presence in text does not imply application to the request. Same for protocols and ciphers: a directive valid in one vhost does not imply it applies to every other. The AST parser solves these problems at the root: every finding has precise context (which block, which line, with which arguments).

Operational privacy. A server config exposes the full structure of an infrastructure: hostnames, certificates, filesystem paths, internal backends, possible proxy caches, hidden admin paths. Uploading it to a third-party service for preliminary audit is a leak vector: the config leaves the perimeter, hits an external endpoint, gets processed and possibly logged. Here no network request leaves with config data: parser and rules run entirely in the browser. Verifiable by opening the DevTools Network panel during the lint.

When static triage is the right level. Typical scenarios. (a) Code review of a Pull Request modifying the Nginx config before merge: the linter covers 70-80% of hardening patterns and reports deterministically. (b) Pre-go-live audit of a new VPS: the freshly written DevOps config passes triage before production deploy. (c) Periodic self-check: the config running in production for two years is re-linted to catch regressions introduced by punctual changes. (d) Pre-engagement audit of a customer asking for a config review: thirty seconds of lint give the list of findings worth diving into with a serious hardening exercise.

Scope limit. The linter analyzes config text: it does not query the server runtime state, does not resolve Include / include against external files, does not validate X.509 certificates near expiry, does not verify the backend behind a proxy_pass actually answers HTTPS, does not parse logs for active attacks. For those aspects you need manual assessments, online scanners (SSLLabs, Mozilla Observatory) and continuous CVE monitoring. The linter is a fast triage, not a substitute.

The linter is structured in three independent layers: AST parser, context-aware rules, value validators. All run in vanilla JS in the browser, zero dependencies.

AST parser (~750 LOC total). Two separate modules: apache-config-parser.js (~400 LOC, line-based with XML-like <VirtualHost> tags, backslash-continuation support, case-insensitive matching) and nginx-config-parser.js (~350 LOC, recursive descent with explicit tokenization of {, }, ;, quoted strings, comments). Output: AST with directive nodes (name + args + line) and block nodes (name + args + children + line). Helper API: findAll, findDirectives, findBlocks, walkContexts (visitor with ancestor chain), findInScope (direct children only). Validated by 26 inline fixtures (12 nginx + 14 apache, manually runnable from console: NginxConfigParser.runFixtures() / ApacheConfigParser.runFixtures()).

Context-aware rules. For Apache: ServerTokens / ServerSignature at top-level; for each <VirtualHost> separately, audit of SSL (SSLProtocol, SSLCipherSuite, SSLUseStapling), HSTS scoped to vhost, security headers, HTTP/2 (Protocols h2); <Directory /> with AllowOverride All; <Location /server-status> and /server-info with/without restrictive Require; presence of <IfModule mod_security2.c>. For Nginx: for each server { }, audit of SSL (ssl_protocols, ssl_ciphers, ssl_stapling), HSTS scoped to server, security headers, HTTP/2 (listen ... http2); autoindex on in any nested scope; location /nginx_status with/without allow/deny; rate limiting (limit_req) on auth-type locations (/login, /auth, /register, /password-reset); add_header override semantics.

Value validators. Three validators write targeted findings on actual header values. CSP: parsing the value into directives (script-src, default-src, report-uri, report-to); 'unsafe-inline' in script-src = medium (XSS protection collapsed); 'unsafe-eval' = medium; * wildcard = medium; missing report-uri/report-to = info. HSTS: parsing of max-age; missing = medium; < 6 months = medium; missing includeSubDomains = low; missing preload = info. Forward secrecy: presence of ECDHE/DHE patterns in ciphers; absence = medium. HTTP/2: missing in Apache Protocols h2 or Nginx listen ... http2 = info.

Nginx override semantics (special case). Nginx has a counterintuitive rule: if a location contains even a single add_header, ALL parent server add_header directives are ignored for that location. Practical result: HSTS, X-Frame, CSP declared at server level are NOT emitted on the specific location's response. The linter detects this configuration (server with add_header + location with add_header) and reports medium with the list of affected locations. Typical fix: repeat essential headers in every location that has overrides, or rewrite using more_set_headers from nginx-headers-more.

Aggregated score 0-100. Computed as 100 - sum(severity_weights), with weights: critical 30, high 15, medium 7, low 3, info 1. Reading: 80-100 green (reasonable posture, possibly small fine-tuning), 50-79 yellow (interventions plannable in upcoming sprints), 0-49 red (significant security debt, some interventions need immediate mitigation). The score does not measure backend quality behind the config, only the security posture visible from the manifest.

Finding severity. critical: confirmed vector leaving the server vulnerable to historical exploits (SSLv2/SSLv3 enabled, weak ciphers without explicit exclusion). Immediate patch. high: probably exploitable configuration (TLSv1/TLSv1.1 without exclusion, HSTS missing on SSL vhost, X-Frame missing, CSP missing, /server-status open, listen 80 without redirect). To be addressed in current sprint. medium: suboptimal practice that reduces defense in depth (missing forward secrecy, CSP with unsafe-inline, HSTS max-age < 6 months, autoindex on, AllowOverride All, add_header semantic override, rate limit missing on auth). Hardening backlog. low: detail to fix (HSTS without includeSubDomains, OCSP stapling missing, add_header without always). info: observational state (default ServerTokens, HSTS without preload, HTTP/2 disabled, mod_security not visible, no server block).

What to do, by priority. (1) For CRITICAL on SSL/TLS: immediately update SSLProtocol / ssl_protocols to TLSv1.2 TLSv1.3 only and SSLCipherSuite / ssl_ciphers to the Mozilla SSL Configurator recommendation (Modern profile for recent browsers, Intermediate for broad compatibility). (2) For HIGH header missing: add HSTS (max-age=31536000; includeSubDomains; preload), X-Frame-Options DENY (or frame-ancestors in CSP), CSP coherent with the frontend, X-Content-Type-Options nosniff. (3) For HIGH /server-status / /nginx_status open: restrict to 127.0.0.1 and/or management subnet. (4) For HIGH listen 80 no redirect: add Redirect permanent / https://... Apache or return 301 https://$host$request_uri; Nginx. (5) For MEDIUM CSP unsafe-inline: refactor the frontend to remove inline scripts, use nonce or hash; in inevitable residual cases (legacy analytics), accept the finding but document it. (6) For MEDIUM Nginx add_header override: repeat parent server headers in every location that adds its own.

Finding format. Each finding reports title, problem description, reference to the exact directive in the config (with line number when applicable), technical motivation, suggested remediation. Hand it to the team with the operational message: "apply the fix in the next deploy, or produce a written analysis of why the vector is not applicable to our architecture".